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