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

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

Am 01.10.2002 02:08 schrieb(en) Carl Nygard:
> On Mon, 2002-09-30 at 11:48, Martin Schulze wrote:
>
> I hesitate to jump in here, because I have no clue what Gst does (you're
> wrapping Gstreamer right?).

I'm glad on anyones input. Asking questions is the best thing you can do.

> BUT, I have a few observations from an outsider's perspective, and
> perhaps (just perhaps) this might make sense.
>
> After that singularly inspiring caveat, see comments below:
>
> > 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).
> > 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):
> >
> > void test1()
> > {
> >    // my_pad won't be deleted until our reference is out of scope.
> >    // Gst::RefPtr<> is identical to Glib::RefPtr<> but
> >    // Gst::RefPtr<>::operator=() references and sinks the object.
>
> Then it's not identical to Glib::RefPtr<>.  If you're going to use the
> same naming convention, then (from a user's perspective) it better do
> the exact same thing (at least semantically, if not technically).
>
> If it doesn't do the same thing, then name it differently.

Okay. The last thing I want to do is to confuse the user. (I didn't
commit Gst::RefPtr<> to CVS so far. It's low priority because it's
convinience stuff. But I want to be able to add it at a later point.)

> >    // => my_pad->ref_count == 1
> >    Gst::RefPtr<Gst::Pad> my_pad = Gst::manage(new Gst::Pad);
> >
> >    test2(my_pad); // first call to test2.
> >    test2(my_pad); // second call to test2.
> > }
> >
>
> I may be dense, but if you use some arbitrary smart ptr, then you don't
> need the Gst::manage() part, right?  I have no idea what you're doing
> with my_bin, but your comments seem to indicate that my_bin only lives
> within the scope of test2().

You need it when you want a container to share the object with your
smartpointers. I.e. when all your smartpointers are out of scope but you
added your object to a container before you don't want you object to be
deleted.
In gstreamer this would be fatal because the container won't notice the
destruction of your object => memory leak. This is different from widgets
in gtkmm. (At least I believe that the containers are notified in gtk when
their childs are destroyed. I haven't investigated this completely.)

> > void test2(const Gst::RefPtr<Gst::Pad>& pad)
> > {
> >    // Gst::Bin::add() increases the reference count of the new child.
> >    // => my_pad->ref_count == 2
> >    Gst::Bin my_bin;
> >    my_bin.add(*my_pad);
> >
> >    /* do something with my_bin */
> >
> >    // On destruction, my_bin decreases the reference count of its
> children.
> >    // => my_pad->ref_count == 1
> > }
> >
> > You have no chance getting this example code to work with gtkmm by
> > replacing Gst::Pad with Gtk::Label and Gst::Bin with Gtk::HBox but
> > to use a static object and not call manage, currently.
> > No smart pointer could prevent the destruction of the label when
> > function test2() ends.
>
> On the other hand, if you're trying to use the same pad object in two
> different hierarchies, then you're already violating Gtk idiom (I think)
> which wouldn't allow the same widget to appear in two different widget
> hierarchies

No. The first hierarchy gets out of scope at the end of test2() and
therefore the container is destroyed and the object unparent()ed.

Regards,

  Martin