Const-correctness

Const-correctness

In computer science, const-correctness is the form of program correctness that deals with the proper declaration of 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 unwriteable. Rather, const-ness is a compile-time construct that indicates what a programmer "may" do, not necessarily what he or she "can" do.

In addition, a method can be declared as const. In this case, the 'this' pointer inside such a method is of const ThisClass* type rather than of ThisClass* type. This makes that non-const methods for this object cannot be called from inside such a method, nor member variables can be modified, nor non-const methods be called for them, if they are of class type. In C++, a member variable can be declared as mutable, indicating that this restriction does not apply to it. Mutable member variables can be used for caching and reference counting, where the logical meaning (state) 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," [Herb Sutter and Andrei Alexandrescu (2005). "C++ Coding Standards". p. 30. Boston: Addison Wesley. ISBN 0-321-11358-6] 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.

imple 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 ){ *ptr = 0; // OK: modifies the pointee ptr = 0; // OK: modifies the pointer

*ptrToConst = 0; // Error! Cannot modify the pointee ptrToConst = 0; // OK: modifies the pointer

*constPtr = 0; // OK: modifies the pointee constPtr = 0; // Error! Cannot modify the pointer

*constPtrToConst = 0; // Error! Cannot modify the pointee constPtrToConst = 0; // 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 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 mutable pointer that refers to a non-mutable integer, and int * const can be read as a non-mutable pointer that refers to a mutable integer.)

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 = 42;int const & refToConst = i; // OKint & 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 have arguedFact|date=May 2008 that these are confusing and error-prone and that they therefore should generally be avoided or replaced with higher-level structures.

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 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;public: 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, this 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] ;public: 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; constArray.Get( 5 ) = 42; // Error!}

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

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(ptr); // Strip qualifier LibraryFunc(nonConstPtr, size); // OK}

It should be noted, however, that 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.

Another loophole 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 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 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. The C++ standard library closes this loophole by providing two overloaded versions of each function: a "const" version and a "non-const" version.

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 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, [ [http://www.cuj.com/documents/s=7998/cujcexp1902alexandr/alexandr.htm "Generic: volatile — Multithreaded Programmer’s Best Friend Volatile-Correctness or How to Have Your Compiler Detect Race Conditions for You"] by Andrei Alexandrescu in the "C/C++ Users Journal" C++ Experts Forum] 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(0x8000);

int currentValue = hardwareRegister; // Read the memory locationint 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 invariant in D

In D programming language, there are immutable views of data (for instance, const pointers to non-const data) and data that is immutable (invariant). Unlike in C++, both of these are transitive such that an immutable view of data makes everything reachable through that view to be immutable also. This "deep const-ness" closes a loophole in C++'s const-correctness scheme. The built-in capability of D can be emulated in C++, albeit imperfectly.

final in Java

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. A final reference in Java means the same as the const pointer in C++ above.Foo *const i; // this C++ declarationfinal Foo i; // is the same as this Java declaration

Unlike C++ where you can declare a "pointer to a const type" above, there is no such mechanism in Java.const Foo *bar; // pointer to a const type; no equivalent in JavaThere is no way to declare that you will not modify the object pointed to by a reference through that reference in Java. Thus there are also no const methods. Const-correctness cannot be enforced in Java.

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. The enhancement request ticket in the Java Community Process for implementing const correctness in Java was recentlywhen closed, implying that const correctness will probably never find its way into the official Java specification. [ [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070 Ticket for adding const parameters in Java] ]

const and readonly in C#

In C#, the qualifier readonly has the same effect on data members that final does in Java; const has an effect similar (but more limited) to that of const in C and 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, the .NET Framework provides some support for converting mutable collections to immutable ones which may be passed as read-only wrappers.

References

#if: | style="-moz-column-width:{colwidth}; -webkit-column-width:{colwidth}; column-width:{colwidth};" | #if: | style="-moz-column-count:{1}; -webkit-column-count:{1}; column-count:{1};" >

ee also

*Single assignment

External links

* [http://gotw.ca/gotw/006.htm "Const-Correctness"] by Herb Sutter
* [http://gotw.ca/gotw/081.htm "Constant Optimization?"] by Herb Sutter
* [http://cprogramming.com/tutorial/const_correctness.html "Const-Correctness Tutorial"] by Cprogramming.com
* [http://parashift.com/c++-faq-lite/const-correctness.html The C++ FAQ Lite: Const correctness] by Marshall Cline
*Section " [http://www.mi.uni-koeln.de/c/mirror/www.codeguru.com/cpp/tic/tic_html.zip/tic0092.html Value substitution] " from the free electronic book "Thinking in C++" by Bruce Eckel
* [http://www.digitalmars.com/d/const.html "Here A Const, There A Const"] by Walter Bright
* [http://www.digitalmars.com/d/2.0/const3.html "Const and Invariant" from D programming language specification, version 2 (experimental)]


Wikimedia Foundation. 2010.

Look at other dictionaries:

  • const-correctness — In computer science, const correctness is the form of program correctness that deals with the proper declaration of 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 …   Wikipedia

  • const correctness — noun The proper declaration of objects as immutable in contexts where they are not expected to be modified …   Wiktionary

  • Constant (programming) — const redirects here. For the keyword, see const correctness. In computer programming, a constant is an identifier whose associated value cannot typically be altered by the program during its execution (though in some cases this can be… …   Wikipedia

  • Comparison of Java and C++ — Programming language comparisons General comparison Basic syntax Basic instructions Arrays Associative arrays String operations …   Wikipedia

  • Immutable object — Immutable and Immutability redirect here. For the Christian doctrine, see Immutability (theology). In object oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.[1] This is in… …   Wikipedia

  • C++ structures and classes — The C++ programming language allows programmers to define program specific datatypes through the use of structures and classes. Instances of these datatypes are known as objects and can contain member variables, constants, member functions, and… …   Wikipedia

  • C++ classes — For background information, see C++. The C++ programming language allows programmers to separate program specific datatypes through the use of classes. Instances of these datatypes are known as objects and can contain member variables, constants …   Wikipedia

  • D (programming language) — For other programming languages named D, see D (disambiguation)#Computing. D programming language Paradigm(s) multi paradigm: imperative, object oriented, functional, meta Appeared in 1999 (1999) Designed by …   Wikipedia

  • Compatibility of C and C++ — Programming language comparisons General comparison Basic syntax Basic instructions Arrays Associative arrays String operations …   Wikipedia

  • Single assignment — is used to describe a programming language or representation in which one cannot bind a value to a name if a value has already been bound to that name. In other words, a variable is initialized with (i.e. bound to) a value at the time that it is… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”