Brian Braatz <brianb@rmtg.com> wrote: [Thomas Witt wrote:]

...

David Abrahams wrote:

...

Reece Dunn <msclrhd@hotmail.com> writes:

...

[1] Support constructor-based window creation, e.g.:

frame.add( new gui::button( "Boost!" ));

Get rid of the new operator, though. IMO there's no excuse for a GUI framework to expose users to unmanaged resources.

Hmm, do you know of a C++ GUI framework that gets this right?

Just curious [Brian Braatz] The problem is handling the "dual lifetimes" of "system" GUI objects and C++ objects.

BeOS is the only system I know that does not have this issue, because they extended C++ in such a way so that when you "create" a C++ window object- you now have a window.

Be didn't extend C++; they just decided to use C++ for most of the system APIs rather than providing C APIs and C++ wrappers for them. (A problem with this approach is that it's difficult to preserve binary compatibility in C++ interfaces while extending them; also, language changes have forced ABI changes in some compilers over the past few years.)

In frameworks like MFC, they have to internally track a windows resources "object" that the system understands as the gui object.

Even in BeOS there is some kind of handle underneath, because windows are managed by a separate process called the application server. It seems to me that the annoyance of mismatched lifetimes in MFC is due to its design as a thin wrapper over the Windows API at a time when the language (or at least the MS implementation) did not have exceptions. This resulted in the evils of two-phase construction. Qt seems to have managed to avoid this, despite not using exceptions, by being a more heavyweight wrapper.

You will always need a dynamic nature to things, but one could take a Rogue Wave approach here and hide all those new's behind accessor type objects which pass around by value and internally hold something like a boost::shared_ptr<>

That may well be a good approach.