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

[MHL Schulze t-online de (Martin Schulze)]

Am 03.10.2002 15:02 schrieb(en) "Butler, Gerald":
> 	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?

Yes. And that's also the way it is in gstmm at the moment when you don't
use a smartpointer:

{
  Gst::Element my_element;
  Gst::Pad* my_pad = Gst::manage(new Gst::Pad);
  my_element.add(*my_pad);
}  // my_element gets out of scope and decreases the reference counter of
      my_pad on destruction => my_pad->ref_count == 0 => my_pad is 
deleted.


> 		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?

Yes.

> 		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?

Yes. Keeping a Gst::RefPtr<Gst::Pad> my_pad_ptr(my_pad) hanging around in
the example above would prevent the destruction of my_pad.
This is the only difference compared to gtkmm at the moment where there
is no such smartpointer (Glib::RefPtr<> doesn't work and has no 
operator*()).

> 	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.

What you describe would be a "weak reference". That would be another
feature and you can find some low(est) priority TODO entry somewhere in
the gtkmm code about adding a weak_ptr<>.
But the problem is, maybe we don't _want_ the container to destroy
the object in first place because we need it for later reference;
i.e. we want a strong reference to the object.

> 		b. Alternatively, we can *not* maintain references to the
> objects and let the container destroy the objects automatically when it
> destructs.

That's right.

> 	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.

The point is to build a memory model that is as flexible as possible
and yet easy to use.
gstmm gives me that overwhelming flexibility with a simple copy&paste
from gtkmm codebase (and some heavy thinking about how things work).
If you use it like gtkmm it behaves exactly the same.
Other users may find some use for the new smartpointer feature and if
only to simplify memory management in their applications.

Regards,

  Martin