Erik Hofman a écrit :
Andy Ross wrote:
Seriously: the removeChild() method is just buggy. It should never
have cared about refcounting at all.
Andy, I have to agree with Melchior here. If you call removeChild you
have the intention that it will stay in the tree until refcount
becomes zero and then it will be deleted. If you call removeChild()
and it just detached from the tree (without cleaning it up at some
point) you won't even be allowed to access it using the property tree,
even after the first call to removeChild().
I am rather on Andy's line here. As I tried to explain to Melchior
'remove' doesn't mean 'destroy'. I think the only reason the tree wasn't
actually deleted/destroyed when the reference returned by removeChild
was deleted is that it was copied in the _removedChild vector before
returning, hence incrementing the counter. If you don't care having
aliases pointing to garbage ( something David was against ), you would
just have to dump the _removedChild vector and, if the
SGPropertyNode_ptr returned is not used, the tree should be destroyed.
Two functions shouldn't be necessary.
-Fred
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
