Re: When and when not to use Glib::RefPtr?
- From: Chris Vine <chris cvine freeserve co uk>
- To: gtkmm-list gnome org
- Cc: Matthias Kaeppler <nospam digitalraid com>
- Subject: Re: When and when not to use Glib::RefPtr?
- Date: Sun, 10 Apr 2005 01:21:41 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]