[Postscript]

The Uses of Const

Const is an extremely useful semantic addition to C++ which is highly underutilized by programmers. It allows the programmer to specify a semantic constraint on the source code - that is, you can state to the compiler that an object should not be modified - and an error will be produced if, in the compiler's view, you are attempting to do so. This is a very powerful feature, and should be used by the programmer as much as possible as it results in more compile time errors and fewer run time errors (i.e. less debugging).

const is primarily utilized in three locations: in data declarations, where the programmer can say ``I don't want this data to be changed'' ; in parameter lists, where she can say ``I don't want this parameter to be changed''; or with member functions, where he can say ``I don't want this function to change the class data in any way''.

Using Const with Data Declarations

const can be utilized to specify when data is to remain constant.

      const pi = 3.141592 ;

In this case, the compiler will not allow the variable pi to be placed in a situation where it might be changed. In other words, it cannot be placed on the left-hand side of an assignment statement, nor can it be passed as a parameter to a function unless that parameter is also declared const

Pointers can also be declared constant and this has implications on the data that the pointer refers to. The statement

      const char *p ;

implies that the data that p points to is const, the statement

      char * const p ;

implies that the pointer is constant but the data can be changed, and the statement

      const char * const p ;

implies that neither the pointer nor the data can be changed.

Using Const with Parameters const parameters act just like local const objects. The interface declaration statement

      Vector dot ( const Vector&, const Vector& ) ;

states that the parameter is a reference to an actual data item, and this item is not allowed to change. In general, this is the normal method of passing parameters, as we do not want side effects as a result of our functions. But there are cases where the compiler will declare variables const, and we must take them into consideration. For example, frequently we wish to substitute an expression for a parameter

      a = dot ( v1 + v2, v3 ) ;

In this case, the result of the expression v1 + v2 is placed into a temporary object by the compiler which cannot be changed and utilized by the programmer - it is an internal variable. In this case, the compiler will declare this temporary variable const. In other words, if the dot function were defined by

      Vector dot ( Vector&, Vector& ) ;

a compiler error would be generated by the above statement.

In general, all parameters should be passed by reference and as const unless explicit side effects are desired by the programmer.

Using Const with Member Functions When a member function is const it implies that the function or operator is not allowed to modify any of the object data members. The statement

      double length() const ;

in the Vector class, implies that the function that determines the length of a Vector should not change the contents of the Vectors data members.

If a member function is declared const, the compiler will not allow the function to be utilized in any situation where the data members of the class may be changed.

Member Functions for the Const and Non-Const Objects

Frequently, it is useful to have nearly identical member functions that can be used on both const and non-const objects. This is most frequently done on operator[], as in the member function for a possible string class

which extracts a single character from the string. Utilizing these functions we can have two different things happen to the const and non-const data items of a class. The first function will be utilized by the compiler for the non-const objects (e.g. putting s[i] on the left-hand side of an assignment statement) and the second statement will be used for the const objects.

This document maintained by Ken Joy.
Comments to the author : joy@cs.ucdavis.edu

All contents copyright (c) 1998
Computer Science Department, University of California, Davis
All rights reserved.