Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 09:46:08 +0100
Murray Cumming <murrayc murrayc com> wrote:
> On Thu, 2010-03-25 at 01:57 +0000, Chris Vine wrote:
> > In cases where GTK+ does not in fact
> > intend ownership to be passed, gtkmm gets round this by incrementing
> > the reference count in the getter function, thus neutering the
> > RefPtr, but also leaving open the possibility of a reference being
> > owned by a user to an invalid object.  In such cases the object
> > should really be returned by a simple pointer or a weak pointer. 
> 
> Do you have an example GTK+ C function for that? Maybe it should even
> be in gtkmm's bugzilla.

I am thinking of all those GTK+ getter functions where the user is
not expected to call g_object_unref() when finished with manipulating
the return value. These objects are usually owned by another GTK+ object
(the one whose method the getter function is) and will have parts of
their implementation which become invalid when the owner is finalised
(they are expected to be destroyed at the same time).

Particularly obvious examples are manager classes such as a
GtkTreeSelection object, which is owned by a GtkTreeView object.  It
is part of the TreeView's implementation and is completely invalid when
the TreeView no longer exists.  (I would not want to restrict the use of
weak pointers to such a case - it should in my view apply to any object
owned by another object which is not capable of fulfilling its proper
purpose once that other object has been destroyed.)  Compare
Gtk::TreeView::get_selection() with gtk_tree_view_get_selection().

Or were you looking for a C example of a weak pointer?  glib provides
g_object_add_weak_pointer() which can be added to a GObject, such as a
GtkTreeView object, and which will be set to NULL when the object is
finalised.  It should be reasonably straightforward to wrap that.  Or
if desired, gtkmm could add its own custom notification callback with
g_object_add_weak().

There will be cases where even a weak pointer is overkill.  For
example, GtkClipboard objects are owned by GTK+ itself ("Once a
clipboard object has been created, it is persistent and, since it is
owned by GTK+, must not be freed or unrefd").  (In this case of course,
the present use by gtkmm of RefPtr for them is harmless but pointless.)

Chris