On 4/27/2010 2:04 AM, Jürgen Hestermann wrote:
An identifier should always refer to a memory address/location. If the
type of the data at that memory location is a pointer then it should
be possible to change the expression to the memory address of the data
by dereferencing it with ^. But for dynamic arrays (and AnsiStrings
and other "modern" structures) this is no longer the case which leads
to a lot of confusion. To me it's a design flaw.
I agree that the introduction of managed data types is inconsistent with
previous Pascal data types. Perhaps it is a design flaw to have changed
the semantics of reference-counted data types. Perhaps not.
Nevertheless, it has been this way for many, many years and will not be
changed at this point.
And the help does not tell about the internals (motto: "you don't need
to bother about the internals") but if someone follows this advice and
it does not work as expected then here in the list all say "don't use
it if you don't know about the internals". But then why not tell the
internals in the documentation? If I construct a heavily nested data
structure with records and pointers to records how do I know that
these "special" things like AnsiStrings etc. don't work as all the
other types that made the Pascal language so popular. It was clear and
easy to understand but now it is no longer.
Correct. The language is no longer as simple and clear and easy as it was.
The rule now is that you need to know if the data types you use are
managed (reference-counted) or not. If they are, you must be aware that
lower-level operations such as Move and FillChar will not work the way
they did with earlier data types. That is one of the things you trade
for the convenience of having some details managed for you when using
managed data.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal