What I mean by "in the long run" is "as the code base grows and ages".
There are many times where you know exactly what you mean when you originally write a function, but months/years later, when you're not thinking about it, you end up mis-using it. This can be avoided by being more explicit in your code.
Here is an example, which while derived, does reflect a situation that I've seen in the past:
Code: Select all
class MyClass{
public:
std::string showData(){return myData;}
private:
std::string myData;
};
I can happily use "MyClass:showData" any time I want to see what data "MyClass" is storing. But what if later, someone decides to rewrite the "showData" method?
Code: Select all
std::string MyClass::showData()
{
myData = myData.append("_");
return myData;
}
This is obviously a poor coding practice, but there is nothing in the class definition that prevents this. If instead, MyClass had been defined as:
Code: Select all
class MyClass{
public:
std::string showData() const;
private:
std::string myData;
};
Then you are being very explicit to the user that this method does not modify MyClass at all.
"const" becomes even more useful when you begin passing values around by reference. Consider the following:
Code: Select all
class MyClass{
public:
void doSomething1(LargeClass data);
void doSomething2(LargeClass& data);
void doSomething3(const LargeClass& data) const;
};
The "doSomething1" version is undesirable, since every time it is called a copy of "LargeClass" is made, which will probably be an "expensive" function.
"doSomething2" is better, in that it does not make a copy of "LargeClass". Rather, it uses whatever instance the caller has on hand. However, this version is dangerous in that it could mutate "LargeClass", and the caller may not be expecting it. If instead the function were named, say, "modifyLargeClass", this would be less of a concern.
Finally, "doSomething3" would be the preferred way to define this method. As you can see, it makes it explicit that:
- I require a "LargeClass" in order to do my business
- I do not need to modify the "LargeClass" in order to do my business. Thus, I will accept a reference in order to save memory
- I do not need to modify myself to do my business
If "const correctness" is used reliably throughout the code base, then using "doSomething2" is no longer scary. This is because the user explicitly knows:
- I require a reference to an existing "LargeClass" in order to do my business
- I may modify the reference to "LargeClass" that you give me
- I may modify myself while I am doing my business
I could go on, but I do not wish to belabor the point. Besides, it seems that it is mostly a personal preference of yours to stay away from c++/const altogether, and really, what can I say about that but cheers!