[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