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 [EMAIL PROTECTED] 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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
