The destructor is called when the object is about to be destroyed,
after the last reference to the object is gone. This lookup table
value is a reference to the object. So...
Charles Yeomans
On Jan 5, 2007, at 11:29 PM, Tom Benson wrote:
But it breaks the circular reference, and when a child's reference
count becomes 0 it will be cleaned up.
So, if you put some code in the child's destructor that removes
it's lookupTable entry, you can be reasonably confident that all
object references are current, and that there are no unattached
cycles.
Or am I misunderstanding the root of the problem?
- Tom
On 06/01/2007, at 1:46 PM, Charles Yeomans wrote:
Storing a reference to parentObject in the dictionary simply moves
the problem. You still need to delete that last reference yourself.
Charles Yeomans
On Jan 5, 2007, at 9:23 PM, Tom Benson wrote:
Hmmm.. you could .hash all of your objects, and then have a
dictionary key(child.hash),value(parentObject)
that would break the cycle without too much overhead, enabling
you to have a reverse lookup table stored in a seperate module.
Everytime you instantiated a child you'd need to make an entry in
the dictionary though.
You could then traverse down the tree with parent.child, but to
traverse up you'd need to do parent = child.lookupParent(child.hash)
On 06/01/2007, at 11:02 AM, Frank Condello wrote:
On 5-Jan-07, at 5:56 PM, Stefan wrote:
Am 05.01.2007 um 23:43 schrieb Daniel Stenning:
Seem to remember someone mentioning that monkeybread
supporting weak
references in their plugin collection, not ideal I know, so
I'll sign on to
that F.R in any case.
Some time ago, we had a lengthy discussion regarding this.
I personally had a problem based on cyclic object graphs. As
far as
I remember, RS explained, that cyclic object graphs can always be
rewritten to acyclic graphs. Furthermore, I remember that
someone of
RS explained, that cyclic graphs are often a sign of bad design
[which
I can't confirm].
I don't know - cyclic references are really useful for tree
structures where you need to traverse the tree backwards. E.g.
in my 3D scene graph nodes can contain child nodes, and each
node's transformations (position/orientation/scale) affect its
children. The renderer traverses the tree from the root so
children needn't know about their parents in that case. However,
nodes must have knowledge about their parents to glean data such
as their absolute world coordinates. I could traverse the whole
tree from the root until I find the node I'm interested in but
that's a huge waste of time - it's far easier and faster to
traverse the tree backwards until you hit the root.
So for right now I use cyclic refs and require nodes to be
disposed of implicitly, giving them a chance tell their children
to trash the parent ref. To ensure I haven't missed any I check
the Runtime module for dangling nodes in the App.Close event.
This works OK, but is quite the PITA, so if anyone's got a
reasonable acyclic solution I'm all ears...
Thus, I really wonder, if RS would implement this feature request.
Well I hope they seriously consider it - the scene graph aside,
my current file caching scheme is a complicated mess that would
be greatly simplified and require far less code with weak refs...
Frank.
<http://developer.chaoticbox.com/>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
