Const (computer programming): Difference between revisions

Revision as of 12:21, 13 July 2005

Revision as of 23:28, 21 July 2005

Line 1:

In [[computer science]], '''const-correctness''' is the form of program correctness that deals with the proper declaration of objects as [[mutable object|mutable]] or [[immutable object|immutable]]. The term is mostly used in a [[C programming language|C]] or [[C Plus Plus|C++]] context, and takes its name from the <code>const</code> keyword in those languages.

:{{merge|immutable object}}

The idea of const-ness does not imply that the variable as it is stored in the [[computer]]'s [[computer storage|memory]] is unwriteable. Rather, <code>const</code>-ness is a [[compile-time]] construct that indicates what a programmer ''may'' do, not necessarily what he ''can'' do.

In [[computer science]], '''<code>Const<code>-correctness''', const being from a word ''constant'', is a qualifier for a [[datatype]] that states that an [[variable]] of the datatype is either unassignable or immutable. That is,

var ''int'' a;

a = 4; // ok

var ''const int'' b;

b = 4; // not ok

Otherwise, variables work exactly like variables with non-const type. The exact semantic of ''const'' varies widely. Mostly, the feature refers to that in [[C plus plus programming language|C++]] (not C).

The idea of <code>const</code>-ness does not imply that the variable as it is stored in the [[computer]]'s [[computer storage|memory]] is unwriteable. Rather, <code>const</code>-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 <code>const</code>, indicating that calling that method does not change the object. Such <code>const</code> methods can only call other <code>const</code> methods but cannot assign [[field (computer science)|member variables]]. (In C++, a member variable can be declared as <code>mutable</code>, indicating that a <code>const</code> method can change its value. Mutable member variables can be used for [[cache|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 <code>const</code>, and all objects should be unless they need to be modified. Such proactive use of <code>const</code> makes values "easier to understand, track, and reason about,"^{[[#Footnotes{{ref|1]]}Sutter}} 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===

Line 23 ⟶ 14:

For pointer and reference types, the syntax is slightly more subtle. A pointer object can be declared as a <code>const</code> pointer or a pointer to a <code>const</code> object (or both). A <code>const</code> 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 <code>const</code> pointers.) A pointer to a <code>const</code> 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 <code>const</code> pointer to a <code>const</code> 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,

<code>

void Foo( int int const * ptrptrToConst,

int const * * const ptrToConstconstPtr,

int const * const constPtr,constPtrToConst )

{

int const * const constPtrToConst )

*ptr = 0; // OK: modifies the pointee

{

ptr = intNULL; const// iOK: =modifies 42;the pointer

*ptrptrToConst = 0; // Ok:Error! Cannot modifiesmodify the pointee

ptrptrToConst = &iNULL; // OkOK: modifies the pointer

*ptrToConstconstPtr = 0; // Error! CannotOK: modifymodifies the pointee

ptrToConstconstPtr = &iNULL; // Ok:Error! Cannot modifiesmodify the pointer

*constPtrconstPtrToConst = 0; // Ok:Error! Cannot modifiesmodify the pointee

constPtrconstPtrToConst = &iNULL; // Error! Cannot modify the pointer

}

*constPtrToConst = 0; // Error! Cannot modify the pointee

constPtrToConst = &i; // Error! Cannot modify the pointer

}

</code>

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, <code>constPtrToConst</code> can be read as a <code>const</code> pointer that refers to a <code>const int</code>.)

References follow similar rules. A declaration toof a <code>const</code> reference is technically redundant since references can never be made to point to another object, and many compilers will not let it pass withoutonly awith some warning or error:

int i = 42;

<code>

int const & refToConst = i; // OK

int i = 42;

int int& const &constRef = i; // OK, but the refToConstextra ="const" i; //is Okredundant

int & const constRef = i; // const is redundant; may not compile

</code>

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 (<code>struct</code>sstructs and <code>class</code>esclasses), which can have methods as well as member data, the programmer must tag methods as <code>const</code> if they don't modify the object's data members. Applying the <code>const</code> qualifier to methods thusly is an essential feature for const-correctness, and is not available in many other [[object-oriented]] languages such as [[Java (programming language)|Java]] and [[C_sharpC Sharp|C#]]. While <code>const</code> methods can be called by <code>const</code> and non-<code>const</code> objects alike, non-<code>const</code> methods can only be invoked by non-<code>const</code> objects. This example illustrates:

class C

<code>

{

class C

{ int i;

int i;public:

int Get() const // Note the "const" tag

private:

int Get() const { return i; } // Note the const tag

void Set( const int j ) {// iNote =the j;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() mightis modifya non-const method and constC! is a const-qualified object

}

}

</code>

Often the programmer will supply both a <code>const</code> and a non-<code>const</code> method with the same name (but possibly quite different uses) in a class to accomodate both types of callers. Consider:

class MyArray

<code>

{

class MyArray

{ int data[100];

public:

int data[ 100 ];

int & Get(int i) { return data[i]; }

private:

int const & Get(int i) const { return data[i]; }

// ...

};

int& Get( const int n ) { return data[ n ]; }

int const& Get( const int n ) const { return data[ n ]; }

};

</code>

The <code>const</code>-ness of the calling object determines which version of <code>MyArray::Get()</code> 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 <code>const</code> reference to an <code>int</code>, instead of merely returning the <code>int</code> 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]].)

===Loop-holesLoopholes to <code>const</code>-correctness===

There are two loop-holesloopholes to pure <code>const</code>-correctness in C and C++. They exist primarily for compatibility with existing code.

