[fpc-pascal] dynamic array contents and system.move
juergen.hestermann at gmx.de
Wed May 5 19:21:20 CEST 2010
> 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.
That's just the root cause of the problem: An idenifier should *always* mean the same address in memory. Otherwise you cannot use such low level functions like move and fillchar (or have to learn it the hard way). And these functions (used rarely in special situations) let you do things much more powerful as for example in Java. Pascal has this in common with C. But if you don't get any information about the internal data structure then you cannot use them. Pascal was always very clear about internal data structures so in general it is a surprise that suddenly *some* data types no longer obey the rule that an identifier means the same address (context independent).
> So it is pure luck that for some arrays you can use the identifier on
> it's own, to indicate the first element
That's not true. Static arrays are well defined and this definition should never change.
> 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?
Yes, that's true. You can assign (compatible) arrays directly. Then all elements will be copied.
> If the identifier
> really represented the whole array (as in the whole data), then why does
> it not include it's len
Well, it *does* include the length. For shortStrings element zero contains the length and will be part of the array.
> As for operators represented by the same char, but having different
> "." 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 "^"
Yes, all these things have been added later by violating the rule of context independent semantic.
> So many data types have there own behaviour for various operators....
They shouldn't. It's a confusion of the programmer and makes everything harder to read/write.
> Well the problem is that it isn;t guranteed. someone could implement a
> compiler, where it was not a pointer.
Then it should be a different data type. The same happened to strings: ShortStrings still behave the same since the beginning of Pascal. Noone would change it's internal data structure. If you need something else, create a new one. But please be consistent!
> 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
I don't mean the first element but the beginning of the array! This mostly starts with the first element of course. ;-)
More information about the fpc-pascal