From Wikipedia, the free encyclopedia
  (Redirected from Const correctness)
Jump to: navigation, search

In computer programming, const-correctness is the form of program correctness that deals with the proper declaration of variables or objects as mutable or immutable. The term is mostly used in a C or C++ context, and takes its name from the const keyword in those languages.

The idea of const-ness does not imply that the variable as it is stored in the computer's memory is unwritable. Rather, const-ness is a compile-time construct that indicates what a programmer should do, not necessarily what they can do. Note, however, that in the case of predefined data (such as const char * string literals), C const is often unwritable.

In addition, a (non-static) member-function can be declared as const. In this case, the this pointer inside such a function is of type return_value_type const * const rather than merely of type return_value_type * const. This means that non-const functions for this object cannot be called from inside such a function, nor can member variables be modified. In C++, a member variable can be declared as mutable, indicating that this restriction does not apply to it. In some cases, this can be useful, for example with caching, reference counting, and data synchronization. In these cases, the logical meaning (state) of the object is unchanged, but the object is not physically constant since its bitwise representation may change.

C (and derived languages) syntax[edit]

In C and derived languages, all data types, including those defined by the user, can be declared const, and const-correctness dictates that all variables or objects should be declared as such unless they need to be modified. Such proactive use of const makes values "easier to understand, track, and reason about,"[1] and it thus increases the readability and comprehensibility of code and makes working in teams and maintaining code simpler because it communicates information about a value's intended use. This can help the compiler as well as the developer when reasoning about code. It can also enable an optimizing compiler to generate more efficient code. [2]

Simple data types[edit]

For simple non-pointer 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[edit]

For pointer and reference types, the meaning of const is more complicated – either the pointer itself, or the value being pointed to, or both, can be const. Further, the syntax can be confusing. A pointer can be declared as a const pointer to writable value, or a writable pointer to a const value, or const pointer to const value. 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 value 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 memory location (which should be an object of the same type or of a convertible type), but it cannot be used to modify the memory that it is pointing to. 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 )
    *ptr = 0; // OK: modifies the "pointee" data
    ptr  = NULL; // OK: modifies the pointer
    *ptrToConst = 0; // Error! Cannot modify the "pointee" data
    ptrToConst  = NULL; // OK: modifies the pointer
    *constPtr = 0; // OK: modifies the "pointee" data
    constPtr  = NULL; // Error! Cannot modify the pointer
    *constPtrToConst = 0; // Error! Cannot modify the "pointee" data
    constPtrToConst  = NULL; // Error! Cannot modify the pointer

C convention[edit]

Following usual C convention for declarations, declaration follows use, and the * in a pointer is written on the pointer, indicating dereferencing. For example, in the declaration int *ptr, the dereferenced form *ptr is an int, while the reference form ptr is a pointer to an int. Thus const modifies the name to its right. The C++ convention is instead to associate the * with the type, as in int* ptr, and read the const as modifying the type to the left. int const * ptrToConst can thus be read as "*ptrToConst is a int const" (the value is constant), or "ptrToConst is a int const *" (the pointer is a pointer to a constant integer). Thus:

int *ptr; // *ptr is an int value
int const *ptrToConst; // *ptrToConst is a constant (int: integer value)
int * const constPtr; // constPtr is a constant (int *: integer pointer)
int const * const constPtrToConst; // constPtrToConst is a constant (pointer)
                                   // as is *constPtrToConst (value)

C++ convention[edit]

Following C++ convention of analyzing the type, not the value, a rule of thumb is to read the declaration from right to left. Thus, everything to the left of the star can be identified as the pointee type and everything to the right of the star are the pointer properties. For instance, in our example above, int const * can be read as a writable pointer that refers to a non-writable integer, and int * const can be read as a non-writable pointer that refers to a writable integer.

C/C++ also allows the const to be placed to the left of the type, in the following syntax:

const int*       ptrToConst;     //identical to: int const *       ptrToConst,
const int* const constPtrToConst;//identical to: int const * const constPtrToConst

This more clearly separates the two locations for the const, and allows the * to always be bound to its preceding type, though it still requires reading right-to-left, as follows:

int* ptr;
const int* ptrToConst; // (const int)*, not const (int*)
int* const constPtr;
const int* const constPtrToConst;

Note, however, that despite the different convention for formatting C++ code, the semantics of pointer declaration are the same:

int* a; // a is an int pointer
int* a, b; // TRICKY: a is an int pointer as above, but b is not; b is an int value
int* a, *b; // both a and b are pointers; *a and *b are int values

Bjarne Stroustrup's FAQ recommends only declaring one variable per line if using the C++ convention, to avoid this issue.[3]

C++ references follow similar rules. A declaration of a const reference is redundant since references can never be made to refer to another object:

int i = 22;
int const & refToConst = i; // OK
int & const constRef = i; // Error the "const" is redundant

