[fpc-pascal] dynamic array contents and system.move

Doug Chamberlin dougchamberlin at earthlink.net
Tue Apr 27 14:57:14 CEST 2010


On 4/27/2010 2:04 AM, Jürgen Hestermann wrote:
> An identifier should always refer to a memory address/location. If the 
> type of the data at that memory location is a pointer then it should 
> be possible to change the expression to the memory address of the data 
> by dereferencing it with ^. But for dynamic arrays (and AnsiStrings 
> and other "modern" structures) this is no longer the case which leads 
> to a lot of confusion. To me it's a design flaw.

I agree that the introduction of managed data types is inconsistent with 
previous Pascal data types. Perhaps it is a design flaw to have changed 
the semantics of reference-counted data types. Perhaps not. 
Nevertheless, it has been this way for many, many years and will not be 
changed at this point.

> And the help does not tell about the internals (motto: "you don't need 
> to bother about the internals") but if someone follows this advice and 
> it does not work as expected then here in the list all say "don't use 
> it if you don't know about the internals". But then why not tell the 
> internals in the documentation? If I construct a heavily nested data 
> structure with records and pointers to records how do I know that 
> these "special" things like AnsiStrings etc. don't work as all the 
> other types that made the Pascal language so popular. It was clear and 
> easy to understand but now it is no longer.

Correct. The language is no longer as simple and clear and easy as it was.

The rule now is that you need to know if the data types you use are 
managed (reference-counted) or not. If they are, you must be aware that 
lower-level operations such as Move and FillChar will not work the way 
they did with earlier data types. That is one of the things you trade 
for the convenience of having some details managed for you when using 
managed data.




More information about the fpc-pascal mailing list