* Andy Ross -- Wednesday 29 June 2005 19:49: > The basic issue as I understand it is that apparently > SGPropertyNode::removeChild() has been (incorrectly, AFAICT) modified
No. The only modification was a name change. It's now called detachChild(). A new function has been added that does really remove a node with all children. You can still use detachChild() and get exactly the same buggy behavior as before. > What is wrong with removing a node that someone else is holding a > reference to? Well, the theory is that the property tree is there to inspect/access values. And the idea is that a remove function shouldn't only detach property nodes that are then secretly used behind the users back. If you want them to stay, don't remove them. If you want to remove them, don't tie a reference to them. I see your point, but you don't see mine. Should there be an option "bool really = true"? The current behavior is (if I understood Fred correctly) the way David had planned. The old "removeChild()" was just a (misnamed) solution for a different demand. > When they free their reference, then it gets deleted. But it doesn't. That's the whole point. The SGPropertyNode_ptr destructor doesn't remove the node's children. Of course, it would have been possible to let it do that. But see above. > > No. removeChild/ren() is correct. Just don't take guarded pointers > > from nodes that you want to remove. > > That's not possible in Nasal. OK. So we are actually talking about a Nasal problem? :-} m. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
