Re: refptr and this

[Murray Cumming <murrayc murrayc com>]

On Sun, 2008-02-17 at 08:43 -0600, Jonathon Jongsma wrote:
> On Sun, 2008-02-17 at 10:58 +0100, Murray Cumming wrote:
> > On Fri, 2008-02-15 at 23:36 -0600, Jonathon Jongsma wrote:
> > >  child->set_parent(Glib::RefPtr<Item>(this));
> > > Except this seems to cause refcounting problems and the program crashes.
> > 
> > The RefPtr constructor does not take a reference, so you need to do
> > RefPtr<Item>(this, true). I think it's that simple.
> > 
> > Murray.
> 
> Well, the reason I didn't do this is because I don't believe you're
> supposed to take a reference when you set the parent.  If you did, I
> think you would end up with circular references and the objects would
> never get destroyed (e.g. child holds a reference to parent and parent
> holds a reference to child).

GTK+ uses a two-stage destruction system to avoid circular references.
First, objects are asked to forget their references. Then the objects
really become invalid.

GooCanvas should do this too, I guess.

> For reference, here's the C implementation for set_parent in ItemSimple:
> 
> static void
> goo_canvas_item_simple_set_parent (GooCanvasItem  *item,
> 				   GooCanvasItem  *parent)
> {
>   GooCanvasItemSimple *simple = (GooCanvasItemSimple*) item;
>   GooCanvas *canvas;
> 
>   simple->parent = parent;
>   canvas = parent ? goo_canvas_item_get_canvas (parent) : NULL;
>   goo_canvas_item_set_canvas (item, canvas);
>   simple->need_update = TRUE;
>   simple->need_entire_subtree_update = TRUE;
> }
>