[fpc-pascal] Dynamic arrays, yet another pitfall

[Jürgen Hestermann]

Am 2014-02-17 10:38, schrieb Lukasz Sokol:
 > To 'write' usually means : changing DATA element(s). That's it.

What else is it when adding or removing elements? The array is modified. That can only mean it was written to it.


 > SetLength is /not/ a write in this sense : because you're resizing the paper you're
 > going to write on (e.g. adding another page or cutting it to size)

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).

Just ask a pupil who started programming recently about what he thinks in this case. Whether he would consider adding or removing elements to an array to be a write operation or not. I suppose you would be astonished about the answers.


 > As far I understood, SetLength is changing the /description/ of the array (meta-data?) but not the data itself :
 > in this sense, it is not a 'write data' operation.

Why is a change not a write? I don't get it. I can only change a variable if I can write to it.


 > It does 'write' as in: change parameters - of the array DESCRIPTION area, but that area is not ARRAY DATA;

That's not true. Before there where 10 elements, now there are only 7. So 3 DATA elements where removed!

Everybody always says that these managed types should be handled like black boxes.
But suddenly it is quite important to know how exactly these types are handled by the compiler.
But when this is so important then it needs to be documented!


 > and enlarging/shrinking the memory allocation - but that does not change the content of the already
 > written-to array elements: it may add some blank ones or remove some written-to ones, but the rest
 > remains UNCHANGED, i.e. they (the just-added or remaining-after-removal ones) are not being written-to
 > by doing SetLength.)

I think you are kidding if you try to make this sound like a clear and fundamental explanation.
With this logic changing only 1 element is not a write either because "the rest remains UNCHANGED".