[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