Even more complicated declarations can result when using multidimensional arrays and references (or pointers) to pointers; however, some[who?] have argued that these are confusing and error-prone and that they therefore should generally be avoided or replaced with higher-level structures.

Parameters and variables[edit]

const can be declared both on function parameters and on variables (static or automatic, including global or local). The interpretation varies between uses. A const static variable (global variable or static local variable) is a constant, and may be used for data like mathematical constants, such as const double PI = 3.14159 – realistically longer, or overall compile-time parameters. A const automatic variable (non-static local variable) means that single assignment is happening, though a different value may be used each time, such as const int x_squared = x*x. A const parameter in pass-by-reference means that the referenced value is not modified – it is part of the contract – while a const parameter in pass-by-value (or the pointer itself, in pass-by-reference) does not add anything to the interface (as the value has been copied), but indicates that internally, the function does not modify the parameter (it is a single assignment). For this reason, some favor using const in parameters only for pass-by-reference, where it changes the contract, but not for pass-by-value, where it exposes the implementation.


In order to take advantage of the design by contract approach for user-defined types (structs and classes), which can have methods as well as member data, the programmer must tag instance methods as const if they don't modify the object's data members. Applying the const qualifier to instance methods thus is an essential feature for const-correctness, and is not available in many other object-oriented languages such as Java and C# or in Microsoft's C++/CLI or Managed Extensions for 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. The const modifier on an instance method applies to the object pointed to by the "this" pointer, which is an implicit argument passed to all instance methods. Thus having const methods is a way to apply const-correctness to the implicit "this" pointer argument just like other arguments.

This example illustrates:

class C
    int i;
    int Get() const // Note the "const" tag
      { return i; }
    void Set(int j) // Note the lack of "const"
      { 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() is a non-const method and constC is a const-qualified object

In the above code, the implicit "this" pointer to Set() has the type "C *const"; whereas the "this" pointer to Get() has type "const C *const", indicating that the method cannot modify its object through the "this" pointer.

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 accommodate both types of callers. Consider:

class MyArray
    int data[100];
    int &       Get(int i)       { return data[i]; }
    int const & Get(int i) const { return data[i]; }
void Foo( MyArray & array, MyArray const & constArray )
    // Get a reference to an array element 
    // and modify its referenced value.
    array.Get( 5 )      = 42; // OK! (Calls: int & MyArray::Get(int))
    constArray.Get( 5 ) = 42; // Error! (Calls: int const & MyArray::Get(int) const)

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. The two methods technically have different signatures because their "this" pointers have different types, allowing the compiler to choose the right one. (Returning a const reference to an int, instead of merely returning the int by value, may be overkill in the second method, but the same technique can be used for arbitrary types, as in the Standard Template Library.)

Loopholes to const-correctness[edit]

There are several loopholes 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 *ptr, int size)
    LibraryFunc(ptr, size); // Error! Drops const qualifier
    int *nonConstPtr = const_cast<int*>(ptr); // Strip qualifier
    LibraryFunc(nonConstPtr, size);  // OK

However, any attempt to modify an object that is itself declared const by means of const_cast results in undefined behavior according to the ISO C++ Standard. In the example above, if ptr references a global, local, or member variable declared as const, or an object allocated on the heap via new const int, the code is only correct if LibraryFunc really does not modify the value pointed to by ptr.

The C language has a need of a loophole because a certain situation exists. Variables with static storage duration are allowed to be defined with an initial value. However, the initializer can use only constants like string constants and other literals, and is not allowed to use non-constant elements like variable names, whether the initializer elements are declared const or not, or whether the static duration variable is being declared const or not. There is a non-portable way to initialize a const variable that has static storage duration. By carefully constructing a typecast on the left hand side of a later assignment, a const variable can be written to, effectively stripping away the const attribute and 'initializing' it with non-constant elements like other const variables and such. Writing into a const variable this way may work as intended, but it causes undefined behavior and seriously contradicts const-correctness:

const size_t    bufferSize = 8*1024;
const size_t    userTextBufferSize;  //initial value depends on const bufferSize, can't be initialized here
int setupUserTextBox(textBox_t *defaultTextBoxType, rect_t *defaultTextBoxLocation)
    *(size_t*)&userTextBufferSize = bufferSize - sizeof(struct textBoxControls);  // warning: might work, but not guaranteed by C

Another loophole[citation needed] 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 to int
    *s.ptr = i;  // OK: the data pointed to by ptr is always mutable,
                 //     even though this is sometimes 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 may not be desirable from the standpoint of const-correctness because s might solely own the pointee. For this reason, some[who?] 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[citation needed], this loophole remains open in C and C++.

The latter loophole can be closed by using a class to hide the pointer behind a const-correct interface, but such classes either don't support the usual copy semantics from a const object (implying that the containing class cannot be copied by the usual semantics either) or allow other loopholes by permitting the stripping of const-ness through inadvertent or intentional copying.

