I dit not follow this thread, but maybe it helps.
Dynamic arrays are located on the heap and are reference counted.
The command System.Move will bypass the reference counting.
For this reason and to be sure the data is available when you need it
use System.Move on stack located arrays an strings only.
On 04/27/2010 08:04 AM, Jürgen Hestermann wrote:
There is a lot of ambigouity with dynamic arrays.
There certainly is if you expect them to work like regular arrays.
They are a quite different datatype.
At least it should always mean the same independent from context.
It does always mean the same, just like a class instance always means
the same. It's just that implicit dereferencing is applied as soon as
you try to access an element (again, like with classes).
That means that identifiers for open arrays are always pointers,
'just' with an automatic dereferencing when using square brackets for
indexing? Then it should be possible to dereference such identifiers
with ^ but it's not. Why? That's the inconcistency I mean: There is no
strict logic behind it.
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.
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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
