what exactly does the 'const' keyword in c++ mean when it's written at the end of a member function (after the argument list)?
thanks!
+6
A:
It means that *this is const inside that member function, i.e. it doesn't alter the object.
The keyword
thisis a prvalue expression whose value is the address of the object for which the function is called. The type ofthisin a member function of a classXisX*. If the member function is declaredconst, the type ofthisisconst X*. [section 9.3.2 §1]In a
constmember function, the object for which the function is called is accessed through aconstaccess path; therefore, aconstmember function shall not modify the object and its non-static data members. [section 9.3.2 §2]
Oli Charlesworth
2010-10-30 17:53:36
Mat
2010-10-30 17:56:01
and does this help the compiler to optimize the assembly code or what exactly is the benefit?
Mat
2010-10-30 17:57:35
Lie Ryan
2010-10-30 17:58:07
@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
2010-10-30 18:03:20
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
2010-10-30 18:17:00
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
2010-10-31 01:50:17
+1
A:
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
2010-10-30 18:03:11
+3
A:
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
2010-10-30 18:16:44
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
2010-10-30 19:22:56
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
2010-10-30 19:32:14
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
2010-10-30 19:36:32
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
2010-10-30 19:41:20