On Sat, 2009-03-07 at 21:52 +0000, Chris Vine wrote:
> I cannot comment on your other points because I do not have a clear
> enough view of how you are organizing 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.
Well, at this point if I can keep my data on the stack that satisfies
me. Discussion relating to having the TreeModel on the stack is more
just a curiosity.
> 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).
Now I see where the memory leak comes from. I was just examining the
objectbase.h file in glibmm. This raises an interesting question as to
why these functions are virtual. Were they made virtual to allow for
differing allocation models? Let me see if I have this correct as far as
deallocation of a tree model would go.
1. TreeView/ComboBox is destroyed and associated TreeModels RefPtr
calls unreference().
2. unreference() calls g_object_unref() on the underlying
dynamically allocated C GTK+ treemodel.
3. If the reference count of the C GTK+ treemodel reaches zero it
self destructs.
4. After self-destruction a callback is made to
destroy_notify_callback_()
5. This function then calls destroy_notify_() on the original
TreeModel C++ wrapper.
6. This function then calls a "delete this" to self destruct.
So it is in fact impossible to get the underlying C GTK+ object on the
stack. Correct?
>
> 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.
Interesting. So by putting stuff on the stack I am actually fooling
myself because all I'm doing is putting pointers on the stack. All real
data is still being put onto the free store. The thread you pointed me
to certainly brought quite a bit to light. Not to try to revive a dead
duck, but as you asked, why are widgets that needn't be copied handled
that way? Is it just for simplicity sake in deriving from ObjectBase
that everything dynamically allocates it's C GTK+ object? Why can
Gtk::Entry not statically allocate it's data?
--
Eddie Carle
This message has been signed with an RFC4880 signature. It is
guaranteed to have originated from Eddie Carle and its contents
can be validated against its signature.
Attachment:
signature.asc
Description: This is a digitally signed message part