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

[Martin]

On 04/05/2010 20:11, "Vinzent Höfler" wrote:
>> I fear you've simply no clue about the usage,
>> internals and purpose of dyn. arrays so I stop this discussion.
>>      
> As you always do once someone does not share your point of view, even after you tried so hard to convince him. :P Well, never mind.
>
> Still, dynamic arrays are a bitch, because they only *pretend* to be arrays up to a certain point. Comparing this data type with classes, or even file type (thus, records) is pointless, because those types do not have a counterpart like the dynamic array has in the form of the "static" array.
>
> A class is a class - is a pointer^Wreference type. Always. Ever. In every context. In contrast, an array is an array is - yes, either an array or a pointer. Maybe.
>
> Is it really that hard to admit to the fact, that the design of dynamic arrays makes promises which the abstraction can't keep, rather than neglecting this fact each and every time this discussion comes up?
>
> Yes, of course, a dynamic array is a precise data type you should know how to handle. This would be the end of discussion if it were the only array-like data type. Unfortunately, the point of reference is the old style static array which the dynamic counter-part tries to resemble - and fails to do so.
>
> The dynamic array simply fails the principle of least surprise. No more, no less.
>    

Then the problem is the name, even so it has a different name "dynamic 
array" versus "static array".

They have many difference. And I never heard any one complaining about 
the other differences:

Size:
   Fixed for static
   Variable for dynamyc

Initialization
   None for static (declare it, and access it)
   SetLength for dynamic (access, it before (via []) and get an error)

So why is it a problem, that one is a pointer, and the other not? 
Because it is easier, or more often overlooked.

Then maybe that's a fault of the documentation, not of the data-type?
To me the data-type itself has no surprises at all. But it did need 
proper learning of what it is supposed to be.


You say "array is an array " and I ask where is that broken?

An array is a collection of data elements, which can be accessed via an 
index (kill me, if I used the wrong words in this sentence, I am sure 
you can pick them and turn them against me, but I am equaly sure, you 
can (willingness assumed) detuct what I tried to express.)

I have never found anything that says, that an array (not a 
static-array, just an array), always and under any circumstances must 
ensure that the identifier of the whole array is equal to the first 
data-element in the array?
I don't even think there is a guarantee that all the data elements are 
found at consecutive addresses in memory. (which is also required in 
order to use move)

It may be (or maybe not) that such promises are made for "static array"; 
but should that mean they must be made for every other type of array, 
for any future type of array too?



> Yes, of course, a dynamic array is a precise data type you should know how to handle. This would be the end of discussion if it were the only array-like data type. Unfortunately, the point of reference is the old style static array which the dynamic counter-part tries to resemble - and fails to do so.
>    
So all similar data types have to stick to the same principles?

1) then what between an
- instance of a class
- object (as in "type foo=object .... end")

2) Why bother having 2 data types at all.
If they must be so equal, then they either both *must* use SetLength, or 
none of them must.

procedure Foo;
var a: Array of integer
begin
   a[1] := 7;
end;

why does that crash? It doesn't crash with a static array?, and they are 
both array-like types. According to your words, I would expect the above 
to work...
And now wait, before some one says that's silly. Why can they not 
auto-expand, auto-shrink? If I access an element, then setlength is 
called automatically....


Martin