Re: When and when not to use Glib::RefPtr?

[Chris Vine <chris cvine freeserve co uk>]

On Sunday 10 April 2005 12:11, Murray Cumming wrote:
> > gtkmm uses
> > Glib::RefPtr for things derived from GObject even where GTK+ does not
> > expect
> > you to manage the lifetime of the unwrapped object.  Taking the example
> > of gtk_tree_view_get_selection(), in the gtkmm equivalent
> > (Gtk::TreeView::get_selection()), the Gtk::TreeSelection object is
> > delivered
> > to you via a Glib::RefPtr and gtkmm adds an additional reference count
> > (which
> > GTK+ does not) before doing so for the purpose.  (Whether that is a good
> > thing is debatable, as the TreeSelection object has no meaning if the
> > TreeView has been destroyed, so it is an ineffective ghost if the
> > TreeView is
> > destroyed before the object holding the Glib::RefPtr finally disposes of
> > it,
> > but it has the merit of consistency.)
>
> It would be an invalid (as in, things crash if you use it) object either
> way. RefPtr manages the object properly whether the programmer wants to or
> not.

Yes the object would be invalid in either case.  Equally, the object would be 
just as well managed if a raw pointer were passed and the reference count 
were not incremented - in other words, if the GTK+ approach were adopted.

I am not saying that the gtkmm approach is wrong, but another policy which 
could be adopted is that accessors will pass on objects by reference counted 
pointer only if the object is valid whilst the reference count is greater 
than 0 - that is, where the claim of shared ownership implicit in a reference 
counted pointer is modelled in practice.

Chris

-- 
Summer is y-cumen in, lhude sing, cuccu!
Groweth sed and bloweth med, springeth the wude nu.