tmp/tmpnkers0yc/{from.md → to.md}
RENAMED
|
@@ -1,8 +1,9 @@
|
|
| 1 |
#### The *cv-qualifiers* <a id="dcl.type.cv">[[dcl.type.cv]]</a>
|
| 2 |
|
| 3 |
-
There are two *cv-qualifiers*, `const` and `volatile`.
|
|
|
|
| 4 |
*cv-qualifier* appears in a *decl-specifier-seq*, the
|
| 5 |
*init-declarator-list* of the declaration shall not be empty.
|
| 6 |
[[basic.type.qualifier]] and [[dcl.fct]] describe how cv-qualifiers
|
| 7 |
affect object and function types. Redundant cv-qualifications are
|
| 8 |
ignored. For example, these could be introduced by typedefs.
|
|
@@ -60,15 +61,18 @@ y.x.j++; // ill-formed: const-qualified member modified
|
|
| 60 |
Y* p = const_cast<Y*>(&y); // cast away const-ness of y
|
| 61 |
p->x.i = 99; // well-formed: mutable member can be modified
|
| 62 |
p->x.j = 99; // undefined: modifies a const member
|
| 63 |
```
|
| 64 |
|
| 65 |
-
|
| 66 |
-
|
| 67 |
-
|
|
|
|
| 68 |
|
| 69 |
`volatile` is a hint to the implementation to avoid aggressive
|
| 70 |
optimization involving the object because the value of the object might
|
| 71 |
-
be changed by means undetectable by an implementation.
|
| 72 |
-
|
| 73 |
-
|
|
|
|
|
|
|
| 74 |
|
|
|
|
| 1 |
#### The *cv-qualifiers* <a id="dcl.type.cv">[[dcl.type.cv]]</a>
|
| 2 |
|
| 3 |
+
There are two *cv-qualifiers*, `const` and `volatile`. Each
|
| 4 |
+
*cv-qualifier* shall appear at most once in a *cv-qualifier-seq*. If a
|
| 5 |
*cv-qualifier* appears in a *decl-specifier-seq*, the
|
| 6 |
*init-declarator-list* of the declaration shall not be empty.
|
| 7 |
[[basic.type.qualifier]] and [[dcl.fct]] describe how cv-qualifiers
|
| 8 |
affect object and function types. Redundant cv-qualifications are
|
| 9 |
ignored. For example, these could be introduced by typedefs.
|
|
|
|
| 61 |
Y* p = const_cast<Y*>(&y); // cast away const-ness of y
|
| 62 |
p->x.i = 99; // well-formed: mutable member can be modified
|
| 63 |
p->x.j = 99; // undefined: modifies a const member
|
| 64 |
```
|
| 65 |
|
| 66 |
+
What constitutes an access to an object that has volatile-qualified type
|
| 67 |
+
is implementation-defined. If an attempt is made to refer to an object
|
| 68 |
+
defined with a volatile-qualified type through the use of a glvalue with
|
| 69 |
+
a non-volatile-qualified type, the program behavior is undefined.
|
| 70 |
|
| 71 |
`volatile` is a hint to the implementation to avoid aggressive
|
| 72 |
optimization involving the object because the value of the object might
|
| 73 |
+
be changed by means undetectable by an implementation. Furthermore, for
|
| 74 |
+
some implementations, `volatile` might indicate that special hardware
|
| 75 |
+
instructions are required to access the object. See [[intro.execution]]
|
| 76 |
+
for detailed semantics. In general, the semantics of `volatile` are
|
| 77 |
+
intended to be the same in C++as they are in C.
|
| 78 |
|