The first, which applies only to C++, is the use of <code>const_cast</code>, which allows the programmer to strip the <code>const</code> 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 <code>const</code>-correct. For instance, consider this code:

// Prototype for a function which we cannot change but which

<code>

// we know does not modify the pointee passed in.

// Prototype for a function which we cannot change but which

void LibraryFunc(int *ptr, int size);

// 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 ); // OkOK

}

}

</code>

The other loop-holeloophole applies both to C and C++. Specifically, the languages dictate that member pointers and references are "shallow" with respect to the <code>const</code>-ness of their owners &mdash; that is, a containing object that is <code>const</code> has all <code>const</code> members except that member pointees (and referees) are still mutable. To illustrate, consider this code:

struct S

<code>

{

struct S

{ int val;

int val*ptr;

};

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; // OkOK: the data pointed to by ptr is always mutable,

// even though this is usuallysometimes not desirable

}

}

</code>

Although the object <code>s</code> passed to <code>Foo()</code> is constant, which makes all of its members constant, the pointee accessible through <code>s.ptr</code> is still modifiable, though this is not generally desirable from the standpoint of <code>const</code>-correctness because <code>s</code> may solely own the pointee. For this reason, some have argued that the default for member pointers and references should be "deep" <code>const</code>-ness, which could be overridden by a <code>mutable</code> 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-holeloophole remains open in C and C++.

===Volatile-correctness===

The otherAnother qualifier in C and C++, <code>volatile</code>, 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 <code>const</code> 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, <code>volatile</code> could be used to implement a similar design-by-contract strategy which might be called <code>volatile</code>-correctness, but it is almost never used to do so.) The <code>volatile</code> qualifier also can alsobe stripped by <code>const_cast</code>, and it can be combined with the <code>const</code> qualifier as in this sample:

// Set up a reference to a read-only hardware register that is

<code>

// mapped in a hard-coded memory ___location.

// Set up a reference to a read-only hardware register that is

const volatile int & hardwareRegister = *reinterpret_cast<int*>(0x8000);

// 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

</code>

Because <code>hardwareRegister</code> 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.

We can also create volatile pointers, though their applications are rarer:

// Set up a pointer to a read-only memory-mapped register that

<code>

// contains a memory address for us to deference

// Set up a pointer to a read-only memory-mapped register that

const int * volatile const tableLookup = reinterpret_cast<int*>(0x8004);

// 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 = &currentTableValue; // Error! cannotCannot modify a const pointer

Since the address held in the <code>tableLookup</code> pointer can change implicitly, each deference might take us to a different ___location in a memory-mapped [[lookup table]].

</code>

==final in Java==

Since the address held in the <code>tableLookup</code> pointer can change implicitly, each deference might take us to a different ___location in a memory-mapped look-up table.

In [[Java programming language|Java]], the qualifier <code>final</code> states that the affected data member or variable is not assignable, as below:

== Final ==

In [[Java programming language|Java]], a qualifer <code>final</code> states the variable is not assignable, as below:

final int i = 3;

i = 4; // thisError! resultsCannot inmodify compiler-timea error."final" object

It must be decidable by the compilers where the the variable with the <code>final</code> marker is initialized, and it must be performed only once, or the class will not compile. Unlike C++'s <code>const</code>, the Java <code>final</code> keyword only protects a variable from assignment, and does not guarentee its immutability. The keyword <code>final</code> can be given to a method definition in Java, but unlike in C++ its semantics are that the method cannot be overridden in subclasses.

It is interesting to note that whereas Java's <code>final</code> and C++'s <code>const</code> keywords have the same meaning when applied with primitive variables, their meanings diverge when applied to method definitions. Java cannot simulate C++'s <code>const</code> methods. Similarly, C++ does not have any feature equivalent to Java's <code>final</code> modifier for methods, although its effect on classes can be simulated by a clever abuse of the C++ <code>friend</code> keyword.{{ref|cleverabuse}}

Interestingly, the Java language specification regards <code>const</code> as a reserved keyword &mdash; i.e., one that cannot be used as variable identifier &mdash; 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 <code>const</code> methods.

It must be decidable by the compilers where the the variable with the <code>final</code> marker is initialised, and it must be performed only once, or the class will not compile. Unlike C++'s <code>const</code>, the Java <code>final</code> keyword only protects a variable from assignment, and does not guarentee its immutability. The keyword <code>final</code> can be given to a method definition in Java, but unlike in C++ its semantics are that the method cannot be overriden in subclasses. It is interesting to note that whereas Java's <code>final</code> and C++'s <code>const</code> keywords have the several meaning when applied with primitive variables, their meanings diverge when appended to method definitions. Java cannot simulate C++'s <code>const</code> methods, similarly C++ does not have an equivalent feature for Java's <code>final</code> modifier.

==const and readonly in C#==

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 sometimes thought that this reservation of the keyword occurred to allow for an extension of the Java language to include const methods.

In [[C Sharp|C#]], the qualifier <code>readonly</code> has the same effect on data members that <code>final</code> does in Java; <code>const</code> has an effect similar (but not equivalent) to that of <code>const</code> in C and C++. (The other, inheritance-inhibiting effect of Java's <code>final</code> when applied to methods and classes is induced in C# with the aid of a third keyword, <code>sealed</code>.)

==FootnotesReferences==

#{{note|Sutter}} [[Herb Sutter|Sutter, Herb]] and Andrei Alexandrescu (2005). ''C++ Coding Standards''. p. 30. Boston: Addison Wesley. ISBN 0321113586

#{{note|cleverabuse}} [[Usenet]] post in <code>comp.lang.c++</code>. Message-ID <code>&lt;[e-mail]&gt;</code>

==External links==