Re: The use of RefPtr

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 07 Mar 2009 13:49:48 -0700
Eddie Carle <eddie erctech org> wrote:
[snip]
> > In answer to your question, if you do not allow the tree model's
> > reference count to reach zero then you will have a memory leak.  But
> > the point you may be missing here is that the tree view also
> > acquires a reference. Once the Glib::RefPtr object which originally
> > owns the tree model goes out of scope, it is the tree view which
> > determines the lifetime of the model (assuming you have passed the
> > model to a view).
> 
> As I said above, the data and TreeModel lifetime will be directly
> associated with the ComboBox that is using them. The nature of this
> memory leak does spark my curiosity though. What exactly is leaked?
> You can't leak stack memory, that's not possible. I understand that
> the TreeView or ComboBox in this case acquires a reference. It
> wouldn't really make any sense if they didn't. So when the ComboBox
> goes out of scope/is deleted, the refcount is decremented and if it
> reaches zero then the TreeModel is deleted. By manually incrementing
> the ref you prevent the delete from ever happening but if the data is
> on the stack it will be destroyed by going out of scope anyway so
> what is actually leaked? Is there some internal data in the TreeModel
> struct that only gets freed if the it is destroyed through the
> unreference() function? --

I cannot comment on your other points because I do not have a clear
enough view of how you are organising your program, and in particular
why having a tree model on the stack is such an issue for you if you
are not doing a deep copy of the data.

On your last question however, I will assume for the sake of the
argument that you have created on the stack a local (auto) object
derived from Gtk::TreeModel.  As I have previously said, all GObjects
are allocated on the heap and are reference counted, and they can only
be destroyed by decrementing the reference count to 0. If you allow the
Gtk::TreeModel object to go out of scope you will have destroyed the
gtkmm wrapper (probably just a single pointer) but not the underlying
GtkTreeModel object.  To do that you need to decrement the reference
count after the tree view has taken ownership.  You could do that by
calling g_object_unref() on the underlying GtkTreeModel object in the
destructor of your object derived from Gtk::TreeModel (happily the
destructor of Gtk::TreeModel is vacant - it just returns - and doesn't
try to access any of the GtkTreeModel internals, although I suppose
that could change).

Is there something in GTK+ which requires the creation of the gtkmm
wrapper of pure GObjects on free store with factory functions?  No (I
made this point here
http://mail.gnome.org/archives/gtkmm-list/2009-February/msg00096.html ).

However, the way gtkmm chooses to do it is by factory functions.  So
constructing objects on the stack won't get you anywhere with gtkmm
because the Gtk::TreeView object will expect its tree model argument by
Glib::RefPtr.  Your scheme will work however if you go down to the raw
GtkTreeView level and pass the tree model by pointer by calling
Gtk::TreeModel::gobj().  But all that that will achieve is the creation
of a pointer on the stack rather than on free store.

That does not seem to me to be a win.  But if your question is, can you
do it, then as someone on your side of the Atlantic might say, yes
you can.

Chris