Motivation for mutable in C++ [duplicate]

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?

Answer 1

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.

Answer 2

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).

Answer 3

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.

Answer 4

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.