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

[Jürgen Hestermann]

> At best, one day we may add GPC-compatible array schema types (see 
> http://www.gnu-pascal.de/gpc/Schema-Types.html, the part under "As a GNU 
> Pascal extension, the above can also be written as"). These don't hide 
> anything.

Yes, that looks good as it does not violate the rule that an identifier 
should mean the same memory address independent from context.

>> A simple solution would be to use the address the pointer is pointing 
>> to (address of first element) for fillchar/move too.
> It would break code like this:
> type  tbytedynarr = array of byte;
> var   a: array of tbytedynarr;
> begin
> setlength(a,10);
> { initialise all dynamic array elements of a}
>   ...
> { now delete one of these elements }
> finalise(a[4]);
> { and compact the array }
> move(a[3],a[4],(length(a)-3)*sizeof(a[0]));
> end.
> With your change, move() would operate on the contents of a[3] 
> tbytedynarr instead of on the contents of "a" itself.

Yes, that's a problem because a[0] and a[0]^ are not distinguishable. 
Although I would have expected that special procedures exist to insert
and remove array elements so that there is no need to do such things 
manually which also requires knowledge of the exact handling of dynamic 
arrays which is not fully documented so you are never sure.
For example, in the above example, a[10] still exists and 
points to the same data as a[9], correct? And how do I *insert* elements?
I would need to extend the allocated memory but how to do that without 
distroying reference counters etc.?


It could also be the other way round and the correct syntax could 
be at least *allowed* (besides the automatic dereferencing):

A dynamic array would then be stated to be a *pointer* to 
an array (as it's already the case for move/fillchar etc). 

"MyArray" would be (the address of) the pointer and 
"MyArray^" would be (the address) of the data. 
The latter would be the same address as "MyArray[0]"
(although it would mean the whole array). 

"MyArray^[0]" could be allowed and could still be abreviated 
to "MyArray[0]" so both could be made syntactical correct (though 
"MyArray^[0]" would raise an expection if "MyArray" is nil).

Length(MyArray) would be the same as Length(MyArray^).

SizeOf(MyArray) would be pointer size (4 or 8 bytes) as it's now.

SizeOf(MyArray^[0]) and SizeOf(MyArray[0]) would be the size of 
an array element (dependend on type) as it's now.

SizeOf(MyArray^) would be the size of the allocated raw data 
(Length(MyArray^)*sizeof(MyArray^[0]) without auxilliary data 
like reference counter etc.).

I am not sure whether this would be doable or whether this raises 
new problems within the parser or so. It would allow programmers 
to work with a clear, logical and unambiguous syntax.