[fpc-pascal] Illogical automatic dereferencing
Martin
lazarus at mfriebe.de
Mon Oct 12 13:59:10 CEST 2009
Jürgen Hestermann wrote:
>
> What has the one thing to do with the other? It would have been easy
> to introduce dynamic arrays without hiding away its nature from the user.
Easy, maybe / useful, far less
The beauty of the current solution is that static and dynamic arrays can
be substituted with each other, simple by changing the declaration, and
adding/removing a setlength. All other code can be left as it is.
If you needed the "^" for dyn arrays everywhere, then you would have to
make huge changes throughout your code, if ever you needed to change
between static and dynamic arrays.
Now, I do not say that makes it right, neither does it make it wrong.
Someone defined this is the decision and to make this the standard for
dyn-arrays. So now, for any pascal compiler it is the right thing to
follow this standard.
And if you seek a flaw in it: The problem is not with hiding the
internal pointer (works well for classes too), the problem is the
exception. the pointer is not hidden, if you use "move". It would have
been nice if it was hidden there too.
Then again "move" has many more dangers:
- it has now range checks
- it gets you into huge trouble, if the array you moved was an "array of
string" or "array of some_other_dyn_array". Because you ref-counting
gets screwed.
So using move requires you to know a lot about the internals of pascal
anyway. (yes you can find examples that don't, but using move without
the knowledge about the internals, makes it a matter of luck, whether
you run into trouble or not. Someone without the knowledge who had
success with move on an "array of integer" will eventually try it with
"array of string" too)
** Besides this the discussion is pointless. It is the standard now, and
it is not going to be changed. **
Martin
More information about the fpc-pascal
mailing list