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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
