[fpc-devel] 0026080: Access by index to dynamic array may be failed

Martin Frb 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)

My understanding:
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 
same too.

// 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 mailing list