Erik Hofman wrote:
> 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 have no objection to either of these scenarios.  My objection is
improperly overloading the reference count (which has *nothing* to do
with "trees" or property values at all!) to implement it.

If you guys need or want a bit that says "leave in tree until
condition X has occurred", then that's fine.  But you can't use the
refcount to do it, that's not what it's for.

Reference counting is used to make sure that (a) memory is never freed
when there are live pointers to it, and (b) live pointers never point
to freed memory.  Any other usage* is just wrong, and causes bugs**.

* In this case: using the reference count to tell whether or not the
  node is "in the tree" or "detached".

** In this case: Nasal can keep a refcounted pointer for a short time
   until it gets garbage collected and deleted, which make the node
   undetachable until the collector runs.

Just call it something else, and leave the refcount value alone.  What
you guys are doing is not reference counted allocation.

Andy

_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to