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

[Chris Vine <chris cvine freeserve co uk>]

On Tuesday 05 April 2005 22:57, Matthias Kaeppler wrote:
> Hello,
>
> is there a general rule of thumb which classes require access through a
> Glib::RefPtr? For example, based on the gtkmm tutorial, a TreeModel is
> constructed directly, while a TreeView is handled through a RefPtr. What's
> the point?

You might want to look at 
http://developer.gnome.org/doc/API/2.0/gtk/GtkObject.html for an explanation 
of the way GTK+ deals with object lifetime management.  If an object is 
derived from GtkObject then its container manages lifetime, and you (the 
user) are only responsible for the object if you add a reference count 
yourself (if you do that, at some stage you must unreference it again).  On 
the other hand, the general rule for an object derived from GObject but not 
GtkObject is that the user (that is, the user calling the function which 
delivers the object) is responsible for managing its lifetime.

However this is only a general rule.  In practice, with an object derived from 
GObject but not GtkObject it can sometimes be quite difficult to work out 
whether GTK+ is actually presenting the user with a new object for which the 
user is responsible or whether the function is only an accessor to an object 
which something else is managing.  If the function delivering the object has 
something like "create" or "new" in its name then you are getting something 
for you to manage with an initial reference count of 1.  But if you are 
accessing it with something like, for example, gtk_tree_view_get_selection(), 
then you are delivered a pointer to an GObject which the tree view manages 
(it is a mere accessor).

The general rule for gtkmm is that where gtk+/gdk/gdk-pixbuf/glib expects the 
user to manage the lifetime of an object derived from GObject but not 
GtkObject, then (as wrapped for gtkmm) it comes to you via a Glib::RefPtr 
object (an intrusive smart pointer) which does the referencing and 
unreferencing for you.  However the analogy is not exact.  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.)  The various Gtk::Widget::get_*() 
accessor functions are a similar example.  gtkmm adds an additional reference 
count and delivers the result to you via Glib::RefPtr, but GTK+ provides raw 
accessors only.

It is easier to leak memory and resources with GTK+ than with gtkmm.

Chris.