bitwise constness and conceptual constness.

What exactly does it mean for a member function to be const? There
are two prevailing notions: bitwise constness and conceptual constness.
The bitwise const camp believes that a member function is const if and only if it doesn't modify any of the
object's data members (excluding those that are static), i.e., if it doesn't modify any of the bits inside the object.
The nice thing about bitwise constness is that it's easy to detect violations: compilers just look for assignments
to data members. In fact, bitwise constness is C++'s definition of constness, and a const member function isn't
allowed to modify any of the data members of the object on which it is invoked.
Unfortunately, many member functions that don't act very const pass the bitwise test. In particular, a member
function that modifies what a pointer points to frequently doesn't act const. But if only the pointer is in the
object, the function is bitwise const, and compilers won't complain. That can lead to counterintuitive behavior:
class String {
public:
// the constructor makes data point to a copy
// of what value points to
String(const char *value);
...
operator char *() const { return data;}
private:
char *data;
};
const String s = "Hello"; // declare constant object
char *nasty = s; // calls op char*() const
*nasty = 'M'; // modifies s.data[0]
cout << s;
// writes "Mello"
Surely there is something wrong when you create a constant object with a particular value and you invoke only
const member functions on it, yet you are still able to change its value! (For a more detailed discussion of this
example, see Item 29.)
This leads to the notion of conceptual constness. Adherents to this philosophy argue that a const member function
might modify some of the bits in the object on which it's invoked, but only in ways that are undetectable by
clients. For example, your String class might want to cache the length of the object whenever it's requested (see
Item M18):
class String {
public:
// the constructor makes data point to a copy
// of what value points to
String(const char *value): lengthIsValid(false) { ... }
...
size_t length() const;
private:
char *data;
size_t dataLength; // last calculated length
                  // of string
bool lengthIsValid; // whether length is
                   // currently valid
};
size_t String::length() const
{
if (!lengthIsValid) {
dataLength = strlen(data);
lengthIsValid = true;
}
// error!
// error!
return dataLength;
}
This implementation of length is certainly not bitwise const ? both dataLength and lengthIsValid may be
modified ? yet it seems as though it should be valid for const String objects. Compilers, you will find,
respectfully disagree; they insist on bitwise constness. What to do?
The solution is simple: take advantage of the const-related wiggle room the °C++ standardization committee
thoughtfully provided for just these types of situations. That wiggle room takes the form of the keyword mutable.
When applied to nonstatic data members, mutable frees those members from the constraints of bitwise
constness:
class String {
public:
...
// same as above
private:
char *data;
mutable size_t dataLength;
// these data members are
// now mutable; they may be
mutable bool lengthIsValid;
// modified anywhere, even
// inside const member
// functions
};
size_t String::length() const
{
if (!lengthIsValid) {
dataLength = strlen(data);
lengthIsValid = true;
}
// now fine
// also fine
return dataLength;
}