[fpc-devel] Const optimization is a serious bug

[Martin]

On 09/07/2011 02:14, Chad Berchek wrote:
> Specifically, the way const is now "defined" (or not...) is disturbing 
> because it leaves out important details. In C++, you can pass by value 
> or reference, or by pointer which is a value but is used to make 
> references. But what's important is you _always_ know what it's going 
> to do. If you pass something by reference and modify that instance via 
> another reference, they're all going to change, because they are the 
> same instance. And if you pass by value, it's the opposite. The point 
> is, though, you always know what it's going to be.
>
> Imagine if we took C++ and redefined the pass by reference syntax as 
> "the compiler might pass by value or reference, depending what it 
> feels like". Result? Boom. Tons of carefully written code would 
> suddenly break.
>
...
> If we *knew* that const meant it would be by reference, then that 
> immediately eliminates the confusion in the case of ShortString and 
> records; modifying one instance through several references affects 
> them all, as expected. What the programmer says happens; there can be 
> no "bug", except in the programmer's own knowledge.
>

We do know:
http://www.freepascal.org/docs-html/ref/refsu58.html#x135-14500011.4.4
> A constant argument is passed by reference if its size is larger than 
> a pointer. It is passed by value if the size is equal or is less then 
> the size of a native pointer.

Of course if you want to rely on this, you must ensure the size of your 
type does ot change (a records definition can be chnaged, and that would 
have consequences for "const" param). But then, if you rely on it, but 
some compiler $IF and $FAIL in the code, to ensure it only compiles if 
your assumptions are met.

Personally I thing this page would be a good place to document the 
properties of "const" param with regards to ref-counted types...