From Jason Turner

[structure]

C++14 → C++17 5.9 KB 40 lines
Current Draft | LaTeX Source
Archived: C++14 | C++17
Markdown: C++14 | C++17
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp3xwdt7jq/{from.md → to.md} +15 -17
tmp/tmp3xwdt7jq/{from.md → to.md} RENAMED
@@ -1,15 +1,15 @@
1
  ### Structure of each clause <a id="structure">[[structure]]</a>
2
 
3
  #### Elements <a id="structure.elements">[[structure.elements]]</a>
4
 
5
- Each library clause contains the following elements, as applicable:[^2]
6
 
7
  - Summary
8
  - Requirements
9
  - Detailed specifications
10
- - References to the Standard C library
11
 
12
  #### Summary <a id="structure.summary">[[structure.summary]]</a>
13
 
14
  The Summary provides a synopsis of the category, and introduces the
15
  first-level subclauses. Each subclause also provides a summary, listing
@@ -43,12 +43,12 @@ The string and iostream components use an explicit representation of
43
  operations required of template arguments. They use a class template
44
  `char_traits` to define these constraints.
45
 
46
  Interface convention requirements are stated as generally as possible.
47
  Instead of stating “class X has to define a member function
48
- `operator++()`,” the interface requires “for any object `x` of class
49
- `X`, `++x` is defined.” That is, whether the operator is a member is
50
  unspecified.
51
 
52
  Requirements are stated in terms of well-defined expressions that define
53
  valid terms of the types that satisfy the requirements. For every set of
54
  well-defined expression requirements there is a table that specifies an
@@ -61,34 +61,34 @@ Template argument requirements are sometimes referenced by name. See 
61
  [[type.descriptions]].
62
 
63
  In some cases the semantic requirements are presented as C++code. Such
64
  code is intended as a specification of equivalence of a construct to
65
  another construct, not necessarily as the way the construct must be
66
- implemented.[^3]
67
 
68
  #### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
69
 
70
  The detailed specifications each contain the following elements:
71
 
72
  - name and brief description
73
- - synopsis (class definition or function prototype, as appropriate)
74
  - restrictions on template arguments, if any
75
  - description of class invariants
76
  - description of function semantics
77
 
78
  Descriptions of class member functions follow the order (as
79
- appropriate):[^4]
80
 
81
  - constructor(s) and destructor
82
  - copying, moving & assignment functions
83
  - comparison functions
84
  - modifier functions
85
  - observer functions
86
  - operators and other non-member functions
87
 
88
  Descriptions of function semantics contain the following elements (as
89
- appropriate):[^5]
90
 
91
  - *Requires:* the preconditions for calling the function
92
  - *Effects:* the actions performed by the function
93
  - *Synchronization:* the synchronization operations (
94
  [[intro.multithread]]) applicable to the function
@@ -97,24 +97,23 @@ appropriate):[^5]
97
  - *Throws:* any exceptions thrown by the function, and the conditions
98
  that would cause the exception
99
  - *Complexity:* the time and/or space complexity of the function
100
  - *Remarks:* additional semantic constraints on the function
101
  - *Error conditions:* the error conditions for error codes reported by
102
- the function.
103
- - *Notes:* non-normative comments about the function
104
 
105
  Whenever the *Effects:* element specifies that the semantics of some
106
  function `F` are *Equivalent to* some code sequence, then the various
107
  elements are interpreted as follows. If `F`’s semantics specifies a
108
  *Requires:* element, then that requirement is logically imposed prior to
109
  the *equivalent-to* semantics. Next, the semantics of the code sequence
110
- are determined by the *Requires:* , *Effects:* , *Postconditions:* ,
111
- *Returns:* , *Throws:* , *Complexity:* , *Remarks:* , *Error
112
- conditions:* , and *Notes:* specified for the function invocations
113
  contained in the code sequence. The value returned from `F` is specified
114
  by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
115
- non-`void` return from `F` is specified by the *Returns:* elements in
116
  the code sequence. If `F`’s semantics contains a *Throws:* ,
117
  *Postconditions:* , or *Complexity:* element, then that supersedes any
118
  occurrences of that element in the code sequence.
119
 
120
  For non-reserved replacement and handler functions, Clause 
@@ -125,11 +124,11 @@ describes a function definition provided by the implementation. The
125
  provided by either the implementation or a C++program. Where no
126
  distinction is explicitly made in the description, the behavior
127
  described is the required behavior.
128
 
129
  If the formulation of a complexity requirement calls for a negative
130
- number of operations, the actual requirement is zero operations.[^6]
131
 
132
  Complexity requirements specified in the library clauses are upper
133
  bounds, and implementations that provide better complexity guarantees
134
  satisfy the requirements.
135
 
