Is const good for efficiency?
Author
Besides telling the compiler "don't modify me"?
Does the compiler will do more optimization work for const?
Thx in advance;
What Herb Sutter has to say on the subject
Having a const pointer/reference to an object doesn't mean it is constant, it means you can't modify it, so there aren't as many opportunities for optimisation as might seem.
Having a const pointer/reference to an object doesn't mean it is constant, it means you can't modify it, so there aren't as many opportunities for optimisation as might seem.
int x = 0;void f(const int* p){ std::cout << *p << std::endl; ++x; std::cout << *p << std::endl;}int main(){ f(&x);}
If something is const, mark it as const. Don't bend over backwards to make stuff const when it really isn't.
const-correctness is a very good thing for code quality, and (at least in VS 2003) there _are_ places that the compiler optimizes better when you use const, but in general the compiler will figure things out whether you use const or not.
const is good for efficiency because it will reduce development time by pointing out some kinds of programming mistakes. Less development time means more time left over for profiler-guided optimization at the end.
const-correctness is a very good thing for code quality, and (at least in VS 2003) there _are_ places that the compiler optimizes better when you use const, but in general the compiler will figure things out whether you use const or not.
const is good for efficiency because it will reduce development time by pointing out some kinds of programming mistakes. Less development time means more time left over for profiler-guided optimization at the end.
Quote:Original post by SamLowry
What Herb Sutter has to say on the subject
Having a const pointer/reference to an object doesn't mean it is constant, it means you can't modify it, so there aren't as many opportunities for optimisation as might seem.int x = 0;void f(const int* p){ std::cout << *p << std::endl; ++x; std::cout << *p << std::endl;}int main(){ f(&x);}
Of course, this code is truly terrible. Aliasing like this is, in my humble experience, bad. Assuming I saw no reason to flush the stream twice in f(), I would see no reason, looking at f(), that I couldn't write:
void f(cont int*p){ ++x; std::cout << *p << "\n" << *p << std::endl;}If I were being a good boy, I'd probably spend a couple hours tracking down why the original author placed the ++x; in between the two outputs. If I was being naughty, I'd just change it and get really confused when the results changed.
But that's beside the point since that's perfectly legal code that the compiler must handle correctly. More relevantly, I remember once turning on icc's "tell me why you didn't vectorize everything" option and in many cases it was because it couldn't prove there was no aliasing even though I knew there wasn't. This is why C99 introduced the "restrict" keyword.
Declaring actual variables as const rather than pointers or references gives the compiler more opportunities for optimization and is a good idea for code quality reasons as well. Compilers can definitely take advantage of const declarations on local variables for optimization.
Quote:Original post by mattnewport
Declaring actual variables as const rather than pointers or references gives the compiler more opportunities for optimization and is a good idea for code quality reasons as well. Compilers can definitely take advantage of const declarations on local variables for optimization.
For a local variable, couldn't the compiler just see that it was never modified and do the optimizations regardless of whether or not the variable was const?
Quote:Original post by Deyjaexcept in rare cases.
[...]Const isn't an optimization.
It doesn't matter either way, though, because you should use it wherever it is appropriate and no more or less.
Quote:Original post by Way WalkerQuote:Original post by mattnewport
Declaring actual variables as const rather than pointers or references gives the compiler more opportunities for optimization and is a good idea for code quality reasons as well. Compilers can definitely take advantage of const declarations on local variables for optimization.
For a local variable, couldn't the compiler just see that it was never modified and do the optimizations regardless of whether or not the variable was const?
// Evil might cast away the constness of its argument.void evil (const Vector & p);void good (){ Vector x; const Vector y; for (int i = 0; i < std::eleventy_billion; ++i) { // The compiler cannot assume that "x" won't be modified just because it is // passed as const; casting the const away here has defined behaviour. evil(x); // But here the compiler *can* assume that "y" won't be modified because, // even if the constness is cast away and it *is* modified, the // consequences of doing so are undefined. evil(y); // The compiler can't move this addition out of the loop because "x" might // legitimately have its value changed. do_something(x + y); // OTOH, this multiplication can be moved out of the loop because even if // evil changes the value of "y", the consequences are undefined. do_something_else(y * y); }}(Assuming Vector contains no mutable members.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
