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

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

Am 30.09.2002 19:06 schrieb(en) Murray Cumming:
> MHL Schulze t-online de (Martin Schulze) wrote:
> > I remember people complaining on the ml that they find memory
> > management with Gtk::Object difficult to understand repeatadly.
> > Give them the possibility to manage their objects with a smartpointer
> > and they will happy - that's my opinion.
>
> I don't see so many messages like that. gtkmm memory management is as
> simple
> as memory management with any C++ class, except for those few classes
> that
> _must_ be used via the RefPtr smartpointer. Plus, we have manage() to
> make it
> even easier.
>
> I'm getting really tired of repeating myself, but I will again: Given
> that
> gtkmm classes are just like regular C++ classes, you can use any existing
> smartpointer to help out with the management of them. Prove to me that
> you
> can't (with test code) and I'll be more interested.

Did you understand the example I wrote in my mail? Is it not clear enough?
Do you doubt that you need to use the glib reference counter and not an
extra reference counter of third party smartpointers when you want to
stretch the lifetime of the underlying C object over the lifetime of
its first container? Or what use do you think is a non-destroyed
C++ wrapper when the underlying C instance has died?

> > The Gst::Object wrapper based on Gtk::Object is already done.
> > It is based on Gtk::Object because GstObject and GtkObject (or better
> > GtkWidget which adds the methods set_parent() and unparent()) behave
> > _identically_ (apart from container destruction).
>
> I think it's a bad idea for the C++ wrapper's inheritance hierarchy to be
> different than the underling C object's. I think it should be done
> properly
> and fixed appropriately _if a problem is found_. I absolutely will not
> support
> any wrapper that does something bizarre like this without first
> demonstrating
> that it is necessary. Your previous misunderstanding of the gtkmm
> lifecycle
> suggests that you really need to test your theory first instead of fixing
> a
> problem that might not exist.

What are you talking about? I know that my english is not perfect but
I can't see where my text proposes that the inheritance structure of
gstmm differs or will differ from the one of the underlying c library.
Nor do I know what misunderstanding you mean. I did do some guesswork
at first because I didn't fully understand _why_ certain things are done
but I can't remember being proven wrong anywhere in _how_ things are done.
I hope the direct questions above will be more useful to make my point.
The thing I was mistaken about was the fact that it is non-trivial to use
Gst::RefPtr<> for gtkmm objects because of GtkButton.
And please show me where you find my example code bizarre if that's your
opinion.

> > And no, there isn't any problem. The following example code will work
> > fine with gstmm, as soon as some more wrapper classes are available:
> > (Gst::Bin is a container class for Gst::Object instantiations):
>
> I was asking for proof of a problem when GstObject is wrapped in the
> obvious
> way, not when wrapped in this strange way. And I certainly can't
> investigate a
> project that doesn't seem to be available to me yet.

Do you think GtkObject is wrapped in a strange way? If not why do you
think GstObject is wrapped in a strange way when the work is done based
on GtkObject? Maybe you want to take a look at

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gst-bind/c%2b%2b/object.ccg?rev=1.6&content-type=text/vnd.viewcvs-markup

and

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gst-bind/c%2b%2b/object.hg?rev=1.6&content-type=text/vnd.viewcvs-markup

if you doubt my words.

> > However, I will end this discussion now because nobody else pops up
> > who seems to want that feature apart from me and because I had to
> > notice that there are problems getting it to work for gtkmm.
> > (basically only because of GtkButton with mnemonic that has a
> > reference count of 2 after construction and thus can only be
> > destroyed with gtk_widget_destroy() :-( )
>
> Yes, that's how I discovered a couple of weeks ago that we were relying
> on
> side-effects of unreference() to cause destruction. We really _should_
> guarrantee destruction of manage()ed widgets. That's what manage() is all
> about.

I fully agree. And the desctruction can only be guaranteed if we follow
the gtk way for objects that have a ref_count > 1 after construction.
This is the problem I didn't see earlier; I had to try first. Sorry!

Regards,

  Martin