From Jason Turner

[intro.compliance]

C++17 → C++20 8.4 KB 120 lines
Current Draft | LaTeX Source
Archived: C++17 | C++20
Markdown: C++17 | C++20
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp_h7g41aa/{from.md → to.md} +87 -30
tmp/tmp_h7g41aa/{from.md → to.md} RENAMED
@@ -1,66 +1,123 @@
1
  ## Implementation compliance <a id="intro.compliance">[[intro.compliance]]</a>
2
 
3
  The set of *diagnosable rules* consists of all syntactic and semantic
4
- rules in this International Standard except for those rules containing
5
- an explicit notation that “no diagnostic is required” or which are
6
- described as resulting in “undefined behavior”.
7
 
8
- Although this International Standard states only requirements on C++
9
- implementations, those requirements are often easier to understand if
10
- they are phrased as requirements on programs, parts of programs, or
11
- execution of programs. Such requirements have the following meaning:
12
 
13
- - If a program contains no violations of the rules in this International
14
- Standard, a conforming implementation shall, within its resource
15
- limits, accept and correctly execute[^2] that program.
16
  - If a program contains a violation of any diagnosable rule or an
17
- occurrence of a construct described in this International Standard as
18
  “conditionally-supported” when the implementation does not support
19
  that construct, a conforming implementation shall issue at least one
20
  diagnostic message.
21
  - If a program contains a violation of a rule for which no diagnostic is
22
- required, this International Standard places no requirement on
23
- implementations with respect to that program.
24
 
25
  [*Note 1*: During template argument deduction and substitution, certain
26
  constructs that in other contexts require a diagnostic are treated
27
  differently; see  [[temp.deduct]]. — *end note*]
28
 
29
  For classes and class templates, the library Clauses specify partial
30
- definitions. Private members (Clause  [[class.access]]) are not
31
- specified, but each implementation shall supply them to complete the
32
- definitions according to the description in the library Clauses.
33
 
34
  For functions, function templates, objects, and values, the library
35
  Clauses specify declarations. Implementations shall supply definitions
36
  consistent with the descriptions in the library Clauses.
37
 
38
- The names defined in the library have namespace scope (
39
- [[basic.namespace]]). A C++translation unit ([[lex.phases]]) obtains
40
  access to these names by including the appropriate standard library
41
- header ([[cpp.include]]).
 
42
 
43
  The templates, classes, functions, and objects in the library have
44
- external linkage ([[basic.link]]). The implementation provides
45
- definitions for standard library entities, as necessary, while combining
46
- translation units to form a complete C++program ([[lex.phases]]).
47
 
48
  Two kinds of implementations are defined: a *hosted implementation* and
49
  a *freestanding implementation*. For a hosted implementation, this
50
- International Standard defines the set of available libraries. A
51
- freestanding implementation is one in which execution may take place
52
- without the benefit of an operating system, and has an
53
- *implementation-defined* set of libraries that includes certain
54
- language-support libraries ([[compliance]]).
55
 
56
  A conforming implementation may have extensions (including additional
57
  library functions), provided they do not alter the behavior of any
58
  well-formed program. Implementations are required to diagnose programs
59
- that use such extensions that are ill-formed according to this
60
- International Standard. Having done so, however, they can compile and
61
- execute such programs.
62
 
63
  Each implementation shall include documentation that identifies all
64
  conditionally-supported constructs that it does not support and defines
65
  all locale-specific characteristics.[^3]
66
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
  ## Implementation compliance <a id="intro.compliance">[[intro.compliance]]</a>
2
 
3
  The set of *diagnosable rules* consists of all syntactic and semantic
4
+ rules in this document except for those rules containing an explicit
5
+ notation that “no diagnostic is required” or which are described as
6
+ resulting in “undefined behavior”.
7
 
8
+ Although this document states only requirements on C++ implementations,
9
+ those requirements are often easier to understand if they are phrased as
10
+ requirements on programs, parts of programs, or execution of programs.
11
+ Such requirements have the following meaning:
12
 
13
+ - If a program contains no violations of the rules in this document, a
14
+ conforming implementation shall, within its resource limits, accept
15
+ and correctly execute[^2] that program.
16
  - If a program contains a violation of any diagnosable rule or an
17
+ occurrence of a construct described in this document as
18
  “conditionally-supported” when the implementation does not support
19
  that construct, a conforming implementation shall issue at least one
20
  diagnostic message.
21
  - If a program contains a violation of a rule for which no diagnostic is
22
+ required, this document places no requirement on implementations with
23
+ respect to that program.
24
 
