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

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

Am 29.09.2002 21:16 schrieb(en) Murray Cumming:
> <snip>
>
> I don't know whether RefPtr<> can really be used with Gtk::Objects. I'f
> like
> to see test code - then I'd think about fixing any problems that were
> found.

Glib::RefPtr<> can't be used because the object cannot be retrieved from
it - there is only operator->(). That's not the point though. I'm talking
about something _similar_ to Glib::RefPtr<>.

> (For other readers: Glib::Object and Gtk::Object have different
> lifecycles.
> This is expressed in the API - see the manual.)
>
> > 1) Not calling manage() on the c++ object and using smart pointers
> >     sucks because the smart pointer calls unreference() which causes
> >     the destruction of the c object (when the reference counter reaches
> >     zero)

... but not the destruction of the c++ object. (You snipped away that
half-sentence :)) I fully agree with you that this way is not applicable
and I did express this in my mail.

> I would expect the RefPtr to just do an _extra_ ref/unref though you
> might
> need to do that reference() explicitly, because RefPtr<> was designed to
> be
> produced only by create() methods. Again, I think you need to test your
> theory.
>
> More importantly, I don't see how an unmanage()d Gtk::Object would be
> used
> with a RefPtr<>. The whole point of the RefPtr<> _is_ that the C++
> instance
> will be deleted after the last unreference(). You can't both RefPtr<>
> something and use normal C++ memory management - you need to surrender
> the
> lifetime to RefPtr<>.
>
> > 2) Calling manage() on the c++ object and using smart pointers
> >     sucks because the destruction of the Container forces the
> >     destruction of its manage()ed children disregarding the
> >     reference counter.
>
> Yes, manage() is not about ref-counting - it's about containers widgets.
>
> > I'd like to be able to recommend 2) for our users but currently it
> > simply doesn't work out and I feel that this should be changed.
>
> As I said before (somewhere), if you want a generic shared
> reference-counting
> smart pointer then you should use boost or something similar. So far I
> don't
> see why you need to involve the underlying C object in this. Again, if
> you
> produce test code that shows a problem then we have something to work on.

I need to involve the underlying C object in it because the underlying
C object is the one that gets referenced in the gtk container code. I
don't see how the reference counter of boost::shared_ptr<> could be
increased when adding the object to some Gtk::Container and descreased
when the object is removed from the container. I.e. I don't see how
boost::shared_ptr<> could share the underlying object with our
containers.

Again, my proposal is to _not_ force the destruction of the childs
when a container is destroyed but only descrease the reference counter
instead. I will work on a patch to prove that this wouldn't break
anything but allow us to create a Glib::RefPtr<> like smart pointer
that can share the underlying object with our containers.
(Test code is not possible at the moment, because there is no such
smart pointer. I would very much like to have one though.)

> > > I do plan to write up a detailed description of the C-C++ lifetime
> > > connection
> > > - that's why I added the //GTKMM_LIFECYCLE comments. But it isn't a
> > > priority
> > > at the moment.
> >
> > That's right. I was also thinking about writing such a description
> > because I need to fully understand the gtkmm lifecycle management
> > code in order to implement it right for gstmm. And make it intuitive
> > for gtkmm users... (Gst::Object is very similar to Gtk::Object).
>
> I would like to see an explanation of how GstObject's lifetime is
> different
> than GObject, or how it is like/unlike GtkObject. That might be a lot
> more
> productive. So far I know nothing about it.

It is different in that the container classes that derive GstObject do
not force the destruction of its children. Instead they simply
decrease the reference counter and set the "parent" field to zero.
If a container holds the only reference to a child, the latter gets
destroyed in the unref(). I consider this a clear & clean behaviour.
It allows for a maximum of flexibility in the c++ wrapper.

Cheers,

  Martin