I'm a const fiend, and I strive to make everything as const as possible.
I've tried looking at various dissassembly outputs from const and non const versions of functions, and I've yet to see a marked improvement however. I'm assuming compilers nowadays are able to do smart things with non const functions that could technically be const.
Are there still cases where const is useful at the machine level? Any examples?
As far as I know, the only effect of marking a function const is to allow the function to be called on a const
object. There's no optimization benefit.
Herb Sutter has an article which discusses const and optimization in depth:
- http://www.gotw.ca/gotw/081.htm
The one area that const
is useful at the machine level is when applied to data - const data might be able to be placed in non-writable memory.
The primary use of const
isn't to generate better code, but to protect you from yourself, ensuring that you don't accidentally change something you didn't mean to.
It's pretty rare for const to actually help the compiler optimize. You have to keep in mind that the const_cast
can be used anywhere to remove constness from an object (although actually modifying the resulting object isn't always well-defined, it is in some cases, and so the compiler has to be careful about assuming that just because a const object is passed to a function, it won't be modified)
Likewise, the mutable
keyword messes things up. You might pass a const object to a function, but what if that object contains a mutable
field?
The compiler has to do a lot of work to verify that it's safe to assume that an object is really constant -- and by the time it's done all this verification, the const
keyword doesn't really matter, because it could have done all the same analysis on a regular non-const object as well to determine that it isn't being modified and can be treated as constant.
I won't say there aren't a few border cases where the const keyword can enable new optimizations, but in general, const
isn't a performance consideration, but a correctness one. Use it to catch more bugs at compile-time, not to speed up your code.
The purpose of const
is primarily an architectural one. When you declare something as const
you should actually be thinking on what it represents: something that cannot change.
This is not exactly a direct answer to the detailed version of your question, but it matches the title's question.
I like to use const pretty aggressively too, in part because I think there's a minute change it will improve performance, but mostly because it reduces errors and communicates intent better.
- Having const methods allows users the freedom of having useful const objects.
- Having const objects allows library writers to succinctly communicate to users whether a function or method can change the input parameters.
- Having const objects allows you to have the compiler yell at you if you accidentally do something that will modify and object you don't want to modify.
I follow your strategy, and I see it's main usefulness as being to a human. I've adopted a very functional style in a lot of my programming, and const helps enforce that and illustrate that to other programmers who might be reading my code.
In truth, I see some of the new function attributes that C++0x is going to support as being a little more useful for compilers. Knowing that the result of a function depends solely on its arguments, and does not follow any pointers passed to it means that calls to the function can be subjected to CSE.