[fpc-devel] type discussion

[Jamie McCracken]

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.