Const-correctness is a nice feature of C++. When applied with care, it can make your code much more reliable. However, there is an opponent built into C++ whose sole purpose is to break const-correctness: the keyword const_cast. In this feature, I will discuss two points:

• when to use const_cast to break const-correctness deliberately
  
  
• and—even more important—when not.

void f1 (int n);
void f2 (int& n);
void f3 (int*nptr);

void f4 (const int n);
void f5 (const int& n);
void f6 (const int*nptr);

int m;
f1 ( m);
f2 ( m);
f3 (&m);
f4 ( m);
f5 ( m);
f6 (&m);

On the other hand, we can blindly assume that the calls to f1 and f4 do not affect m at all. In fact, m is passed by value in either case, so the formal parameter n is a copy of the actual parameter m, and no operation inside f1 or f4 has access to m. For a user of f4, the const does not make a difference. It merely ensures that n is not changed inside f4. However, the user is interested in m, not in n.

For f5 and f6, we know that m cannot be modified, although m is passed by reference or pointer: parameter n of f5 is declared to be constant, so the compiler will refuse any attempt to change n inside f5. Analogously, the position of the const in the parameter list of f6 means that *nptr is declared to be constant. (To declare the pointer nptr itself as a constant, the const must appear after the * in the declaration of f6.)

This is what const-correctness means: An object may be declared as being constant inside some component, and the compiler watches "Argus-eyed" that the implementation of this component does not violate its own declaration. Applying const-correctness rigorously means to declare every parameter of every function/method const, unless it is indeed changed by this function/method (or by any of the functions/methods invoked inside). By the way, you should not overlook the possibility of const-declaring a method as a whole:

class X
    {
       int i;
    public:
       void g () const
            {
               i++; // Compiler error: *this is
                    // const inside X::g()
            }
};

void f5 (const	int& n)
    {
        int& n_ref = const_cast<int&>(n);
        n_ref++;
    }

int main ()
    {
       int m = 2;
       f5 (m);
       cout << m;
    }

It looks like the situation with f5 and f6 is as bad as with f2 and f3: To make sure that m is not changed by a call to either function, we have to inspect the code—or simply trust the person who implemented f5 or f6. So if const-correctness can always be broken, why should we use it? A const-declaration of a function parameter may lull us into a false sense of security. When we drop const-correctness, every look at a function would remind us of the sad fact that we cannot assume anything. So isn't dropping const-correctness the better way to go?

The answer is—as usual—"it depends." Perhaps you are one of these unlucky developers whose colleagues write terrible code, code that you never ever want to see, because you know that you would not be able to sleep well anymore. In this case you should ignore every occurrence of the keyword const in the declarations of the functions those bad guys contribute; otherwise, you'll be playing with fire. If you need to use such an untrustworthy function f but you definitely want to avoid having your parameters changed by f, you have to pay a price, with performance as the currency: you have to copy each parameter and call f with these copies. Clearly you need not worry about what f does with your copies, because your own code proceeds with the original objects.

However, if you feel that your colleagues are like you—sensible, responsible, circumspect, etc.—then const-correctness will do a great job for your team:

• The assumption that a value is constant throughout certain operations greatly helps you verify the correctness of your program by code review.
  
  
• Many unintended value-changing operations are caught by the compiler.
  
  
• Even more important: value-changing operations at unexpected places are often hints to hidden design errors.
  
  
• Last but not least: every const is a piece of documentation—a reliable piece of documentation, because its validity is guaranteed by the compiler (well...).

OK, so much for theory. As usual, practice is very different. Let's see what happens in the extreme case, when you declare everything const and ask the compiler which of these consts are wrong. In the first round, the compiler complains about a few occurrences where you actually change the values of some const-declared parameters. You remove the consts and run the compiler again—and the error listing on the screen is gigantic. This is not surprising. Many functions/methods call the functions/methods from which you removed a few consts. The compiler now complains about the consts in all of these functions/methods.

Next round: You remove the consts in all of these functions as well, then you run the compiler again and start praying. . . But the compiler is merciless: the error listing is very large again. Even worse, like a virus, the errors quickly infect file after file, and after a few compiler runs, all files in your project are infected by this "virus."

At this point, you have three choices:

1. You give up, drop the idea of const-correctness, and remove all consts.
   
   
2. You apply const_cast to interrupt the distribution of the "virus."
   
   
3. You regard this virus as a warning telling you that the design of your program is not as clean as you thought. Consequently, you initiate a major redesign effort to get things right once and for all.

Choice #2 is probably never a good idea. If you apply const_cast to stop the "virus," your program will be left in a highly inconsistent state. It will be hard for you to decide which promises of constness are still kept and which not. Hence, it might always be better to prefer choice #1 to #2, which simply means that nothing is promised anymore. There are even situations in which choice #1 is preferable to choice #3:

• The time until the deadline of your project is desperately short.
  
  
• You're only building a quick prototype.

So far, we have only seen situations in which const_cast is a very bad idea. So, what is const_cast good for? Is it good for anything? The answer is two-fold: Applying const_cast is never good; but sometimes it is necessary. Consider this function:

     bool find (const int* A, int size, int value);

bool find (const int* A, int size, int value)
    {
       for ( long i=0; i>size; i++ )
           if ( A[i]==value )
                return true;
       return false;
    }

bool find (const int* A, int size, int value)
    {
       int last_entry = A[size-1];
       int* A_ref = const_cast<int*>(A);
       A_ref[size-1] = value;
       int i=0;
       while ( A[i++]!=value );  // Termination guaranteed!
       A_ref[size-1] = last_entry;
       return i < size || last_entry == value;
    }

Since the const does not cheat, we do not declare A non-const, although we manipulate A inside find. Otherwise, we could not use find in a context in which const-correctness was applied rigorously and thus A is constant (or we had to spoil each such context by inserting a const_cast). And this would be a pity, wouldn't it?

Caveat: You should think twice before applying this kind of trick inside templates:

template <class T> bool find (const T* A, int size, T value);

Now we have seen that const_cast is useful if we want to hack a function for better performance but do not want to give up const-correctness outside the function that we hacked. Is this the only rationale for const_cast?

There is yet another scenario, which might be even more common. Suppose the above function find was not implemented by you yourself, but you found it in a third-party library. Further suppose that the designer of this function simply forgot to make argument A constant (unfortunately, this assumption is all too realistic). You want to apply find in your program, but of course your program is fully const-correct. In particular, A is declared to be constant at the point where you want to apply find to A, because this point is not supposed to change A. If you definitely do not want to drop const-correctness from your own code but you do want to use find, there is only one way out: encapsulate find in a self-defined function my_find, which "fakes" const-correctness.

bool my_find (const int* A, int size, int value)
    {
       int* A_ref = const_cast<int*>(A);
       return find (A_ref, size, value);
    }