Re: [gtkmm] Glib::RefPtr construction

[Michael Johnson <michaelj maine rr com>]

Murray Cumming wrote:
> On Wed, 2003-01-08 at 16:45, Michael Johnson wrote:
> >   
> > One consequence of this paradigm shift would be that the
> > destroy_notify_callback in Glib::ObjectBase would no longer result in
> > deletion of the wrapper.
> >   
>
> When the GTK+ object dies, the C++ object must die. Their lifetimes must
> be linked to keep things simple. So far that has worked fine.
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.
> I don't think you'll be able to make RefPtr
> do the right thing always by writing perfect constructor and operator=()
> implementations, because GTK+ does not have a consistent
> reference-counting policy. We need to generate specific generated code
> (e.g. see refreturn in the .hg files). As I said before, by doing so, we
> hide the GTK+ inconsistencies.
Is there someplace where these inconsistencies are documented, or do I need
to go searching through the GTK+ documentation?
> > > RefPtr<> is not intended for this purpose. RefPtr is for use with
> > > Glib::Object-derived objects only.
> > >   
> > >     
> > The documentation does not make this distinction.
> >   
> 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.

..mj
> >