[fpc-pascal] Illogical automatic dereferencing

Jürgen Hestermann juergen.hestermann at gmx.de
Tue Oct 13 12:29:23 CEST 2009


>> BTW, the expression "@DynamicArray" should really return the address of the first element, not the address of the pointer to the array structure.
> What's wrong with the current solution?
> "the first element" = DynamicArray[0]
> "address of the first element" -> @DynamicArray[0]

You only find this solution if you already know that "DynamicArray" is a 
pointer (instead of the array). Otherwise I would always use the 
identifier "DynamicArray" if I have to feed the array to a procedure or 
function (or "@DynamicArray" if I have to give the pointer to the 
array). I never would use the first element. Why should I? This could be 
even misleading if the index of the first element changes or is unknown 
from start.

> Makes perfect sense :-)

No, it does not because it implies that you already know about the 
nature of "DynamicArray". It is not transparently useable if you change 
between dynamic and static arrays (as was claimed here a lot of times).

>> It somehow destroys the abstraction. And I can't imagine any situation where the pointer might be of the interest for the user of the abstraction.
> That really doesn't matter. What matters is consistency. 

Which does not exist because the identifier "DynamicArray" sometimes 
means the pointer and sometimes the data it points to.

> Pointer to
> variable X is defined as address of the first byte of memory where
> variable X is stored. If you work with pointers to complex data types,
> you have to be aware of internal structure. Otherwise, don't use
> pointers - they are evil anyway :-)

Yes, but you cannot avoid it, if you work with dynamic arrays. You are 
not even told that it's a pointer. That's just the problem.



More information about the fpc-pascal mailing list