Quote:Original post by Anonymous Poster
One example on how the compiler can use const to optimize your code:
struct S
{
int a;
int b;
}
...
S s;
s.a = xxx;
s.b = yyy;
doStuff(s);
...
doStuff(s);
...
doStuff(s);
Assume that doStuff is declared like this:
void doStuff(S& s);
At the first call to doStuff, the compiler must store the variable s onto the stack. Since s is used later and the compiler can't know if something in the doStuff is being modified. The code becomes something like this:
put s.a in eax
put s.b in ebx
push eax
push ebx
call doStuff
mov ebx,[esp + 0]
mov eax,[esp + 4]
call doStuff
mov ebx,[esp + 0]
mov eax,[esp + 4]
call doStuff
If the definition of doStuff is:
void doStuff(const S& s);
You're telling the compiler that s doesn't change during the call and the code could be optimized, more like:
put s.a in eax
put s.b in ebx
call doStuff
call doStuff
call doStuff
This is one place where the const keyword helps the compiler to perform better. And belive me it does. Using const were applicable is really creating better code. I use it everywhere I can.
This is unfrotuantely not true. Unless the compiler knows the definition of doStuff() and can verify that s.a and s.b indeed do not change, this is an invalid optimisation, and can produce incorrect behaviour.
If I (stupidly, granted, but still possible and legal code) decide do make doStuff() do this:
doStuff(const S &s) {
S *nonConstS = const_cast<S*>&s
nonConstS.a += 5;
}
Then the code will no longer behave as expected. This is not the programmers fault, but the compiler's fault for doing an incorrect omptimsation based on things it doesn't know enough bout.
The appearance or lack of const will not help the compiler one iota in this situation optimise your code, unless the compiler already knows the body of doStuff() and can verify that nothing changes.
