...You know a programmer who gets confused by the word "const"?
Not in general, but it partially obscures situations and requires more time to understand a context. The problem of overusing a language feature is that you don't differ anymore between important and useless cases.
In my opinion, a crucial point in designing a robust API entails making interfaces as expressive as possible already by language features, one of which is const. I primarily make sure that function
interfaces are const-correct. In other words: I keep const for the important uses, so that I immediately see respective semantics. The expressiveness decreases when I use const wherever possible.
Which doesn't mean I don't declare other variables const. However, I only do it when it really brings an advantage. A counter-example:
class Person
{
public:
Person(const std::string& name, const Date& birthDate);
private:
std::string myName;
const Date myBirthDate; // can't ever change, so make it const
};Nice, by writing that single const I've just now disabled Person's value semantics and prevented Person objects from ever being stored inside STL containers. It's important that not every const increases const-correctness and that some – to the contrary – even result in bad effects, of which the increasing complexity is only the most obvious one.
There is another problem: consistency. Would you place a const here?
void MyClass::SetValue(const int value)
{
// prevent value from accidentally being modified
myValue = value;
}If not, why not? Because the function is too trivial? Yes, but that applies to many functions. Where do you place the border? And what if you declare SetValue() inline? Then the interface is again spilled with useless information.
What's your basis for believing that? It's been my experience that C++ programmers generally go out of their way to const-qualify when a passed value won't be changed, copy or not.
It's my experience from looking at code. SFML is such an example, the C-library OpenGL is another one. I just skimmed through some Boost and MSVC++ StdLib headers, and I never saw a top-level-const in a function declaration.
Why isn't it relevant for you if the parameter is copied or not? You can't change the original value inside the function, and that's the only important thing for the caller. You can create thousands of further copies and modify them, the caller cannot prevent that. But he can prevent that his value is changed.
By the way, Herb Sutter seems to share my opinion.
http://www.gotw.ca/gotw/006.htm[/url]"]Since the point object is passed by value, there is little or no benefit to declaring it const.
Normally const pass-by-value is unuseful and misleading at best.
Of course, the whole topic is also a matter of style. I personally like expressive code, and I don't like redundancy or irrelevant information. But we should at least agree that top-level const-qualifications in function declarations (not definitions) are meaningless.
