On 6 Jan 2007, at 14:55, Theodore H. Smith wrote:
From: Mars Saxman <[EMAIL PROTECTED]>
Date: Fri, 5 Jan 2007 23:16:41 -0800
On Jan 5, 2007, at 10:46 PM, Mathieu Langlois wrote:
It's actually pretty trivial to implement weak references with a
plugin, all
you need to do is return the object without locking it.
Sounds like a recipie for a crash?
Even my ElfData plugin locks the objects it returns...
This is trivial only because it leaves the hard part of the problem
unsolved. When the object reaches the end of its life, all of these
fake "weak references" will become dangling references, pointing at
an object which no longer exists. Breaking the memory management
system like this is not a good idea unless you have too much free
time and want to spend it solving tricky bugs.
My ElfData plugin has a RingTree class, which does properly
implement "weak references", but only for one tree node to another
tree node :) It's got no bugs in it also.
To be honest, I can't remember another situation except for trees
where I actually needed weak refs. Well maybe a double-linked
list... but my tree is essentially a double linked list with a bit
ontop.
It's also a light class, low overhead. It has only 4 properties,
which take up 16 bytes of RAM altogether, per node. A Child, prev,
next and parent property. So I definitely left it at a light
implementation.
One thing however I really wish my ElfData plugin could do, would be
to use "genericity" or "templates" to C++ people. Then I could make
my RingTree class actually specify that it's children can only be of
one type.
Unfortunately RB doesn't give us templating :(
This means, if I make a tree of files...
the coder could add in some tree nodes for xml nodes, lol. And
there's nothing ElfData can do about that :(
Ideally, I'd make my RingTree unusuable without templating it into a
specific subclass. That is, you couldn't add anything to my RingTree
without subclassing it. And anything you got from the RingTree would
already be have the correct subclass type specified at compile time.
If RB had syntax like this:
class RingTree template MySub
function AddNode(n as MySub)
function FirstChild() as MySub
end class
That's what I mean. "template" would mean that it's a class template
and has no purpose except for being subclassed. And if I DO subclass
it, the subclass's type is specified by "MySub".
That would stop anyone from adding the wrong stuff to the RingTree
AND it would make it easier to use, because otherwise you have to do
this:
dim n as MyXMLNode
n = MyXMLNode(CurrNode.NextSibling)
instead of just this:
dim n as MyXMLNode
n = CurrNode.NextSibling
_______________________________________________
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>
