[fpc-devel] Const optimization is a serious bug

[Martin]

On 07/07/2011 18:14, Alexander Klenin wrote:
> On Fri, Jul 8, 2011 at 04:06, Florian Klämpfl<florian at freepascal.org>  wrote:
>> Am 07.07.2011 19:00, schrieb Alexander Klenin:
>>> Currently, there are four meaninigs of "const":
>>> 1) "Const by value" -- like Integer
>>> 2) "Const by reference" -- like shortstring
>>> 3) "Const by reference, but not really const" -- like objects
>>> 4) "Const by value, excapt rare breakage" -- AnsiString
>>>    (and interfaces, but let's not touch that can of worms in this thread :-) )
>>>
>>> I propose to remove meaning (4).
>>>
>> Unlogical. 2) and 4) are coupled.
> This whole construct is unlogical. Logically, "const a" should mean
> just "assignment to a is a compile-time error".
> But this is not achievable due to compatibility reasons.
> Still, I suggest that (4) is a (small, but still) evil, and sould be removed.

Slightly fresh start.

I do believe the feature itself is a valid feature (the ability for the 
programmer to tell the compiler to skip something like ref counts)
There is a similar feature (via compiler switch) to skip implicit 
exception frames. (With the risk of mem leaks, and what else, if 
incorrectly used.

The current naming may not be the best, since it implies a point of view 
different from the real meaning.

But the current naming is already there, shall we really make everyone 
who used the feature correctly, change their code, because some others 
did not?
Wouldn't that be to punish the ones who got it right.

I don't oppose having compiler switches, and/or directives, to defined 
the exact kind and extend of the const behaviour, so people can choose 
the one they like.
- But I can see, that those who maintain the overall compiler-code will 
cry out in pain, in expectancy of what there will be to be maintained...
- And I am not sure, if any other more correct definitions can be done 
(The problem is, I am not sure, if any other design, does not end up in 
splitting hairs, due to the overlap of tightly coupled issues....)

I agree the fact that objects are not const, if passed as const is not 
consistent. But if that was to be fixed, then objects had to be made 
real const too (rather than further weaken the entire thing)

Anyway back to strings.
I would not oppose (but I am not sure if sensible either) if the 
behaviour for strings could be modified by compiler switch or directive.

To prove or disprove the sense in that, will take a lot of tiny steps, 
and see , if in the end they all make sense. And I will not go into that 
discussion....
Just some ideas what all might have to be considered, extremely 
incomplete list of ideas. Maybe easy to dismiss at first sight, but 
before dismissal they would have to be tracked down a long way, to every 
possible extend. Feel free to dismiss them, I have no intend in proving 
them.

- You mentioned interfaces, well there are dyn-array ref counted too and 
no copy on write. So the earlier example I tried to make on strings 
(with the caching of expressions) it would probably apply to dyn arrays...
Which means trying to change the feature, would create even more and 
more special cases... (or alternatively for all time forbid certain 
optimizations like caching certain results...)

- const should avoid to copy data (only data that is smaller or equal to 
pointer is passed as value). But strings with refcount will be copied 
(if the other/global var with the same data is changed). So adding a 
refcount, means making a copy of the data. Which is fundamentally 
against the stated indent of not copying it...

....