[dcl.type.cv] (original) (raw)

9 Declarations [dcl.dcl]

9.2 Specifiers [dcl.spec]

9.2.9 Type specifiers [dcl.type]

9.2.9.2 The cv-qualifier s [dcl.type.cv]

Redundant cv-qualifications are ignored.

[Note 2:

For example, these could be introduced by typedefs.

— _end note_]

[Note 3:

As described in [dcl.init], the definition of an object or subobject of const-qualified type must specify an initializer or be subject to default-initialization.

— _end note_]

A pointer or reference to a cv-qualified type need not actually point or refer to a cv-qualified object, but it is treated as if it does; a const-qualified access path cannot be used to modify an object even if the object referenced is a non-const object and can be modified through some other access path.

[Note 4:

Cv-qualifiers are supported by the type system so that they cannot be subverted without casting.

— _end note_]

[Example 1: const int ci = 3; ci = 4; int i = 2; const int* cip; cip = &i; *cip = 4; int* ip; ip = const_cast<int*>(cip); *ip = 4; const int* ciq = new const int (3); int* iq = const_cast<int*>(ciq); *iq = 4;

For another example,struct X { mutable int i;int j;};struct Y { X x; Y();};const Y y; y.x.i++; y.x.j++; Y* p = const_cast<Y*>(&y); p->x.i = 99; p->x.j = 99;

— _end example_]

The semantics of an access through a volatile glvalue areimplementation-defined.

If an attempt is made to access an object defined with a volatile-qualified type through the use of a non-volatile glvalue, the behavior is undefined.

[Note 5:

volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation.

Furthermore, for some implementations, volatile might indicate that special hardware instructions are required to access the object.

In general, the semantics of volatile are intended to be the same in C++ as they are in C.

— _end note_]