Due to a question in Reddit's main beginners' C++ group (about parallel
implementation class hierarchies) I sat down and tried to code up a
portable widget definitions, such that the low level OS-specific widget
that provides the implementation of a portable widget, exists from
successful construction of the portable widget object, until destruction
of the portable widget object, where it's that high level destruction
that effects the low level OS-specific widget destruction and not vice
versa.

Avoiding self-destruction avoids the need to allocate widget objects
dynamically, which I think is desirable for ease of use.

But then e.g. a main window object will need to cause its own
destruction by informing the event loop to finish up, whereas some other
top level window must do something else.

So far I ended up with code like this:

#include "gui.hpp"

auto main() -> int
{
auto event_dispatcher = gui::Event_dispatcher();
auto window = gui::Main_window( [&]{
event_dispatcher.finish(); } );

window.set_startup_displaystate();
event_dispatcher.dispatch_events();
}

Is that a reasonable design? I'm not sure how to fix the ugliness that
user code has to connect things that ideally should Just Work.

I considered for a while a kind of design where the high level object
could instead transition to zombie state where the low level OS specific
widget is destroyed, but it felt wrong and Microsoft-ish.

- Alf