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

["Butler, Gerald" <gbutler jewels com>]

	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.


Thank You,
	Gerald E Butler
	

> -----Original Message-----
> From:	MHL Schulze t-online de [SMTP:MHL Schulze t-online de]
> Sent:	Thursday, October 03, 2002 8:25 AM
> To:	Carl Nygard
> Cc:	gtkmm-list
> Subject:	Re: [Re: [Re: [Re: [Re: [Re: [Re: [Re: [[gtkmm] technical
> question: GTKMM_LIFECYCLE]]]]]]]]
> 
> Am 03.10.2002 13:27 schrieb(en) Carl Nygard:
> > Then you should just throw up your hands and say "It ain't gonna be
> > consistent."  The base libraries are already inconsistent, so quit
> > trying to force it.
> 
> I thought it would be a good idea to make the behaviour 100% consistent
	<SNIP>
> hard to explain nor that I would hit such a sensitive nerve.
> 
> > And if it's going to be inconsistent, then don't use the same function
	<SNIP>
> > Gst::manage() works that way.  Make it obviously different.
> 
> They work the same way internally but have a different consequence when
	<SNIP>
> function but I don't believe that this is so pressing at the moment.
> 
> Regards,
> 
>    Martin
> 
> 
> 
 The information contained in this e-mail message is privileged and/or
 confidential and is intended only for the use of the individual or entity
 named above.  If the reader of this message is not the intended recipient,
 or the employee or agent responsible to deliver it to the intended 
 recipient, you are hereby notified that any dissemination, distribution or 
 copying of this communication is strictly prohibited.  If you have received 
 this communication in error, please immediately notify us by telephone
 (330-668-5000), and destroy the original message.  Thank you.