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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
