[fpc-pascal] Dynamic arrays, yet another pitfall
Martin Frb
lazarus at mfriebe.de
Mon Feb 17 18:01:18 CET 2014
On 17/02/2014 16:40, Jürgen Hestermann wrote:
>
> But changing the size it is a modification! When an array can be
> resized then the resizing means that I have to write to it (in
> contrast to reading, where no data is modified). I am astonished that
> everybody here seems not to see this. Maybe because they already got
> so accustomed to the behaviour that now far-fetched explanations are
> fabricated to make the documentation look right in some sense only
> because it *has* to be right (like a dogma).
In the question really, if the documentation is right? The documentation
(if right) expresses the expected behaviour that the person who designed
the function had intended.
It appears, that the copy-on-setlength is intended. So in that the
documentation is right.
As for this being a good or bad idea, is a different question. (There
are pro and con apparently). But even if we concluded it bad, changing
it now would be by far worse.
Besides I believe it is not possible
setlength(a,10)
b := a;
setlength(a,1200)
The data pointed to by both a and b (before the final setlength) has a
refcount of 2. But it has no info where a and b are. So in SetLength(a,
1200) it is unknown where the other reference (b) is. And that means b
can not follow this change.
Other theoretical solutions would be:
- do not allow setlength, if refcount > 1
- do another level of pointer/referencing
- do a full COW
None of those appeal to me.
More information about the fpc-pascal
mailing list