Re: The use of RefPtr

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 07 Mar 2009 12:30:23 -0700
Eddie Carle <eddie erctech org> wrote:
> On Sat, 2009-03-07 at 18:48 +0100, Murray Cumming wrote:
> > Eddie, presumably you are implementing a custom model (which will be
> > difficult enough already), to avoid duplicating a large block of
> > data inside the regular ListStore or TreeStore. And presumably it's
> > this block of data that you don't want to allocate dynamically.
> 
> That, is exactly what I am trying to accomplish. Pardon my inability
> to explain it in a proper fashion like that. I've already got my
> derived TreeModel working. That's not the issue.
> 
> > Can't you just do that and use a pointer to it from inside your
> > TreeModel, rather than trying to change the memory management of the
> > treemodel itself?
> 
> That, is an excellent idea. I guess I got so caught up in trying to
> keep the whole thing on the stack that that didn't even occur to me.
> 
> I am still curious however if calling reference(), never allowing the
> TreeModels refcount to reach zero and manually destructing is safe.
> Are there any comments on this?

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.

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?

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).

Chris