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

["Murray Cumming" <murrayc murrayc com>]

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

In general we avoid guessing such (undocumented) internal lifetime
details, and just do the same thing with all GObjects. C coders do
whatever works, with lots of errors along the way.


Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com