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

[Martin]

On 05/05/2010 06:34, Jürgen Hestermann wrote:
>> So why is it a problem, that one is a pointer, and the other not? 
>> Because it is easier, or more often overlooked.
>
> The problem is not that one is a pointer (to an array) and the other 
> one is the array itself. That would be fine if it is told to the 
> programmer that way and if it would be consistent. But then why am I 
> not able to derefference this pointer with MyArray^? Why can I use an 
> index on that pointer? In these cases it does *not* behave like a 
> pointer but like an array. That's what makes it ambiguous.

Let me rephrase my own words: "That one of the 2 arrays is implemented 
using a pointer"

Of course you are right it is an array, both of them, and both of them 
behave like that.

And as also explained in my original mail: An array does not guarantee 
that the identifier(stand alone) can be used for the first element.
So it is pure luck that for some arrays you can use the identifier on 
it's own, to indicate the first element

Oh and to make another point.

people seem to believe that because on static arrays you can do 
"move(src, dest, len)", that would mean the identifier represents the 
whole data of the array?
Because that assumptions fails even for static arrays. If the identifier 
really represented the whole array (as in the whole data), then why does 
it not include it's len


As for operators represented by the same char, but having different 
meanings:
"." on a record or the instance of a class => exactly the same thing => 
the instance of a class is internally a pointer.
"+" on a pointer: it doesn't just add the number, it adds the size of 
the pointed-to-type as often as specified
"()" on a method-pointer or procedure pointer: it acts like 
dereferencing it, after all you access (call) the procedure to which it 
points; but there is no "^"

So many data types have there own behaviour for various operators....


>
> So at least I would expect that these realy confusing things are 
> clearely explained in the help so that a programmer is not lead to 
> false assumptions. Say that it is a pointer to an array (and do not 
> let the user think it is "an array"!). And say that although it is a 
> pointer you still cannot derefference it but you need to use the first 
> index to get the beginning of the array.

Well the problem is that it isn;t guranteed. someone could implement a 
compiler, where it was not a pointer.

I haven't looked at the documentation, but it should probably point out 
for *all* arrays, that you should not use the stand alone identifier, 
when really you mean the first element
And IIRC the doc at least contains that assignment between two array, 
creates a shallow copy => so you could check out what that means.

But as I said, I havent recently looked at the doc. maybe it needs 
improvement.
Maybe this is better solved, by adding warning to procedures like "move".

but then again, you get the same results, when doing:
procedure x(var a: TIntArraray);

except, no one is probably going to use that, unless they already 
understood what it means. (I can't thing of a case where it was needed, 
but then neither a case where it would hurt.

procedure x(var a: TSomeClass);  is useful by the way

Martin