Motivation for mutable in C++

Question

Possible Duplicate:
C++ 'mutable' keyword
When have you used C++ 'mutable' keyword?

I understand what mutable means and how it is used, What I would like to know is what is the real motivation behind its existence. I don't think the only motivation is to bypass the immutability of this in const member functions I rather think there is something more to it.
I don't think it is just a means to bypass problems in poorly designed systems? or is it?

An obvious offshoot of the original question when does using mutable makes sense even in a good design?

http://stackoverflow.com/questions/4554031/when-have-you-used-c-mutable-keyword — DumbCoder, Apr 18 '12 at 15:12
@DumbCoder: Thanks for the link but that doesn't answer my question. — Alok Save, Apr 18 '12 at 15:14
That wasn't the answer, it was more for your offshoot question. — DumbCoder, Apr 18 '12 at 15:15
Yes it does - it gives good examples where you might want to "bypass const" which are not "poorly designed systems". — Ben, Apr 18 '12 at 15:15
@DumbCoder: Well folks here in So don't actually read anything but just run around marking anything that gets posted related as duplicate. 2 votes to close already. — Alok Save, Apr 18 '12 at 15:15
@Als: You have to understand that it makes sense to vote as duplicate. While not exactly a duplicate it is understandable to claim that the answer to your question is to support the answers to the other questions in the language. — David Rodríguez - dribeas, Apr 18 '12 at 15:20
@DavidRodríguez-dribeas:As per the SO policy Q's are to be vote closed as duplicate if they are exact duplicates.A little search on meta would bring up that thread if need be.That being said my motivation for asking the Q is not rep farming I have plenty of those so called rep and I seriously don't need any in this manner.My motivation was to understand subtle detail, which an answer like yours nicely reveals.I fail to understand the mob mentality here in SO which jumps to close down anything that is remotely relevant.It gets increasingly difficult to learn anything new with this attitude . — Alok Save, Apr 18 '12 at 15:33
@Nawaz: Lookup James or David's answer, that should tell you what I was looking for. — Alok Save, Apr 18 '12 at 16:23
@Als: You want more answers with more text in it than *something different* answer. — Nawaz, Apr 18 '12 at 16:25
@Nawaz: Sorry, Your comment makes no sense to me.[End of conversation] — Alok Save, Apr 18 '12 at 16:27
@Als: Neither yours makes sense to me [End of the conversation] ;-) — Nawaz, Apr 18 '12 at 16:29

score 12 · Answer 1 · answered Apr 18 '12 at 15:15

The motivation is actually to bypass the immutability (syntax level) of this in const methods. The const is a semantic check that is verified syntactically by the compiler. Any operation that semantically does not modify the state of the object should be const, but in some cases the implementation requires changing subobjects, and mutable is the syntactic tool to tell the compiler that this particular member is not part of the state of the object and thus can be modified inside const methods.

Without mutable, for example, you could not lock a mutex stored as a member variable in an accessor that semantically does not modify the state of your object, as the syntactic check in the compiler would complain that you are modifying the mutex. There are other motivating examples like memoization where an implementation detail (optimization, thread safety) implies changing a member variable in methods that do not modify the visible state of the object.

When you mean *state*, You mean the behavior observed by the users of the class? Something which is meant for internal book keeping by the class itself rather than the functionality it exposes to its users? — Alok Save, Apr 18 '12 at 15:20
@Als: Anything that does not affect the results of the rest of the program. A cached value in *memoization* is exactly the same value you would get if you reprocessed the calculation, so for the external world, whether you are caching or not the result does not affect the results. The important point is that `const` is a *semantic* tag, and *mutable* is the syntactic construct to tell the compiler that this particular member is not *semantically* part of your state. — David Rodríguez - dribeas, Apr 18 '12 at 15:26

score 8 · Accepted Answer · answered Apr 18 '12 at 15:54

mutable is part of separating bitwise const from logical const. Basically, what the compiler implements is called bitwise const: it complains if you try to modify the bits of the actual object in a const function, but not otherwise. When you write a class, you want to implement logical const: a const function doesn't modify the observable value of the object (where the author of the class defines what is observable value). Mostly, this is a question of not modifying things, even when you could (e.g. parts of the value accessed through pointers), but every so often, there are "bits" in the actual object (as seen by the compiler) which aren't part of the observable value: cached values calculated lazily are the classical example, but one can imagine others: elements in an intrusive linked list, for example, where moving the element around in the list requires updating pointers to previous and next (but where the location of the element in the list is not part of the element's observable value).

+1 Mentioning the *bitwise* const & the *logical* const concept makes this my accepted answer. — Alok Save, Apr 18 '12 at 16:17

score 5 · Answer 3 · answered Apr 18 '12 at 15:14

5

One common need is to implement memoization. To the external world a function call is not modifying the object state, but internally the memoization cache has to be updated. Identifying the cache as mutable allows that.

answered Apr 18 '12 at 15:14

Mark Ransom

299,747
42
398
622

score 0 · Answer 4 · answered Apr 18 '12 at 15:21

The motivation is to bypass the immutability of this. The point is that there might be parts of the object which have to be mutated, but do not contribute to the visible state of the object. Sometimes the modification is just an implementation detail which shouldn't really be visible in the interface (and might be subject to change.

An example would be mutices for locking datastructures. You'll likely need to lock the structure even for const methods to make sure that no other thread is modifying the structure while you are reading it. If the method doesn't change the object it should logically be const (exposing the change made by locking and unlocking the object seems silly), so you'd need to make the mutex mutable.

Motivation for mutable in C++

4 Answers4