25
  [*Note 1*: During template argument deduction and substitution, certain
26
  constructs that in other contexts require a diagnostic are treated
27
  differently; see  [[temp.deduct]]. — *end note*]
28
 
29
  For classes and class templates, the library Clauses specify partial
30
+ definitions. Private members [[class.access]] are not specified, but
31
+ each implementation shall supply them to complete the definitions
32
+ according to the description in the library Clauses.
33
 
34
  For functions, function templates, objects, and values, the library
35
  Clauses specify declarations. Implementations shall supply definitions
36
  consistent with the descriptions in the library Clauses.
37
 
38
+ The names defined in the library have namespace scope
39
+ [[basic.namespace]]. A C++ translation unit [[lex.phases]] obtains
40
  access to these names by including the appropriate standard library
41
+ header or importing the appropriate standard library named header unit
42
+ [[using.headers]].
43
 
44
  The templates, classes, functions, and objects in the library have
45
+ external linkage [[basic.link]]. The implementation provides definitions
46
+ for standard library entities, as necessary, while combining translation
47
+ units to form a complete C++ program [[lex.phases]].
48
 
49
  Two kinds of implementations are defined: a *hosted implementation* and
50
  a *freestanding implementation*. For a hosted implementation, this
51
+ document defines the set of available libraries. A freestanding
52
+ implementation is one in which execution may take place without the
53
+ benefit of an operating system, and has an *implementation-defined* set
54
+ of libraries that includes certain language-support libraries
55
+ [[compliance]].
56
 
57
  A conforming implementation may have extensions (including additional
58
  library functions), provided they do not alter the behavior of any
59
  well-formed program. Implementations are required to diagnose programs
60
+ that use such extensions that are ill-formed according to this document.
61
+ Having done so, however, they can compile and execute such programs.
 
62
 
63
  Each implementation shall include documentation that identifies all
64
  conditionally-supported constructs that it does not support and defines
65
  all locale-specific characteristics.[^3]
66
 
67
+ ### Abstract machine <a id="intro.abstract">[[intro.abstract]]</a>
68
+
69
+ The semantic descriptions in this document define a parameterized
70
+ nondeterministic abstract machine. This document places no requirement
71
+ on the structure of conforming implementations. In particular, they need
72
+ not copy or emulate the structure of the abstract machine. Rather,
73
+ conforming implementations are required to emulate (only) the observable
74
+ behavior of the abstract machine as explained below.[^4]
75
+
76
+ Certain aspects and operations of the abstract machine are described in
77
+ this document as implementation-defined (for example, `sizeof(int)`).
78
+ These constitute the parameters of the abstract machine. Each
79
+ implementation shall include documentation describing its
80
+ characteristics and behavior in these respects.[^5] Such documentation
81
+ shall define the instance of the abstract machine that corresponds to
82
+ that implementation (referred to as the “corresponding instance” below).
83
+
84
+ Certain other aspects and operations of the abstract machine are
85
+ described in this document as unspecified (for example, order of
86
+ evaluation of arguments in a function call [[expr.call]]). Where
87
+ possible, this document defines a set of allowable behaviors. These
88
+ define the nondeterministic aspects of the abstract machine. An instance
89
+ of the abstract machine can thus have more than one possible execution
90
+ for a given program and a given input.
91
+
92
+ Certain other operations are described in this document as undefined
93
+ (for example, the effect of attempting to modify a const object).
94
+
95
+ [*Note 1*: This document imposes no requirements on the behavior of
96
+ programs that contain undefined behavior. — *end note*]
97
+
98
+ A conforming implementation executing a well-formed program shall
99
+ produce the same observable behavior as one of the possible executions
100
+ of the corresponding instance of the abstract machine with the same
101
+ program and the same input. However, if any such execution contains an
102
+ undefined operation, this document places no requirement on the
103
+ implementation executing that program with that input (not even with
104
+ regard to operations preceding the first undefined operation).
105
+
106
+ The least requirements on a conforming implementation are:
107
+
108
+ - Accesses through volatile glvalues are evaluated strictly according to
109
+ the rules of the abstract machine.
110
+ - At program termination, all data written into files shall be identical
111
+ to one of the possible results that execution of the program according
112
+ to the abstract semantics would have produced.
113
+ - The input and output dynamics of interactive devices shall take place
114
+ in such a fashion that prompting output is actually delivered before a
115
+ program waits for input. What constitutes an interactive device is
116
+ *implementation-defined*.
117
+
118
+ These collectively are referred to as the *observable behavior* of the
119
+ program.
120
+
121
+ [*Note 2*: More stringent correspondences between abstract and actual
122
+ semantics may be defined by each implementation. — *end note*]
123
+