Brian Braatz <brianb(a)rmtg.com> wrote:
[Thomas Witt wrote:]
> > David Abrahams wrote:
> > > Reece Dunn <msclrhd(a)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.
