[fpc-devel] Modernising Pascal

Jamie McCracken jamie-junk at blueyonder.co.uk
Wed Feb 23 13:05:23 CET 2005

Marco van de Voort wrote:

>>The best solution I can 
>>think for this is to reference count non-component classes. This should 
>>be safe for TObjects but obviously not for Tcomponent descendants (cf 
>>circular reference problem) so a protected variable could be added to 
>>TObject to specify whether to ref count it or not (with TComponent 
>>turning it off).
> This is impossible. 90% of the language wouldn't work anymore as it does
> now, and besides, it would be dog slow. Could be that it gets slower than
> Boehm GC even.

Thats very pessimistic!

Why wouldn't existing code work with this? If you call free on an object 
it would ignore the ref count and free it - so it wont alter how 
existing code works so it certainly should not break anything. You can 
always create a new dialect that has this if you're worried about 
existing code (I take it most of the existing code is using FPC mode 

Is'nt the overhead for reference counting negligible compared to having 
try..finally blocks which the programmer would have to add anyway if we 
didn't refcount them?

(there also pointers for cases where you dont need try..finally)

>>This will improve legibility of code too as there will no longer be a need
>>for having loads of try..finally statements to free stuff.

> How do you free objects then? Those try..finally's are there actually because
> of the refcounting.

The system frees them automatically - there no need to manually add 
try..finally statements. The benefit is clearer code and less chance of 
a memory leak.

>>2. For Each. Its in Delphi 2005 and every modern language implements it.
> Yeah, and I still wonder why. There is nothing to gain with it. 

one less variable to manually declare

>>3. Increasing the number of base types to include common stuff like 
>>lists (Tlist, TStringList). Python does this nicely and theres no reason 
>>Pascal cant.
> I partially agree with you that the container types of Delphi aren't the
> strongest point. However the solution is to make a lib with better types.
> Pulling it in the compiler with ref counting however is something totally
> else, and will make them dog slow.
> Keep in mind that I can walk through 5-6 million (real world) objects in
> just under 2 secs in Pascal/Delphi on an already old 2GHz P IV, and inspect
> them all. Try that in Python.

I know python is dog slow and its far from perfect but it does have 
clearer and more compact code than pascal as a result of ref counting 
stuff and improving the base container types.


More information about the fpc-devel mailing list