>> I would never expect an assignmet to nil changing anything else than
just the value of the pointer. And for (all?) other pointers this
expectation is valid.
> That expectation is not valid for any reference counted type (be it a
dynamic array, ansistring, unicodestring, COM-style interfaces). That's
the whole point of reference counted types: they keep track of how many
references still exist to the data, and once that reaches zero the data
is freed.
But I just assign a value to a pointer, then I expect it to do just
that: Assign a nil to the pointer. This should be low level and not
create any side effects. Of course, SetLength(0) should take care of
references etc. but not a simple assignment. It's ignoring the will of
the programmer.
>> No. Be aware that my dyn array pointer is part of a larger record
structure which I blockwrite/-read to and from file. When I read back
the structure the pointer is not valid. It's just the pointer at the
time I wrote the file (could be months ago). Now I have to rebuild the
stucture again. To do this I have to the pointer to nil so that
following calls to SetLength have the correct assumption that no data
has been allocated yet.
> The correct way to do so is to call initialize() on the field.
It's not mentioned in the documentation you refered to
(http://www.freepascal.org/docs-html/ref/refsu15.html#x39-450003.3.1).
And I don't need any other routine because fillchar does the job. The
irritation just was, that I expected an assignment to nil doing exactly
the same as fillchar(..,#0). And I am still astonished that it does
more. What other traps are lurking under the hood? It's hard to program
if you have to fight with undocumented "features" instead of
concentrating on my own mistakes...
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
