[fpc-devel] type discussion

[Jamie McCracken]

Danny Milosavljevic wrote:
> 
> I'd suggest creating tlist, tstringlist, tfilestream-like things with an
> optional owner (TComponent-like). I've been programming delphi for
> years, and trust me, I know how annoying keeping track of tlist memory
> is (and I mean _annoying like *@! hell_ :)). Of course having to cast
> around list content is even more annoying. But 'm trying to fix that
> now, in fpc.

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.


> Setting a reference to nil works automagically (user doesnt need to do
> it).
> Only remaining serious problem are reference cycles. And thats a BIG
> problem (see old java versions and swing, and you will see... its the
> horror).
> But it still 'only' means you have to set 'some' references to nil
> manually. Which is ugly. Either all or none would be cleaner :)


ref cycles are not a big deal - show me one bit of the FCL that has 
cycles using Tobjects only (IE not with Tcomponents)!

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.

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 
the strings are objects - you would have to call dec_ref on all the 
strings and thats why ref counting is considered slow especially with java)

I am asserting that ref counting in pascal would probably have a much 
lower effect on overall performance as a result. Ref counting objects 
with long life spans is actually far more cpu efficient than any GC 
scheme (and thats why the best performing GCs are hybrid GCs which 
actually ref count globals and all objects that survive multiple 
generations). In fact unless you are creating loads of temporary short 
lived objects in your code, the overhead of ref counting should be 
acceptable in most cases and of course you can optimise your code for 
ref counting by using more global vars instead of temps/passing them as 
parameters to functions etc.

But we cant test out any of this until we have c++ style exception 
handling so its performance or lack of performance is just speculation 
at the moment.

jamie.