Re: [gtkmm] Glib::RefPtr construction

[Daniel Elstner <daniel elstner gmx net>]

On Mit, 2003-01-08 at 18:51, Michael Johnson wrote:
> >   
> I believe that this will happen appropriately with a 'correct'
> implementation of reference counting. So long as the C++ object is
> alive and holds a reference to it, the GTK+ object should not be
> destroyed. When the C++ object is destroyed and releases its
> reference, then the GTK+ object *may* be destroyed, if there are no
> other references to it being held by other C objects.
> 
> The current implementation works by keeping the GTK+ object alive at
> least as long as there are references to the C++ object. That should
> remain the case in the implementation I described, but hopefully in a
> greatly simplified manner.

GObject might be simple to deal with, but GtkObject refcounting
semantics are from hell.  Yes, you could theorhetically make GtkObject
behave like GObject by reffing and sinking it.  But GTK+ code seems to
acquire references that are only dropped on gtk_object_destroy().  Also
see the GtkWindow and GtkInvisible behaviour for more sources of
annoyance.

In short, it's not that simple.

> > > > RefPtr<> is not intended for this purpose. RefPtr is for use with
> > > > Glib::Object-derived objects only.
> > > >   
> > > >       
> > > 
> > > The documentation does not make this distinction.

Although it may seem obvious, the Glib::RefPtr<> docs do nowhere state
that it is implemented by calling reference() and unreference()
methods.  (Actually, reference() and unreference() shouldn't appear in
the docs at all since you don't need to use them directly.) Further
there's no guarantee the RefPtr<> semantics won't change at some point
in a way that only works transparently with Glib::Object.

And I really don't see the need for it.  Glib::RefPtr<> is a simple
intrusive smart pointer.  It's trivial to implement if you need it. 
IMHO it's a bad idea to promote a smart pointer implementation for use
with your own types that requires two special methods to work.

> > OK, we should fix the docs.
> >   
> I was thinking more along the lines that the docs are correct and the
> implementation needs to be changed, actually. I note that there are
> already classes in gtkmm (see Glib::IOChannel) that are derived
> directly from SigC::Object that are nonetheless managed using
> Glib::RefPtr.

This is all glibmm internal.  You shouldn't need to worry about it.

--Daniel