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

José Mejuto joshyfun at gmail.com
Wed May 5 13:44:40 CEST 2010

Hello FPC-Pascal,

Wednesday, May 5, 2010, 8:54:01 AM, you wrote:

>> architectures. Much better would be "move
>> (array1[0],array2[0],elements*sizeof(element))" but even in this case
>> the result is undefined, but it is a bit more exact as the programmer
GG> Now this is a perfect example, of why I love Java (at least what I have
GG> seen of it - I am no Java expert). In your example, the developer need to
GG> have knowledge of the internal structure of an array before they can use
GG> the move() function. Java and good programming practices like OOP states
GG> that you should try and hide the internal structure from a client using
GG> your structure. This gives you the freedom to change the internal structure
GG> without the need to change client code. This is the reason why things like
GG> Iterator exists in design patterns.
GG> What if move() and the developer assumes the data is one continuous block
GG> of data, when in fact it might not be. [I don't know internal structures of
GG> FPC] Seeing that dynamic arrays are a collection of pointers (I think I
GG> understood this correctly), each memory block pointed to by each pointer
GG> could be in a totally different memory location. So copying a continuous
GG> block of memory will result in rubbish data as a result.

The same applies to Pascal, my previous example is badly designed, but
better than the first one. The problem here is try to use "move" as a
Pascal way of do things. Move is low level function that should be
used to optimize code when you known underalying structure, if you do
not known this one you should copy/move element by element:

for j:=Low(ArraySource) to High(ArraySource) do

Is the same as complaint about fpc not assembling X86 ASM in a PPC
platform :-? Yes, both are assembler but you must use the assembler of
the underlaying architecture.
Best regards,

More information about the fpc-pascal mailing list