Re: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE]

[Carl Nygard <cjnygard fast net>]

On Thu, 2002-10-03 at 09:02, Butler, Gerald wrote:
> 	Pardon me for interjecting, but, I've been following this thread for a
> couple of days, and everytime I think I understand either side of the
> argument, the next response seems to turn everything upside-down.
> 	
> 	For purposes of my sanity, can I reiterate my understanding of the
> issues involved and could someone please tell me if my understanding is
> correct.
> 
> 
> 	1. GtkMM has 3 different memory management models
> 
> 		a. Standard C++ Automatic Allocation/Deallocation on the Stack
> 		b. Standard C++ Dynamic Allocation/Deallocation on the Heap
> 		c. Dynamic Allocation with "Manage" which delegates the
> lifetime of the GtkMM object to the lifetime of its container
> 
> 
> 	2. The "problem" in the opinion of (let's say the developer of GstMM
> -- sorry I'm getting confused about who is who -- please forgive me) is that
> he feels there is a need for another memory management possibility.
> 
> 		a. Dynamic Allocation with "Manage" which allows the widgets
> container to have a reference count to the object as well as other pointer
> with a reference count to the object.
> 
> 		b. Everytime one of the "pointers" goes out of scope or is
> destroyed, the reference count decrements.
> 
> 		c. If the container of the object destructs, it also
> decrements the reference counter to the object.
> 
> 		d. When the reference counter reaches zero, the underlying Gtk
> object is destroyed as well as the C++ wrapper.
> 
> 	3. Here's where I think my understanding completely goes awry (unless
> the above is completely off also)
> 
> 		a. By delegating the lifetime of an object to that of its
> container, we are saying, "I don't want to worry about destroying this object
> or even keeping track of it directly. Let the container do that for me. I only
> need to keep track of the container." Correct?
> 
> 		b. By maintaining a smart, reference counting pointer to an
> object we are saying, "I want to have multiple references to this object. I
> don't want to have to worry about invalid pointers/references. Whenever one of
> the pointers is destroyed, it will decrement the reference count. Every time I
> create an additional reference to my object I want it to increment the
> reference count. When the reference count reaches zero, meaning there are no
> longer any references to the object, the object is destroyed." Correct?
> 
> 		c. With the newly proposed model, we are saying, "Let me have
> multiple references to the object. Let one of those multiple references be
> from the container of the object. The reference from the container is the same
> as any other reference. When the container destructs, it DOES NOT destroy the
> object unless there are no other references to the object." Correct?
> 
> 	4. If everything I said above, then I still don't understand the
> problem trying to be solved by the new memory model.
> 	
> 		a. Why should we care when the container destructs if we are
> maintaining references to the contained objects. We can simply connect to the
> "destroy" signal handler of the container and iterate over our "list" of
> objects and destroy/de-reference them.
> 
> 		b. Alternatively, we can *not* maintain references to the
> objects and let the container destroy the objects automatically when it
> destructs.
> 
> 	5. Now, here's the Kicker -- I sincerely believe I have completely
> missed somebody's point. From reading these threads, I feel that those working
> on these issues are highly competent and it is my lack of understanding which
> is preventing me from seeing the point. Would someone please explain the
> problem the new memory model intends to solve with real-world examples.
> Perhaps, in trying to explain it to me, one side or the other might gain
> greater understanding of the other's point.
> 

You're basically correct (well, I won't be pedantic).  The key is what
P. Davis said:

"petitioning the GTK+ crowd to use gtk_object_unref()
instead of gtk_widget_destroy() in gtk_container_destroy(). then we'd
end up with a much more consistent and easy to think about toolkit."

The difference is in how the underlying libraries treat containers.  Gst
uses a pure Glib refcount model, while Gtk shortcuts around it and
assumes if it's in the container, destroy it, don't just unref it.  If
this were fixed in Gtk, Gtkmm would by extension do the same thing, and
magically everyone would be consistent.

Regards,
Carl