I see, I'm thinking upside down. ;-)
Destroying down the tree back to the root would work, but if you
dereferenced the tree at the root it would leave the tree in
memory... hmmm...
I guess this illustrates the difference between reference count based
garbage collection and garbage collection alá Java fairly well. Java
would collect the whole tree once you cut it off at the base, RB
won't because the tree retains references to itself, even though the
program no longer references it.
- Tom
On 06/01/2007, at 4:00 PM, Charles Yeomans wrote:
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>
_______________________________________________
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>
