Const (computer programming): Difference between revisions

Revision as of 07:51, 12 May 2005

Revision as of 14:59, 12 May 2005

Line 21:

===Methods===

In C++, methods of a <code>struct</code> or <code>class</code> can be tagged as <code>const</code>, and 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:

In C++, methods can be tagged as constant. Observe this example:

<code>

class PointC

{

public: int i;

private:

int getX() const;

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

void setXset( int xj ) { i = j; }

void setY(int y)};

}

void Foo( C& nonConstC, const C& constC )

void doSomethingWithAPoint()

{

int y = nonconstC.get(); // Ok

const Point point(20, 30);

cout << "x = " <<int pointx = constC.getXget(); << endl; // thisOk: codeget() is legalconst

point.setX(50); // this statement will NOT compile, because the point contents are immutable

nonConstC.set( 10 ); // Ok: nonConstC is modifiable

}

constC.set( 10 ); // Error: set() might modify constC!

}

</code>

===Pointers and references===

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>

int const * ptrToConst,

void Foo( int int *const constPtr ptr,

int const * const constPtrToConst ) ptrToConst,

int * const constPtr,

{

int const * ptrToConst,const constPtrToConst )

{

int const i;

Line 61 ⟶ 64:

*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 to a <code>const</code> reference is permitted for the sake of templates but 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;

<code>

int const & refToConst = i; // Ok

int & const constRef = i; // Nonsensical; may compile, but may not = 42;

int const & refToConst = i; // Ok

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.

Line 75 ⟶ 83:

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

}

}

</code>

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

{

intstruct val;S

int{ * ptr;

int getX() const val;

};

void Foo( int * ptr,;

};

void BarFoo( S const 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 = 0; // Ok: the data pointed to by ptr is always mutable,

// even though this is usually not desirable

}

}

</code>

Although the structureobject <code>s</code> passed to <code>BarFoo()</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-hole remains open in C and C++.

===The <code>volatile</code> qualifier===

The other qualifier in C and C++, <code>volatile</code>, indicates that an object may be changed by another thread or by something external to the program at unexpectedany timestime and so must be re-read from memory every time it is accessed. 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 variables. The <code>const_castvolatile</code> keywordqualifier can also stripped by <code>const_cast</code>, and it can be used to stripwith the <code>volatileconst</code> qualifier. as in this sample:

<code>

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

</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 value is read-only but not necessarily unchanging. We can also create volatile pointers, though their applications are rarer:

<code>

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

tableLookup = &currentTableValue; // Error: cannot modify a const pointer

int currentTableValue = *tableLookup; // Deference the memory ___location

int newTableValue = *tableLookup; // Deference it again

</code>

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

Although the structure <code>s</code> passed to <code>Bar()</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-hole remains open in C and C++.

==References==

===<code>volatile</code>===

* [http://www.parashift.com/c++-faq-lite/const-correctness.html The C++ FAQ Lite: Const correctness] by Marshall Cline

<!-- This needs love. I've seen no clear explanation of it other than "it's importand for multi-threaded applications"-->

The other qualifier in C and C++, <code>volatile</code>, indicates that an object may be changed by another thread at unexpected times and so must be re-read from memory every time it is accessed. 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 variables. The <code>const_cast</code> keyword can also be used to strip the <code>volatile</code> qualifier.

{{sectstub}}

[[Category:C programming language family]]