Re: [glade--] Could raw C++ pointers be eliminated?

[Carl Nygard <cjnygard fast net>]

On Wed, 2004-10-20 at 18:21, Paul Elliott wrote:
> On Wed, Oct 20, 2004 at 10:59:44AM +0200, Murray Cumming wrote:
> > > Christof Petig schrieb:
> > >> At the time I implemented Toolbars, Dialogs and Menus I simply gave up
> > >> to bother about member variable order. [variable order is spread between
> > >> two to three different functions, the ctor code emitter is much more
> > >> linear and local to write].
> > >
> > > The other reason is that ctor local variables (and widgets) are not
> > > possible with member variables once any member widget needs a reference
> > > to it (e.g. spinbuttons and alignments)
> > 
> > Why not? Can you give an example?
> > 
> > By the way, I should reword the text in that gtkmm FAQ entry. It's a bit
> > too strongly worded.
> > 
> > > Concerning smart pointers: The gtkmm infrastructure needs to work well
> > > first.
> > 
> > Specifically?
> 
> Thank you gentlemen for your discussion of the difficulties in removing
> raw pointers from the code generated by glade--.
> 
> I hold what you may view as a radical position. I believe that
> FRAMEWORKS should be designed so that applications programmers should
> not have to think about or deal with raw pointers at all, unless
> collection classes are being written, or some other class that deals
> with things with dynamic lifetimes.
> 
> This view, if correct, points out a problem with gtkmm not glade--.
> 
> The problem, when dealing with windowing programming seems to be the
> existence of Deletion Responsibility Transferring Objects (DRTO). That
> is there are all these objects that you are supposed to create, mess
> with a little bit, and then "give" to some other object that will have
> responsibility for deleting it in the future some time.
> 
> It is these DRTOs that always seem to require you to use pointers.
> 
> I believe that with a lot of thought and work, encapsulation could be
> used to hide the existence of DRTO's from the user.
> 
> If this were done the FRAMEWORK would never return a DRTO to the user.
> Instead some kind of DTRO_holder object would be returned which would
> hide a pointer to the real DTRO. The constructors for DTROs would all
> be made protected. The "add" methods would take a DTRO_holder objects
> as parameters and would do reference counting so that the real DTRO
> objects would be deleted when both the holder and the object that it
> was "given to" went a way.
> 
> I have not got this 100% figured out, especially when the user wants
> to derive from FRAMEWORK objects, but I believe it is a good idea to
> think about such things. Perhaps such a Framework could be designed to
> run on top of GTKMM without changing GTKMM itself?
> 
> Memory leaks and references through invalid pointers are the number 1
> reason why SUITS want to force us to use inferior Languages like
> JAVA. Really, why should Joe Sixpack application programmer be
> required to think about pointers when all he wants to do is write a
> simple X11 application? The Framework designer should hide such
> complexity from Joe, so that Joe can think about what his windows and
> dialogs look like.

Did WE just step INTO a zippy carTOON?

As soon as you require all widgets to take DTRO_holder objects, you lose
the ability to have widgets as class members or local variables, which
is one of the design goals of gtkmm.

Once you require DTRO_holder objects, you muck up the derivation of
derived widgets, as you pointed out.  I've tried this sort of thing in
similar circumstances, and you tend to box yourself into a corner.

And I think you want to be looking at libglademm anyway.

Regards,
Carl