27

As stated in book Effective C++: "Use const whenever possible.", one would assume that this definition: Vec3f operator+(Vec3f &other); would be better defined as Vec3f operator+(const Vec3f &other) const; or even better as const Vec3f operator+(const Vec3f &other) const;.

Or an example with 5 const keywords: const int*const Foo(const int*const&)const;

Of course, you should only include const where there can be one. What Im asking is it a good practice to use them whenever possible? While it does give you more error safe code, it can get quite messy. Or should you, for example, ignore pointer and reference const (unless you really need it), and use it only on the types itself, as in const int* Foo(const int* parameter)const;, so it doesnt end up too messy?

Additional info: http://duramecho.com/ComputerInformation/WhyHowCppConst.html

Thanks in advance!

Improve this question
16
  • 9
    Putting a top-level const on the return type has lost its value in C++11, but other than that, yes, const-correctness helps. Commented Mar 9, 2014 at 17:55
  • 3
    Pointer and reference const is far more important than value const when passed as function argument. When passing by value, you are passing a copy, unlike when you pass by pointer or reference. Commented Mar 9, 2014 at 17:58
  • 6
    You should pass function parameters by const reference if the function doesn't modify them, looking messy is irrelevant. A member function should be const if it doesn't modify the object, looking messy is irrelevant. Commented Mar 9, 2014 at 18:06
  • 1
    @PetrBudnik, const on parameters passed by value is ignored completely, so it's not just less important, it's unimportant Commented Mar 9, 2014 at 18:08
  • 1
    @JonathanWakely What do you mean "ignored"? Try compiling void foo(int const a) { a += 1; }... If you are not using const on value parameter and change it by mistake, you are changing copy. Unlike with reference or pointer. So it's not that big of a deal not to use it in function declaration. But if you use it, it is not ignored, it is enforced by compiler even for copy. Commented Mar 9, 2014 at 18:24

5 Answers 5

Reset to default
8

C++ FAQ:

If you find ordinary type safety helps you get systems correct (it does; especially in large systems), you'll find const correctness helps also.

You should use const when you want to be sure not to change variable accidentally or intentionally. Some constants (globals and class static, strings & integers, but not variables with nontrivial constructor) can be placed in read-only parts of the executable, therefore result in segmentation fault if you try to write to it.

You should be explicit using const as a specifier on functions that follow this principle as well as on function arguments. If you don't have to change actual argument, make it const. This doesn't limit the possible usages of such function, but extends them, because now they might be used on const arguments, and on const objects.

In declaration

const int* foo(const int* const&) const;

every const means something different and yes, obviously it should be used if it is needed.

Summary

Using const increases type-safety of your program.

C++ FAQ:

[18.3] Should I try to get things const correct "sooner" or "later"?

At the very, very, very beginning.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

6

Using const whereever possible is generally a good thing, but it's a bad wording. You should be using const whereever it is possible and makes sense.

Above all else (it may, rarely, open extra optimization opportunities) it is a means to document your intention of not modifying something.

In the concrete example of a member operator+ that you have given, the best solution would not be to make everything const, but a freestanding operator+ which bases on member operator+= and takes one argument by value like so:

T operator+(T one, T const& two) const { return one += two; }

This solution works with T appearing on either side of the plus sign, it allows for chaining, it doesn't replicate code, and it allows the compiler to perform the maximum of optimizations.
The semantics of operator+ require that a copy be made, so you can as well have the compiler make it (the other one will be optimized out).

It would be possible to make one a const&, but then you would have to manually make a copy, which would likely be sub-optimal (and much less intellegible).

Improve this answer

Comments

2

When using const you are telling the compiler something.

It can then use that information to check that you are not doing something that you should not be doing and also enables it to optimize the code.

So when using const it enables it to be smarter.

Improve this answer

4 Comments

Using const almost never helps optimization, if the compiler can tell whether you're modifying an object or not then it can perform the same optimizations without needing const. See gotw.ca/gotw/081.htm
Once you start to use const it can also cause unnecessary creation and destruction of temporaries. eg Passing a const object to a non cost parameter when the function does not modify the object. You need to use it consistently to get the benefit.
@QuentinUK I dont think so. Lets consider the situation: If you pass by value, a copy is always made if its a lvalue, whether its const or not, period. If you pass by reference though, you simply cant pass your object, because the compiler assumes that the object can be modified. So yes, if you want to pass your object nonetheless, you will have to create a copy (explicitely). But that is not a bug, its design.
I think I've seen this due to a "feature" of VS2010, stackoverflow.com/questions/7189420/…
0

I think that using const whenever possible is a good way to go. It adds implicit documentation to your code and increases type safety, as noted by the other answers.

It's nice to know that you can call const functions without having to worry about whether they change an object's internal state and that passing const pointers or references to something other object will keep it safe from encapsulation breakage. It also lets objects owning const references get the most value out of whatever that reference is pointing to.

Also, applying const from the get-go is a good idea because it can be a pain to add later. For example, if you have a class:

class A { public: //... int getCount() { return m_count; } private: int m_count; }

And another:

class B { public: //... int getInternalCount() { return m_a->getCount(); } private: A* m_a; }

And you want to do:

void foo( const B* b ) { int count = b->getInternalCount(); //-- Do something }

This is a perfectly valid use case, but you then have to go and add const to multiple places to support it (B::getInternalCount() and A::getCount()). If you do it from the very start, it's actually quite easy to use const and it makes the design much more obvious to other developers. If you're working on your own, it still helps a lot, but it's not as much of a concern. When working in a team, though, I found it really helped when we started enforcing const and retrofitted some of our legacy code to adhere to it more.

Long story short: I recommend always using it.

Improve this answer

Comments

-1

The original purpose of const is to deal with problems, which arise when you use magic numbers and hard-coded values in general.

A bit stupid, but picturesque example to show the point. Such code is error-prone and inconvenient.

c1 = 3.14159 * diameter1; c2 = 3.14159 * diameter2;

You'd rather be better defining Pi as a constant.

const double PI = 3.14159; c1 = PI * diameter1; c2 = PI * diameter2;

Compared to variables constants have "priviliges". In your example it makes sense to pass other vector by const reference, because thanks to this function will accept temporary (rvalue) as its parameter.

Vec3f operator+(const Vec3f &other) const; // Would not be possible with Vec3f operator+(Vec3f &other) const; Vec3f v = u + Vec3f(1, 0, 0);

With constexpr you can use constants in contexts such as for example static array allocation

constexpr std::size_t LENGTH = 10; int arr[LENGTH];

So it's not to prevent you from accidentally setting some random value (you would have to be exceptionally stupid programmer to make such mistakes). It does not make sense to use it whenever possible, but only when you want to specify a constant.

This is not the first time I see weird statements from "Effective C++".

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.