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

[Murray Cumming <murrayc usa net>]

MHL Schulze t-online de (Martin Schulze) wrote:
> > 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.

And so far I have no idea why you would be interested in when the C object
gets referenced. It's wrapped.

> 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 don't know why you would want that to happen.

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

But the whole point of manage() is that it is destroyed. That's the default
GTK+ behaviour. I like to offer C++-like behaviour (default) and GTK+-like
(using manage()) behaviour but I don't think it's a good idea to add a 3rd way
or to obfuscate the GTK+-like behaviour.

> 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 am far more interested in seeing what problem this solves - with test code.
I suspect there is something meaningful at the root of this conversation, but
I'm not seeing it now so I'm not interested in spending my time on fixing
problems that don't seem to exist.
 
> > 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.

So maybe it would make sense to derive Gst::Object from Glib::Object and add
Gtk::Object-like code, but unreference instead of destroy. Maybe then it could
be used with Glib::RefPtr. Actually you might not even need to write code for
that - GstObject might do it for you.

Once again, I urge you to _try_ it first - the most obvious thing to do would
be to use gtkmmproc to derive a Gst::Object wrapper from Glib::Object. Then,
if there's a problem, it can be investigated. Please just try it.


Murray Cumming
murrayc usa net
www.murrayc.com