[18.1] What is "const correctness"?

A good thing. It means using the keyword const to prevent const objects
from getting mutated.

For example, if you wanted to create a function f() that accepted a std::string,
plus you want to promise callers not to change the caller's std::string that gets
passed to f(), you can have f() receive its std::string parameter...

void f1(const std::string& s); // Pass by reference-to-const

void f2(const std::string* sptr); // Pass by pointer-to-const

void f3(std::string s); // Pass by value

In the pass by reference-to-const and pass by
pointer-to-const cases, any attempts to change to the caller's std::string
within the f() functions would be flagged by the compiler as an error at
compile-time. This check is done entirely at compile-time: there is no
run-time space or speed cost for the const. In the pass by value
case (f3()), the called function gets a copy of the caller's std::string. This
means that f3() can change its local copy, but the copy is destroyed when
f3() returns. In particular f3() cannot change the caller's std::string
object.

As an opposite example, if you wanted to create a function g() that accepted
a std::string, but you want to let callers know that g() might change the
caller's std::string object. In this case you can have g() receive its std::string
parameter...

void g1(std::string& s); // Pass by reference-to-non-const

void g2(std::string* sptr); // Pass by pointer-to-non-const

The lack of const in these functions tells the compiler that they are allowed
to (but are not required to) change the caller's std::string object. Thus they
can pass their std::string to any of the f() functions, but only f3() (the one
that receives its parameter "by value") can pass its std::string to g1() or
g2(). If f1() or f2() need to call either g() function, a local copy
of the std::string object must be passed to the g() function; the parameter to
f1() or f2() cannot be directly passed to either g() function. E.g.,

Naturally in the above case, any changes that g1() makes are made to the
localCopy object that is local to f1(). In particular, no changes
will be made to the const parameter that was passed by reference to f1().

[18.2] How is "const correctness" related to ordinary type safety?

