On Sat, 2009-03-07 at 20:24 +0000, Chris Vine wrote:
> I wonder if you are looking at this from the wrong direction. If you
> have a custom tree model which just references data allocated and held
> elsewhere (it does not make a deep copy), then why is limiting the
> tree model to local scope important? What is important in terms of
> usage of resources in that scheme is the lifetime of the data which is
> referenced. You also need to consider the lifetime of the tree view
> which takes ownership of the model.
Well, that is exactly the point the Murray alerted me to and most likely
the direction I will go in. The data is actually declared inside a class
derived from ComboBox that will be the only object using the TreeModel
anyway so I assume that is sufficient assurance that the lifetimes will
not conflict.
> Also, if you have a local (auto) tree model object, how are you
> returning control to the GTK+ main loop so that your tree model can
> actually be displayed by the tree view?
I'm not sure I understand this question. If I could allocate the
TreeModel in the stack it would be declared inside the derivation of the
ComboBox. Constructors would be called, data built at which point I can
initiate the GTK loop.
> 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?
--
Eddie Carle
This message has been signed with an RFC4880 signature. It is
guaranteed to have originated from Eddie Carle and it's contents
can be validated against it's signature.
Attachment:
signature.asc
Description: This is a digitally signed message part