[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