85

What exactly does the const keyword in C++ mean when it's written at the end of a member function (after the argument list)?

artm
  • 17,291
  • 6
  • 38
  • 54
Mat
  • 2,713
  • 5
  • 25
  • 25

3 Answers3

97

It means that *this is const inside that member function, i.e. it doesn't alter the object.

The keyword this is a prvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. If the member function is declared const, the type of this is const X*. [section 9.3.2 §1]

In a const member function, the object for which the function is called is accessed through a const access path; therefore, a const member function shall not modify the object and its non-static data members. [section 9.3.2 §2]

This means that a const member function can be called on a const instance of the class. A non-const member function can't be called on [1]a const object, since it could potentially try to modify it.

[1] Note: a temporary is not a const object unless it's of const type.

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
  • ah ok thx! and how do I get inside such a const function a pointer to a member variable? if i try `int* ptr = &m_value` I get a `C2440 const int * can't be converted to int *` – Mat Oct 30 '10 at 17:56
  • and does this help the compiler to optimize the assembly code or what exactly is the benefit? – Mat Oct 30 '10 at 17:57
  • 2
    @Mat: declare your variable as a const as well: `const int* ptr = &m_value` – Lie Ryan Oct 30 '10 at 17:58
  • 4
    @Mat: No, it has nothing to do with optimization. It's all about `const` correctness. Any reasonable compiler is going to be able to figure out on it's own what is constant when applying optimizations. Plus, declaring a member function `const` doesn't really help the compiler immediately, because the `const` can be `const_cast` ed away. (Though in general you should NOT do that). – Billy ONeal Oct 30 '10 at 18:03
  • 2
    It's mostly useful when designing libraries/internal APIs, as it promises to the user of said API that this member function call won't mess with the data. It's also worth noting that if the user for some reason has a const variable of that class type, they can only use const member functions. – jkerian Oct 30 '10 at 18:17
  • 2
    The answer should really be `*this` is `const` inside that member function. It's the object (what `this` points to) that is const. – Ben Jackson Oct 31 '10 at 01:50
  • 2
    Actually, the `const` means the function _promises_ not to alter the object. It can circumvent or even violate the promise. It might be useful to elaborate on bitwise vs. logical constness. And a hint to `mutable` might be a good idea as well. – sbi Nov 20 '10 at 16:55
41

const at the end of a function signature means that the function should assume the object of which it is a member is const. In practical terms it means that you ask the compiler to check that the member function does not change the object data in any way. It means asking the compiler to check that it doesn't directly change any member data, and it doesn't call any function that itself does not guarantee that it won't change the object.

When you create a const object you are asking the compiler to make sure that that object does not change beyond its initialization. That in turns means that the compiler will check you don't directly change its member data and that you don't call any function that does not guarantee it won't change the object.

This is all part of the const correctness philosophy. In essence it means that if things work right now and they won't change then they will never break. In other words, constant things are easier to work with reliably. This const thing at the end of function signatures is a tool for you to prohibit things from breaking. This in turns means you should put const everywhere you possibly can.

wilhelmtell
  • 57,473
  • 20
  • 96
  • 131
  • thanks for this explanation. are there any arguments against using const in a function that doesn't change the object? I feel that software could get less flexibly maintainable if you suddenly decide for example to change some design and need to call a non const function in a currently as const declared function and then maybe a big chain of functions that call this function have to be changed too – Mat Oct 30 '10 at 19:22
  • 1
    No, there is no argument against using a `const`. That is, unless you know right now, at the time of designing your class, that a member function should be allowed to change the object. It's a design question that you should ask yourself early on, and it should easy to answer. It's not about "leaving the door open for later". Rather, it's about whether the function **should** change the object or **should not** change it. It's a yes/no question, black or white, with nothing in between, and it should be easy to answer. Note: it's not about **may** it change the object, but **should** it. – wilhelmtell Oct 30 '10 at 19:32
  • 1
    This in turn means the const-correctness philosophy forces you early on to be very conscious about what each function does. It forces you to decide and be very clear about the raison d'être of each of the member functions. That's a Good Thing. What you're asking is to leave a door open for changing the raison d'être of a function, and that's a Bad Thing. You should only change **how** a function gets what it's meant to do done, not **what** it does. Think about the users of your API (which well be you yourself). Don't pull the rug off their feet! – wilhelmtell Oct 30 '10 at 19:36
  • 1
    When users create a `const` object they can only call `const` member functions on that object. Remember that. So we're talking about designing an interface here: what a user may and may not call. This is an early decision. If you "leave a door open" by not defining a function as `const` then you prohibit that function from being called in the `const` object circumstance. Users like `const` objects because, well, the object then doesn't change and hence doesn't break things. Design for allowing that. – wilhelmtell Oct 30 '10 at 19:41
12

Compiler optimizations are possible, but the main benefit is in enforcing the contract expressed in the function's declaration - if you define a member function as const, the compiler prevents any modification to the object inside that function.

You can exempt individual fields in the class from this restriction using mutable in their declaration. This is useful for example when you have a class that encapsulates its own lock_guard, which must change its value to enforce thread safety even within const member functions.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140