[fpc-devel] 0026080: Access by index to dynamic array may be failed
lazarus at mfriebe.de
Mon Apr 28 03:12:47 CEST 2014
Reading this bug, I came to an interesting question. (Purely out of
academic interest / not really interested in the final decision to the bug)
A property guarantees that the accessor can be changed between "direct
field access" and "getter/setter method".
Code using a property should not be affected by such a change to property,.
To which extend is that statement correct?
Certainly, there is a gurantee that you can change a field property to a
getter propert, and it will still compile (that is why
"inc(Foo.PropBar)" does no longer compile)
Is there a guarantee, that if that getter return the same value, as the
previous field access, that the behaviour of the code using the property
will be kept exactly the same? (at all levels of code optimization /
with the exception to cpu cycles used)?
And if there is, does it also exist (does the guarantee exist) in
reverse. That is when changing a getter to field? It should, otherwise
the behaviour in the former case would have been altered.
But if that is true, if a property gurantees to hide the difference
between field and getter, Then the 2 properties in the bug should be the
// Actual access to the field is indeed not guranteed to work
item := TRec.FItems[TRec.RegisterItem(Index)];
FItems = dyn array
TRec.RegisterItem => SetLenght(FItems, ...)
But with the property?
In the bug the statement is about evaluation order. And there is no
guarantee to that. But that is not what is asked for. It is about
behaviour for the property being exactly as if it was a getter. (unless
you can make the getter to fail too, then both will behave the same)
More information about the fpc-devel