[Exceptional C++ Style] Exceptional C++ Style - Item 24: ConstantOptimization

[Balog Pal]

The really short summary of the item: 'const' applied to a reference is just 
a programmer-related local promise and the compiler can't use it for 
anything, optimisation included.  And the purpose of const is completely 
different.

> we don't know
> whether they are really constant at all (IMHO they are likely not to be.
> How many times do you pass a function a const reference to a non-const
> string, for example?)

Those are completely unrelated issues.  const in the function param list 
means "this function supposed not and will not alter the string passed". 
What the caller drops in is the caller's stuff.

> The only way using "const" can help the compiler, is when defining 
> something
> const.  Then it could potentially be put into read-only memory. 
> Personally
> I'm dubious even about this - const_cast (or plain old "C"-style cast) can
> still be used in this case.

Other posts already  cleared that being UB.   When the compiler sees az 
originally const object it can tread it as immutable at will.  It the object 
is a local its unlikely be ROM-ed, but the complier can cache it in 
registers, or do calculations on known state. Despite going through calls to 
functions with unknown implementation. [While objects to which only const 
refs are seen could mutate in those functions!]

> Finally, Herb reveals how const really can allow some optimization.  There
> is in fact one, very specific, set of circumstances in which the compiler
> might be able to use const-ness to generate better code.  This would be if
> the definitions for all of const object Z's functions used in our function 
> f
> are visible, and those functions are all "pretty simple and free of side
> effects".

What is a surprising part of the item, as the same applies to this case as 
written just after: if all those intermmittent functions are inline and the 
compiler follows the data flow, it can prove the state of the object 
unchanged, and any applied 'const' is irrelevant.

And my practice shows compilers like MS did terrific job in data flow 
analysis even 10-15 years ago. To analyse example code for the generated 
assy you had to do all sort of tricks, else all you got was a return 0 from 
main. :-)

And current technology way beyond that. Other articles describe link-time 
code generation and rearrangements after everything is seen.  Or even at 
runtime.  (See Herb's or AA's articles on multithread problems -- old wisdom 
told any function without seen body prevented optimisations and code 
rearrangement, that is outdated.)

> The guideline for this item is therefore: Avoid passing by const value -
> prefer const reference instead, even for cheap-to-copy objects like ints.

An old guideline said const  (non-ref) params belong to the *impelmentation 
details*. So in headers and function interfaces const shall be omitted (it's 
discarded by the compiler anyway). And the implementation can insert cont at 
will if it feels like it.

I rarely see anyone const-ing params despite the fact input params are 
really used as local vars and changed.