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

[Murray Cumming <murrayc usa net>]

MHL Schulze t-online de (Martin Schulze) wrote:
> Am 28.09.2002 00:54 schrieb(en) Murray Cumming:
> > MHL Schulze t-online de (Martin Schulze) wrote:
> > > Am 27.09.2002 20:10 schrieb(en) Murray Cumming:
> > > > No, whenever a C object is destroyed, the C++ instance _will_ be
> > deleted.
> > > > It
> > > > might not be obvious how that happens, though I have tried to add
> > verbose
> > > > and
> > > > repetitive comments about that kind of thing.
> > >
> > > You must be wrong. It has always been possible to have gtkmm widgets
> > > on the stack.
> > 
> > The statements are not incompatible. If the C++ object is on the stack
> > (for
> > instance a class member variable) then the underlying C object will not
> > be
> > destroyed before the C++'s destructor runs. It's the same when you use
> > new/delete. If it's not manage()ed then noone but the C++ destructor
> > should
> > cause destruction of the underlying C object.
> > 
> > 
> > > And sure enough, in Object::destroy_notify_() which gets executed
> > > when the c instance dies, "delete this" is not reached when
> > > "referenced_ == true" (i.e. when the object has not been manage()ed):
> > 
> > If you think you've found a problem with the memory mangement please give
> > me a
> > test case that proves it. We have identified and fixed a few problems
> > recently
> > and those test cases are in the distribution in the tests directory.
> 
> Sorry for confusing you with my initial mail. I wasn't able to find the
> right words in the beginning. Allow me to start again.
> 
> I don't believe that there are any bugs in the Code. The problem I'm
> having is missing compatibility of Gtk::Object with smart pointers
> (i.e. smart pointers that use the GObject reference counter like
> Glib::RefPtr<> does):

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

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



Murray Cumming
murrayc usa net
www.murrayc.com