Declaring the const-ness of a parameter is just another form of type safety.
It is almost as if a conststd::string, for example, is a different class than
an ordinary std::string, since the const variant is missing the various mutative
operations in the non-const variant (e.g., you can imagine that a conststd::string simply doesn't have an assignment operator).

[18.4] What does "const Fred* p" mean?

It means p points to an object of class Fred, but p can't be used to
change that Fred object (naturally p could also be NULL).

For example, if class Fred has a const member
function called inspect(), saying p->inspect() is OK.
But if class Fred has a non-const member
function called mutate(), saying p->mutate() is an error
(the error is caught by the compiler; no run-time tests are done, which means
const doesn't slow your program down).

[18.6] What does "const Fred& x" mean?

It means x aliases a Fred object, but x can't be used to change that
Fred object.

For example, if class Fred has a const member
function called inspect(), saying x.inspect() is OK. But
if class Fred has a non-const member function
called mutate(), saying x.mutate() is an error (the error is
caught by the compiler; no run-time tests are done, which means const doesn't
slow your program down).

In other words, "Fred& const x" is functionally equivalent to
"Fred& x". Since you're gaining nothing by adding the const after
the &, you shouldn't add it since it will confuse people. I.e., the
const will make some people think that the Fred is const, as if you had
said "const Fred& x".

[18.8] What does "Fred const& x" mean?

Fred const& x is functionally equivalent to
const Fred& x. However, the real question is
which should be used.

Answer: absolutely no one should pretend they can make decisions for
your organization until they know something about your organization.
One size does not fit all; there is no "right" answer for all organizations,
so do not allow anyone to make a knee-jerk decision in either
direction. "Think" is not a four-letter word.

For example, some organizations value consistency and have tons of code using
const Fred&; for those, Fred const& would be a bad decision
independent of its merits. There are lots of other business scenarios, some
of which produce a preference for Fred const&, others a preference for
const Fred&.

Use a style that is appropriate for your organization's average
maintenance programmer. Not the gurus, not the morons, but the average
maintenance programmer. Unless you're willing to fire them and hire new ones,
make sure that they understand your code. Make a business decision
based on your realities, not based on someone else's assumptions.

You'll need to overcome a little inertia to go with Fred const&. Most
current C++ books use const Fred&, most programmers learned C++ with
that syntax, and most programmers still use that syntax. That doesn't mean
const Fred& is necessarily better for your organization, but it does
mean you may get some confusion and mistakes during the transition and/or when
you integrate new people. Some organizations are convinced the benefits of
Fred const& outweigh the costs; others, apparently, are not.

[18.9] What does "Fred const* x" mean?

Fred const* x is functionally equivalent to
const Fred* x. However, the real question is
which should be used.

Answer: absolutely no one should pretend they can make decisions for
your organization until they know something about your organization.
One size does not fit all; there is no "right" answer for all organizations,
so do not allow anyone to make a knee-jerk decision in either
direction. "Think" is not a four-letter word.

For example, some organizations value consistency and have tons of code using
const Fred*; for those, Fred const* would be a bad decision
independent of its merits. There are lots of other business scenarios, some
of which produce a preference for Fred const*, others a preference for
const Fred*.

Use a style that is appropriate for your organization's average
maintenance programmer. Not the gurus, not the morons, but the average
maintenance programmer. Unless you're willing to fire them and hire new ones,
make sure that they understand your code. Make a business decision
based on your realities, not based on someone else's assumptions.

You'll need to overcome a little inertia to go with Fred const*. Most
current C++ books use const Fred*, most programmers learned C++ with
that syntax, and most programmers still use that syntax. That doesn't mean
const Fred* is necessarily better for your organization, but it does
mean you may get some confusion and mistakes during the transition and/or when
you integrate new people. Some organizations are convinced the benefits of
Fred const* outweigh the costs; others, apparently, are not.

[18.10] What is a "const member function"?

A member function that inspects (rather than mutates) its object.

A const member function is indicated by a const suffix just after the
member function's parameter list. Member functions with a const suffix are
called "const member functions" or "inspectors." Member functions without a
const suffix are called "non-const member functions" or "mutators."

The error in unchangeable.mutate() is caught at compile time. There is
no runtime space or speed penalty for const.

The trailing const on inspect() member function means that the
abstract (client-visible) state of the object isn't going to change.
This is slightly different from promising that the "raw bits" of the object's
struct aren't going to change. C++ compilers aren't allowed to take the
"bitwise" interpretation unless they can solve the aliasing problem, which
normally can't be solved (i.e., a non-const alias could exist which could
modify the state of the object). Another (important) insight from this
aliasing issue: pointing at an object with a pointer-to-const doesn't guarantee
that the object won't change; it promises only that the object won't change
via that pointer.

The good news is that the compiler will often catch you if you get
this wrong. In particular, if you accidentally return a member of your
this object by non-const reference, such as in
Person::name_evil() above, the compiler will often detect it
and give you a compile-time error while compiling the innards of, in this
case, Person::name_evil().

The bad news is that the compiler won't always catch you: there are some cases
where the compiler simply won't ever give you a compile-time error message.

Net: you need to think, and you need to remember the guideline in this FAQ.
If the thing you are returning by reference is logically part of your
this object, independent of whether it is physically embedded within
your this object, then a const method needs to return by
const reference or by value, but not by non-const reference.
(The idea of "logically" part of your this object is related to the
notion of an object's "abstract state"; see the
previous FAQ for more.)

[18.12] What's the deal with "const-overloading"?

It's when you have an inspector method and a
mutator method with the same name and the same
number and type of parameters  the methods differ only in that one is
const and the other is non-const.

The subscript operator is a common use of const-overloading. You
should generally try to use one of the standard container
templates, such as std::vector, but if you need to create your
own class that has a subscript operator, here's the rule of thumb:
subscript operators often come in pairs.

When you apply the subscript operator to a MyFredList object that is
non-const, the compiler will call the non-const subscript
operator. Since that returns a normal Fred&, you can both inspect and
mutate the corresponding Fred object. For example, suppose class
Fred has an inspector called Fred::inspect() const and a
mutator Fred::mutate():

However when you apply the subscript operator to a const MyFredList
object, the compiler will call the const subscript operator. Since
that returns a const Fred&, you can inspect the corresponding
Fred object, but you can't mutate/change it:

[18.13] What do I do if I want a const member function to make an "invisible" change to a data member?

Use mutable (or, as a last resort, use const_cast).

A small percentage of inspectors need to make innocuous changes to data members
(e.g., a Set object might want to cache its last lookup in hopes of improving
the performance of its next lookup). By saying the changes are "innocuous," I
mean that the changes wouldn't be visible from outside the object's interface
(otherwise the member function would be a mutator rather than an inspector).

When this happens, the data member which will be modified should be marked as
mutable (put the mutable keyword just before the data member's declaration;
i.e., in the same place where you could put const). This tells the compiler
that the data member is allowed to change during a const member function. If
your compiler doesn't support the mutable keyword, you can cast away the
const'ness of this via the const_cast keyword (but see the
NOTE below before doing this). E.g., in Set::lookup()
const, you might say,

