[fpc-devel] Const optimization is a serious bug

[Martin]

On 07/07/2011 14:14, michael.vancanneyt at wisa.be wrote:
> On Thu, 7 Jul 2011, Wimpie Nortje wrote:
>>
>> For me the advantages of using const strings are completely dwarfed by
>> the time required to ensure I keep my side of the promise and still have
>> the risk that some small change in the future will break it without
>> causing compiler warnings.
>
> Well, I program FPC and Delphi since many many years, in a multithreaded
> server environment, and have never encountered a problem with this.
>
> Given this, and the IMHO convoluted examples that were used to show the
> 'problem', I'm inclined to say that you must be writing some pretty 
> strange code to have encountered this problem.

The original example ( a bug on mantis) had little strangeness. A global 
variable being modified in an OnChange handler of a TEdit.
This could very, very easily happen.


I think it is correct to say that there currently is a problem, and it 
starts in the documentation, and results in (many/most) people not knowing.
The extend of this "not knowing" (or at least not fully taking in 
account all consequences) is manifested in both the LCL and the FCL.

Both of them include code, that invites to break the promise. That is, 
it does not in itself break the promise. But I hides the promise made 
from the user, and therefore the user can break the promise without ever 
knowing it was made.
This happens when code provides events (such as many LCL Controls, or 
TStringList)
They accept strings (and there types) as const param to some methods, 
and then call back user code, in an event. This user code can modify the 
originally passed in variable.

Sure it could be said, that if I pass SomeValue to TStringList.Add, then 
I should see that I pass it as const param, and should know that I must 
not change it.
Only:
- These classes (TStringList, TControl) are provided to all users, 
including beginners. They contain no further warning.
- The user may not see the "const" declaration

And the user can not be sure, that he must follow the promise. 
TStringList could internally be protecting the value, and the user would 
not need to care about the promise.

In other words, the fact that such an expert option has been exposed in 
such manner to even beginners, implies that the authors themself had not 
fully reflected all consequences.
( At least in the LCL this has happened due to such unawareness)