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

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

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):

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

Your comments above show me that 1) is the wrong way. (That's what I
thought anyway).

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.

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.

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

Regards,

  Martin