After this line, self will have the same bits as this (e.g., self
== this), but self is a Set* rather than a const Set*
(technically a const Set* const, but the right-most const is
irrelevant to this discussion). Therefore you can use self to modify
the object pointed to by this.

NOTE: there is an extremely unlikely error that can occur with
const_cast. It only happens when three very rare things are combined at the
same time: a data member that ought to be mutable (such as is discussed
above), a compiler that doesn't support the mutable keyword, and an object
that was originally defined to be const (as opposed to a normal, non-const
object that is pointed to by a pointer-to-const). Although this combination
is so rare that it may never happen to you, if it ever did happen the code may
not work (the Standard says the behavior is undefined).

If you ever want to use const_cast, use mutable instead. In other words,
if you ever need to change a member of an object, and that object is pointed to
by a pointer-to-const, the safest and simplest thing to do is add mutable
to the member's declaration. You can use const_cast if you are sure
that the actual object isn't const (e.g., if you are sure the object is
declared something like this: Sets;), but if the object itself
might be const (e.g., if it might be declared like: constSets;), use mutable rather than const_cast.

Please don't write and tell me that version X of compiler Y on
machine Z allows you to change a non-mutable member of a const
object. I don't care  it is illegal according to the language and your code
will probably fail on a different compiler or even a different version (an
upgrade) of the same compiler. Just say no. Use mutable instead.

[18.14] Does const_cast mean lost optimization opportunities?

In theory, yes; in practice, no.

Even if the language outlawed const_cast, the only way to avoid flushing the
register cache across a const member function call would be to solve the
aliasing problem (i.e., to prove that there are no non-const pointers that
point to the object). This can happen only in rare cases (when the object is
constructed in the scope of the const member function invocation, and when
all the non-const member function invocations between the object's
construction and the const member function invocation are statically bound,
and when every one of these invocations is also inlined, and when the
constructor itself is inlined, and when any member functions the constructor
calls are inline).

[18.15] Why does the compiler allow me to change an int after I've pointed at it with a const int*?

Because "const int* p" means "p promises not to change the *p,"
not "*p promises not to change."

Causing a const int* to point to an int doesn't const-ify the int. The
int can't be changed via the const int*, but if someone else has an int*
(note: no const) that points to ("aliases") the same int, then that int*
can be used to change the int. For example:

Note that main() and f(const int*,int*) could be in different
compilation units that are compiled on different days of the week. In that
case there is no way the compiler can possibly detect the aliasing at compile
time. Therefore there is no way we could make a language rule that prohibits
this sort of thing. In fact, we wouldn't even want to make such a rule, since
in general it's considered a feature that you can have many pointers pointing
to the same thing. The fact that one of those pointers promises not to change
the underlying "thing" is just a promise made by the pointer; it's
not a promise made by the "thing".

[18.16] Does "const Fred* p" mean that *p can't change?

"const Fred* p" means that the Fred can't be changed via pointer p,
but there might be other ways to get at the object without going through a
const (such as an aliased non-const pointer such as a Fred*). For
example, if you have two pointers "const Fred* p" and "Fred* q"
that point to the same Fred object (aliasing), pointer q can be used to
change the Fred object but pointer p cannot.