[fpc-devel] Const optimization is a serious bug

[Max Vlasov]

On Sat, Jul 9, 2011 at 3:14 AM, Martin <fpc at mfriebe.de> wrote:
> On 09/07/2011 00:09, Max Vlasov wrote:
>>
>> The answer is indirect referencing. it's a workaround that probably
>> will solve the problem, but I must admit that I don't know what is the
>> exact performance price. The compiler when it detects const s:
>> ansistring could switch to passing not the actual address of the
>> string, but the address of the variable that holds it. In other words
>> passing PString instead of string. In this case no reference counting
>> or exception frame is probably created and at the same time, if the
>> used string is reallocated occasionally because of a side change, the
>> code will not fail because it will just automatically use the new
>> modified address.
>>
>
> function CRCConstString(constref Str: string): integer;
>
> does what you describe
>

Hmm, it's interesting.. Some observations:
- constref is implemented in 2.5.1, right? Unfortunately I can not
test it right now in 2.4.2, it refuses to recognize it, but I I want
to test it.
- In LCL it used only with interfaces and TGuid's, no strings or other
structures
- there are not much information about constrefs in Lazarus, several
posts, the largest part of them is yours, Martin :) so you're probably
one of the few who really understand it  :)

If constref is what you said , some "quick" fix for those who's scary
of the current const behavior could  be iintroducing a setting in fpc
that forces all const to be constrefs.

Max