In computer science, Const-correctness, const being from a word constant, is a qualifier for a datatype that states that an variable of the datatype is not assignable. That is,
var int a;
a = 4; // ok
var const int b;
b = 4; // not ok
Otherwise, variables work exactly like varialbes with non-const type. The exact semantic of const varies widely. Mostly, the feature referrs to that in C++ (not C).
The idea of const-ness does not imply that the variable as it is stored in the computer's memory is unwriteable. Rather, const-ness is a compile-time construct that indicates what a programmer may do, not necessarily what he can do.
In addition, a class method can be declared as const, indicating that calling that method does not change the object. Such const methods can only call other const methods but cannot assign member variables. (In C++, a member variable can be declared as mutable, indicating that a const method can change its value. Mutable member variables can be used for caching and reference counting, where the logical meaning of the object is unchanged, but the object is not physically constant since its bitwise representation may change.)
C++ syntax
In C++ all data types, including those defined by the user, can be declared const, and all objects should be unless they need to be modified. Such proactive use of const makes values "easier to understand, track, and reason about,"1 and thus, it increases the readability and comprehensibility of code and makes working in teams and maintaining code simpler because it communicates something about a value's intended use.
Simple data types
For simple data types, applying the const qualifier is straightforward. It can go on either side of the type for historical reasons (that is, const char foo = 'a'; is equivalent to char const foo = 'a';). On some implementations, using const on both sides of the type (for instance, const char const) generates a warning but not an error.
Pointers and references
For pointer and reference types, the syntax is slightly more subtle. A pointer object can be declared as a const pointer or a pointer to a const object (or both). A const pointer cannot be reassigned to point to a different object from the one it is initially assigned, but it can be used to modify the object that it points to (called the "pointee"). (Reference variables are thus an alternate syntax for const pointers.) A pointer to a const object, on the other hand, can be reassigned to point to another object of the same type or of a convertible type, but it cannot be used to modify any object. A const pointer to a const object can also be declared and can neither be used to modify the pointee nor be reassigned to point to another object. The following code illustrates these subtleties:
void Foo( int * ptr,
int const * ptrToConst,
int * const constPtr,
int const * const constPtrToConst )
{
int const i = 42;
*ptr = 0; // Ok: modifies the pointee
ptr = &i; // Ok: modifies the pointer
*ptrToConst = 0; // Error! Cannot modify the pointee
ptrToConst = &i; // Ok: modifies the pointer
*constPtr = 0; // Ok: modifies the pointee
constPtr = &i; // Error! Cannot modify the pointer
*constPtrToConst = 0; // Error! Cannot modify the pointee
constPtrToConst = &i; // Error! Cannot modify the pointer
}
To render the syntax for pointers more comprehensible, a rule of thumb is to read the declaration from right to left. Thus, everything before the star can be identified as the pointee type and everything to the left are the pointer properties. (For instance, in our example above, constPtrToConst can be read as a const pointer that refers to a const int.)
References follow similar rules. A declaration to a const reference is technically redundant since references can never be made to point to another object, and many compilers will not let it pass without a warning or error:
int i = 42;
int const & refToConst = i; // Ok
int & const constRef = i; // const is redundant; may not compile
Even more complicated declarations can result when using multidimensional arrays and references (or pointers) to pointers. Generally speaking, these should be avoided or replaced with higher level structures because they are confusing and prone to error.
Methods
In order to take advantage of the design-by-contract strategy for user-defined types (structs and classes), which can have methods as well as member data, the programmer must tag methods as const if they don't modify the object's data members. Applying the const qualifier to methods thusly is an essential feature for const-correctness and is not available in many other object-oriented languages such as Java and C#. While const methods can be called by const and non-const objects alike, non-const methods can only be invoked by non-const objects. This example illustrates:
class C
{
int i;
private:
int Get() const { return i; } // Note the const tag
void Set( const int j ) { i = j; }
};
void Foo( C& nonConstC, const C& constC )
{
int y = nonConstC.Get(); // Ok
int x = constC.Get(); // Ok: Get() is const
nonConstC.Set( 10 ); // Ok: nonConstC is modifiable
constC.Set( 10 ); // Error: Set() might modify constC!
}
Often the programmer will supply both a const and a non-const method with the same name (but possibly quite different uses) in a class to accomodate both types of callers. Consider:
class MyArray
{
int data[ 100 ];
private:
// ...
int& Get( const int n ) { return data[ n ]; }
int const& Get( const int n ) const { return data[ n ]; }
};
The const-ness of the calling object determines which version of MyArray::Get() will be invoked and thus whether or not the caller is given a reference with which he can manipulate or only observe the private data in the object. (Returning a reference to an int may be overkill in the second method, but the same technique can be used for arbitrary types, as in the Standard Template Library.)
Loop-holes to const-correctness
There are two loop-holes to pure const-correctness in C and C++. They exist primarily for compatibility with existing code.
The first, which applies only to C++, is the use of const_cast, which allows the programmer to strip the const qualifier, making any object modifiable. The necessity of stripping the qualifier arises when using existing code and libraries that cannot be modified but which are not const-correct. For instance, consider this code:
// Prototype for a function which we cannot change but which
// we know does not modify the pointee passed in.
void LibraryFunc( int * ptr, int size );
void CallLibraryFunc( int const * const ptr, int const size )
{
LibraryFunc( ptr, size ); // Error! Drops const qualifier
int *const nonConstPtr = const_cast<int*>( ptr ); // Strip qualifier
LibraryFunc( nonConstPtr, size ); // Ok
}
The other loop-hole applies both to C and C++. Specifically, the languages dictate that member pointers and references are "shallow" with respect to the const-ness of their owners — that is, a containing object that is const has all const members except that member pointees (and referees) are still mutable. To illustrate, consider this code:
struct S
{
int val;
int * ptr;
};
void Foo( const S& s )
{
int i = 42;
s.val = i; // Error: s is const, so val is a const int
s.ptr = &i; // Error: s is const, so ptr is a const pointer
*s.ptr = i; // Ok: the data pointed to by ptr is always mutable,
// even though this is usually not desirable
}
Although the object s passed to Foo() is constant, which makes all of its members constant, the pointee accessible through s.ptr is still modifiable, though this is not generally desirable from the standpoint of const-correctness because s may solely own the pointee. For this reason, some have argued that the default for member pointers and references should be "deep" const-ness, which could be overridden by a mutable qualifier when the pointee is not owned by the container, but this strategy would create compatibility issues with existing code. Thus, for historical reasons, this loop-hole remains open in C and C++.
Volatile-correctness
The other qualifier in C and C++, volatile, indicates that an object may be changed by something external to the program at any time and so must be re-read from memory every time it is accessed. The qualifier is most often found in embedded systems or systems manipulating hardware directly. It can be used in exactly the same manner as const in declarations of variables, pointers, references, and member functions, but such use has little semantic value, except in the case of simple objects. (In fact, volatile could be used to implement a similar design-by-contract strategy which might be called volatile-correctness, but it is almost never used to do so.) The volatile qualifier can also stripped by const_cast, and it can be combined with the const qualifier as in this sample:
// Set up a reference to a read-only hardware register that is
// mapped in a hard-coded memory ___location.
const volatile int & hardwareRegister = *reinterpret_cast<int*>( 0x8000 );
hardwareRegister = 5; // Error! Cannot write to a const ___location
int currentValue = hardwareRegister; // Read the memory ___location
int newValue = hardwareRegister; // Read it again
Because hardwareRegister is volatile, there is no guarantee that it will hold the same value on two successive reads even though the programmer cannot modify it. The semantics here indicate that value is read-only but not necessarily unchanging.
We can also create volatile pointers, though their applications are rarer:
// Set up a pointer to a read-only memory-mapped register that
// contains a memory address for us to deference
const int * volatile const tableLookup = reinterpret_cast<int*>( 0x8004 );
int currentTableValue = *tableLookup; // Deference the memory ___location
int newTableValue = *tableLookup; // Deference it again
tableLookup = ¤tTableValue; // Error! cannot modify a const pointer
Since the address held in the tableLookup pointer can change implicitly, each deference might take us to a different ___location in a memory-mapped look-up table.
Final
In Java, a qualifer final states the variable is not assignable, as below:
final int i = 3;
i = 4; // this results in compiler-time error.
The variable with final must be initialized explicitly.
Unlike C++, a method with final merely means that the method would not be overriden.
Footnotes
- Sutter, Herb and Andrei Alexandrescu (2005). C++ Coding Standards. p. 30. Boston: Addison Wesley. ISBN 0321113586
External links
- "Const-Correctness" by Herb Sutter
- "Constant Optimization?" by Herb Sutter
- The C++ FAQ Lite: Const correctness by Marshall Cline
- "Const_Cast: An Offspring from the Dark Side of C++" by Karsten Weihe
- Section "Value substitution" from the free electronic book "Thinking in C++" by Bruce Eckel