Danny Milosavljevic wrote:
you *might* have less overhead using ref count on a tstringlist then
making it a component (if you are creating more than one reference to it
or passing it as a parameter to a function then yes a component would be
more efficient). You also have the problem of what you are going to set
the owner to in the case where its only a temp variable.
owner nil, and free later
yeah and now you are back at manual management.
ref cycles are not a big deal - show me one bit of the FCL that has
cycles using Tobjects only (IE not with Tcomponents)!
I dont know the fcl enough for that.
But generally speaking, most (nice) trees have that problem actually.
Good point but are trees like that the exception or the rule? I mean
Delphi's TTreeview's TTreeNode is not cyclic AFAIK.
however they are better implemented using Tcomponent where the parent
objects can automatically free the children. In any case we would need
weak refs to overcome problems like these in tobjects.
so in your code we would have something like:
b.Parent := weak (a);
where weak() prevents the ref count from incrementing. Or a quick hack
would be to manually dec the ref count (assuming we provide a public
Tobject method for this) after that assignment. What we shouldn't do is
rely on the developer who is using the class to nil it at the end cause
that defeats the whole purpose.
I admit its not perfect but exceptions like these should hopefully be
few and far between.
Its obvious that you wont have cycles in things like TstringList,
TFileStream objects etc.
In fact only in Tlist are you likely to have cycles and in the add
method you could check to make sure no self references are added and
throw an exception if they are. A knowledgable developer can of course
set any object to nil if he knows that there are or likely to be cycles
but again this will only happen in a very small minoirty of cases.
For gui stuff, it like happens all the time...
Absolutely, which is why components will not be ref counted
for tree stuff, it like
happens all the time ... hmm
dunno - its hard to say how common occurances like your example are as
all the trees I have recalled using have not been cyclic like that.
I would implement ref count on TObjects with a protected boolean
variable to turn it off for TComponent descendants as we dont need to
ref count components and components by their nature are far more likely
to have cycles then plain objects.
Its also obvious that pascal by its nature is far better suited to
efficient ref counting than others like java because java strings are
objects and ref counting a whole load of short term objects can
adversely affect performance. (imagine deleting a stringlist where all
and pascal strings are ?
records or pointers to records. If you use shortstrings then it will be
fast cause they are not ref counted. Java strings by comparison are
classes so they will always suck in this regard.
jamie.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
