RE: [boost] Re: GUI Windowing Framework in C++

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-24 14:02:43

Brian Braatz <brianb_at_[hidden]> wrote:
 [Thomas Witt wrote:]
> > David Abrahams wrote:
> > > Reece Dunn <msclrhd_at_[hidden]> 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.