[18] Const correctness, C++ FAQ Lite







[18] Const correctness
(Part of C++ FAQ Lite, Copyright © 1991-98, Marshall Cline, [e-mail])

FAQs in section [18]:

[18.1] What is "const correctness"?
[18.2] How is "const correctness" related to ordinary
type safety?
[18.3] Should I try to get things const correct "sooner" or
"later"?
[18.4] What does "const Fred* p" mean?
[18.5] What's the difference between "const Fred* p", "Fred* const p" and "const Fred* const p"?
[18.6] What does "const Fred& x" mean?
[18.7] Does "Fred& const x" make any sense?
[18.8] What does "Fred const& x" mean?
[18.9] What is a "const member function"?
[18.10] What do I do if I want to update an "invisible" data
member inside a const member function?
[18.11] Does const_cast mean lost optimization
opportunities?
[18.12] Why does the compiler allow me to change an int after
I've pointed at it with a const int*?
[18.13] Does "const Fred* p" mean that *p
can't change?



[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 String,
plus you want to promise callers not to change the caller's String that gets
passed to f(), you can have f() receive its String parameter . . .

void f1(const String& s);     
// Pass by reference-to-const
void f2(const String* sptr);  
// Pass by pointer-to-const
void f3(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 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 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 String
object.
As an opposite example, if you wanted to create a function g() that accepted
a String, but you want to let callers know that g() might change the
caller's String object. In this case you can have g() receive its String
parameter . . .

void g1(String& s);     
// Pass by reference-to-non-const
void g2(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 String object. Thus they
can pass their String to any of the f() functions, but only f3() (the one
that receives its parameter "by value") can pass its String to g1() or
g2(). If f1() or f2() need to call either g() function, a local copy
of the 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.,

    void g1(String& s);
    
    void f1(const String& s)
    {
      g1(s);          // Compile-time Error since s is const
    
      String localCopy = s;
      g1(localCopy);  // OK since localCopy is not const
    }

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().
[ Top | Bottom | Previous section | Next section ]


[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 const String, for example, is a different class than
an ordinary String, since the const variant is missing the various mutative
operations in the non-const variant (e.g., you can imagine that a const
String simply doesn't have an assignment operator).
If you find ordinary type safety helps you get systems correct (it does;
especially in large systems), you'll find const correctness helps also.
[ Top | Bottom | Previous section | Next section ]


[18.3] Should I try to get things const correct "sooner" or
"later"?
At the very, very, very beginning.
Back-patching const correctness results in a snowball effect: every const
you add "over here" requires four more to be added "over there."
[ Top | Bottom | Previous section | Next section ]


[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).
[ Top | Bottom | Previous section | Next section ]


[18.5] What's the difference between "const Fred* p", "Fred* const p" and "const Fred* const p"?
You have to read pointer declarations right-to-left.

const Fred* p means "p points to a Fred that is const"
— that is, the Fred object can't be changed via
p.
Fred* const p means "p is a const pointer to a Fred"
— that is, you can change the Fred object via
p, but you can't change the pointer p itself.
const Fred* const p means "p is a const pointer to a
const Fred" — that is, you can't change the pointer p itself, nor can
you change the Fred object via
p.

[ Top | Bottom | Previous section | Next section ]


[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).
[ Top | Bottom | Previous section | Next section ]


[18.7] Does "Fred& const x" make any sense?
No, it is nonsense.
To find out what the above declaration means, you
have to read it right-to-left. Thus "Fred& const x" means "x is
a const reference to a Fred". But that is redundant, since references are
always const. You can't reseat a reference.
Never. With or without the const.
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".
[ Top | Bottom | Previous section | Next section ]


[18.8] What does "Fred const& x" mean?
"Fred const& x" is functionally equivalent to "const Fred& x".
The problem with using "Fred const& x" (with the const before the
&) is that it could easily be mis-typed as the
nonsensical "Fred &const x" (with the const after the
&).
Better to simply use const Fred& x.
[ Top | Bottom | Previous section | Next section ]


[18.9] 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."

    class Fred {
    public:
      void inspect() const;   // This member promises NOT to change *this
      void mutate();          // This member function might change *this
    };
    
    void userCode(Fred& changeable, const Fred& unchangeable)
    {
      changeable.inspect();   // OK: doesn't change a changeable object
      changeable.mutate();    // OK: changes a changeable object
    
      unchangeable.inspect(); // OK: doesn't change an unchangeable object
      unchangeable.mutate();  // ERROR: attempt to change unchangeable object
    }

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 const pointer doesn't guarantee
that the object won't change; it promises only that the object won't change
via that pointer).
[ Top | Bottom | Previous section | Next section ]


[18.10] What do I do if I want to update an "invisible" data
member inside a const member function?
Use mutable, or 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. E.g., in
Set::lookup() const, you might say,

    Set* self = const_cast<Set*>(this);

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*.
Therefore you can use self to modify the object pointed to by this.
[ Top | Bottom | Previous section | Next section ]


[18.11] 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).
[ Top | Bottom | Previous section | Next section ]


[18.12] 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 a int*
(note: no const) that points to ("aliases") the same int, then that int*
can be used to change the int. For example:

    void f(const int* p1, int* p2)
    {
      int i = *p1;         // Get the (original) value of *p1
      *p2 = 7;             // If p1 == p2, this will also change *p1
      int j = *p1;         // Get the (possibly new) value of *p1
      if (i != j) {
        cout << "*p1 changed, but it didn't change via pointer p1!\n";
        assert(p1 == p2);  // This is the only way *p1 could be different
      }
    }
    
    main()
    {
      int x;
      f(&x, &x);           // This is perfectly legal (and even moral!)
    }

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".
[ Top | Bottom | Previous section | Next section ]


[18.13] Does "const Fred* p" mean that *p
can't change?
No! (This is related to the FAQ about aliasing of
int pointers.)
"const Fred* p" means that the Fred can't be changed via pointer p,
but any aliasing pointers that aren't const can be used to change the Fred
object. 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.

    class Fred {
    public:
      void inspect() const;   // A const member function
      void mutate();          // A non-const member function
    };
    
    main()
    {
      Fred f;
      const Fred* p = &f;
            Fred* q = &f;
    
      p->inspect();    // OK: No change to *p
      p->mutate();     // Error: Can't change *p via p
    
      q->inspect();    // OK: q is allowed to inspect the object
      q->mutate();     // OK: q is allowed to mutate the object
    }

[ Top | Bottom | Previous section | Next section ]


 E-mail the author
[ C++ FAQ Lite
| Table of contents
| Subject index
| About the author
| ©
| Download your own copy ]
Revised May 27, 1998