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



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.

This is not criticism, so much as a request, I realize how difficult
it must have been to get Gtkmm as it is to work right!


http://www.io.com/~pelliott/notes/philo.html
http://austinlug.org/ALG/Presentations/elliott_peless/peless.sxi
(see especially slide 40)

-- 
Paul Elliott                       1(512)837-1096
pelliott io com                    PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/   Austin TX 78758-3117

Attachment: pgpIrktpXXuo6.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]