Melchior FRANZ wrote :
* Frederic Bouvier -- Thursday 30 June 2005 16:05:
Melchior FRANZ a écrit :
I am sorry about that, and please accept my apologies. I didn't get into
the issue until you change the API, and I only understood you didn't get
the idea until your last message.
Heh ... and I apologize to all for the false alarm and the needless
inconvenience, especially to Erik for dragging him into that and
(successfully :-) fooling him. I've learned a lot about the property
system now, maybe it'll at least pay in the future.
But reverting doesn't solve all problems (although I could again be wrong):
alias() and unalias() referenced pointers *without* increasing/decreasing
the refcounter. So they could lose their target and crash. I simply let
them call incrementRef/decrementRef on their target. This should then be
done with SGPropertyNode_ptr, too, right?
What about :
// The right kind of pointer...
union {
- SGPropertyNode * alias;
+ SGPropertyNode_ptr alias;
SGRawValue<bool> * bool_val;
SGRawValue<int> * int_val;
I don't remember why it wasn't done that way at the first time.
And a removeChildren() (derived from the old removeChild(), not a "clever"
new design based on wrong assumptions :-) would also be handy.
Sure
And all callers of removeChild() should set "keep" to false. Only one
did so far. Mine didn't, because the documentation left me quite unclear
about why I would or would not want that.
I am not sure about the 'keep' thing. Is there any reason duplicating
the same thing. If you want to keep a subtree, hold the reference
yourself and don't destroy the returned SGPropertyNode_ptr, and dump
_removedChildren. I am afraid the alias feature is complicating the
whole design.
-Fred
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