@@ -138,8 +137,7 @@ conditions are listed, together with a suitable explanation, as the
138
  `enum class errc` constants ([[syserr]]).
139
 
140
  #### C library <a id="structure.see.also">[[structure.see.also]]</a>
141
 
142
  Paragraphs labeled “” contain cross-references to the relevant portions
143
- of this International Standard and the ISO C standard, which is
144
- incorporated into this International Standard by reference.
145
 
 
1
  ### Structure of each clause <a id="structure">[[structure]]</a>
2
 
3
  #### Elements <a id="structure.elements">[[structure.elements]]</a>
4
 
5
+ Each library clause contains the following elements, as applicable:[^1]
6
 
7
  - Summary
8
  - Requirements
9
  - Detailed specifications
10
+ - References to the C standard library
11
 
12
  #### Summary <a id="structure.summary">[[structure.summary]]</a>
13
 
14
  The Summary provides a synopsis of the category, and introduces the
15
  first-level subclauses. Each subclause also provides a summary, listing
 
43
  operations required of template arguments. They use a class template
44
  `char_traits` to define these constraints.
45
 
46
  Interface convention requirements are stated as generally as possible.
47
  Instead of stating “class X has to define a member function
48
+ `operator++()`”, the interface requires “for any object `x` of class
49
+ `X`, `++x` is defined”. That is, whether the operator is a member is
50
  unspecified.
51
 
52
  Requirements are stated in terms of well-defined expressions that define
53
  valid terms of the types that satisfy the requirements. For every set of
54
  well-defined expression requirements there is a table that specifies an
 
61
  [[type.descriptions]].
62
 
63
  In some cases the semantic requirements are presented as C++code. Such
64
  code is intended as a specification of equivalence of a construct to
65
  another construct, not necessarily as the way the construct must be
66
+ implemented.[^2]
67
 
68
  #### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
69
 
70
  The detailed specifications each contain the following elements:
71
 
72
  - name and brief description
73
+ - synopsis (class definition or function declaration, as appropriate)
74
  - restrictions on template arguments, if any
75
  - description of class invariants
76
  - description of function semantics
77
 
78
  Descriptions of class member functions follow the order (as
79
+ appropriate):[^3]
80
 
81
  - constructor(s) and destructor
82
  - copying, moving & assignment functions
83
  - comparison functions
84
  - modifier functions
85
  - observer functions
86
  - operators and other non-member functions
87
 
88
  Descriptions of function semantics contain the following elements (as
89
+ appropriate):[^4]
90
 
91
  - *Requires:* the preconditions for calling the function
92
  - *Effects:* the actions performed by the function
93
  - *Synchronization:* the synchronization operations (
94
  [[intro.multithread]]) applicable to the function
 
97
  - *Throws:* any exceptions thrown by the function, and the conditions
98
  that would cause the exception
99
  - *Complexity:* the time and/or space complexity of the function
100
  - *Remarks:* additional semantic constraints on the function
101
  - *Error conditions:* the error conditions for error codes reported by
102
+ the function
 
103
 
104
  Whenever the *Effects:* element specifies that the semantics of some
105
  function `F` are *Equivalent to* some code sequence, then the various
106
  elements are interpreted as follows. If `F`’s semantics specifies a
107
  *Requires:* element, then that requirement is logically imposed prior to
108
  the *equivalent-to* semantics. Next, the semantics of the code sequence
109
+ are determined by the *Requires:* , *Effects:* , *Synchronization:* ,
110
+ *Postconditions:* , *Returns:* , *Throws:* , *Complexity:* , *Remarks:*
111
+ , and *Error conditions:* specified for the function invocations
112
  contained in the code sequence. The value returned from `F` is specified
113
  by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
114
+ non-`void` return from `F` is specified by the `return` statements in
115
  the code sequence. If `F`’s semantics contains a *Throws:* ,
116
  *Postconditions:* , or *Complexity:* element, then that supersedes any
117
  occurrences of that element in the code sequence.
118
 
119
  For non-reserved replacement and handler functions, Clause 
 
124
  provided by either the implementation or a C++program. Where no
125
  distinction is explicitly made in the description, the behavior
126
  described is the required behavior.
127
 
128
  If the formulation of a complexity requirement calls for a negative
129
+ number of operations, the actual requirement is zero operations.[^5]
130
 
131
  Complexity requirements specified in the library clauses are upper
132
  bounds, and implementations that provide better complexity guarantees
133
  satisfy the requirements.
134
 
 
137
  `enum class errc` constants ([[syserr]]).
138
 
139
  #### C library <a id="structure.see.also">[[structure.see.also]]</a>
140
 
141
  Paragraphs labeled “” contain cross-references to the relevant portions
142
+ of this International Standard and the ISO C standard.
 
143