Finally, several functions in the C standard library violate const-correctness, as they accept a const pointer to a character string and return a non-const pointer to a part of the same string. strtol and strchr are among these functions. Some implementations of the C++ standard library, such as Microsoft's[4] try to close this loophole by providing two overloaded versions of some functions: a "const" version and a "non-const" version.


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 code that manipulates hardware directly (such as in embedded systems and device drivers) and in multithreaded applications (though often used incorrectly in that context; see external links at volatile variable). It can be used in exactly the same manner as const in declarations of variables, pointers, references, and member functions, and in fact, volatile is sometimes used to implement a similar design-by-contract strategy which Andrei Alexandrescu calls volatile-correctness,[5] though this is far less common than const-correctness. The volatile qualifier also can be 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);
int currentValue = hardwareRegister; // Read the memory location
int newValue = hardwareRegister; // Read it again
hardwareRegister = 5; // Error! Cannot write to a const location

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 the register's value is read-only but not necessarily unchanging.

const and immutable in D[edit]

In Version 2 of the D programming language, two keywords relating to const exist.[6] The immutable keyword denotes data that cannot be modified through any reference. The const keyword denotes a non-mutable view of mutable data. Unlike C++ const, D const and immutable are "deep" or transitive, and anything reachable through a const or immutable object is const or immutable respectively.

Example of const vs. immutable in D

int[] foo = new int[5];  // foo is mutable.
const int[] bar = foo;   // bar is a const view of mutable data.
immutable int[] baz = foo;  // Error:  all views of immutable data must be immutable.
immutable int[] nums = new immutable(int)[5];  // No mutable reference to nums may be created.
const int[] constNums = nums;  // Works.  immutable is implicitly convertible to const.
int[] mutableNums = nums;  // Error:  Cannot create a mutable view of immutable data.

Example of transitive or deep const in D

class Foo {
    Foo next;
    int num;
immutable Foo foo = new immutable(Foo); = 5;  // Won't compile. is of type immutable(Foo).
                   // is of type immutable(int).

final in Java[edit]

In Java, the qualifier final states that the affected data member or variable is not assignable, as below:

final int i = 3;
i = 4; // Error! Cannot modify a "final" object

It must be decidable by the compilers where the variable with the final marker is initialized, and it must be performed only once, or the class will not compile. Java's final and C++'s const keywords have the same meaning when applied with primitive variables.

const int i = 3; // C++ declaration
i = 4; // Error!

Considering pointers, a final reference in Java means something similar to const pointer in C++. In C++, one can declare a "const pointer type".

Foo *const bar = mem_location; // const pointer type

Here, bar must be initialised at the time of declaration and cannot be changed again, but what it points is modifiable. I.e. *bar = value is valid. It just can't point to another location. Final reference in Java work the same way except it can be declared uninitialized.

final Foo i; // a Java declaration

Note: Java does not support pointers.[7] It is because pointers (with restrictions) are the default way of accessing objects in Java, and Java does not use stars to indicate them. For example i in the last example is a pointer and can be used to access the instance.

One can also declare a pointer to "read-only" data in C++.

const Foo *bar;

Here bar can be modified to point anything, anytime; just that pointed value cannot be modified through bar pointer. There is no equivalent mechanism in Java. Thus there are also no const methods. Const-correctness cannot be enforced in Java, although by use of interfaces and defining a read-only interface to the class and passing this around, one can ensure that objects can be passed around the system in a way that they cannot be modified. Java collections framework provides a way to create unmodifiable wrapper of a Collection via Collections.unmodifiableCollection() and similar methods.

Methods in Java can be declared "final", but that has a completely unrelated meaning - it means that the method cannot be overridden in subclasses.

Interestingly, the Java language specification regards const as a reserved keyword — i.e., one that cannot be used as variable identifier — but assigns no semantics to it. It is thought that the reservation of the keyword occurred to allow for an extension of the Java language to include C++-style const methods and pointer to const type.[citation needed] An enhancement request ticket for implementing const correctness exists in the Java Community Process, but was closed in 2005 on the basis that it was impossible to implement in a backwards-compatible fashion.[8]

const and readonly in C#[edit]

In C#, the qualifier readonly has the same effect on data members that final does in Java and the const does in C++; the const modifier in C# has an effect similar (yet typed and class-scoped) to that of #define in C++. (The other, inheritance-inhibiting effect of Java's final when applied to methods and classes is induced in C# with the aid of a third keyword, sealed.)

Unlike C++, C# does not permit methods and parameters to be marked as const. However one may also pass around read-only subclasses, and the .NET Framework provides some support for converting mutable collections to immutable ones which may be passed as read-only wrappers.

See also[edit]


External links[edit]