Re: [gtkmm] Glib::RefPtr construction

[rsteinke w-link net]

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

Not to mention that the "destroy" signal in a GtkObject really
means 'drop all references to this object', and trying to
account for _that_ automagically would be a pain in the ass.

Ron Steinke