tmp/tmptcldlpau/{from.md → to.md}
RENAMED
|
@@ -1,27 +1,27 @@
|
|
| 1 |
#### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
|
| 2 |
|
| 3 |
The detailed specifications each contain the following elements:
|
| 4 |
|
| 5 |
- name and brief description
|
| 6 |
-
- synopsis (class definition or function
|
| 7 |
- restrictions on template arguments, if any
|
| 8 |
- description of class invariants
|
| 9 |
- description of function semantics
|
| 10 |
|
| 11 |
Descriptions of class member functions follow the order (as
|
| 12 |
-
appropriate):[^
|
| 13 |
|
| 14 |
- constructor(s) and destructor
|
| 15 |
- copying, moving & assignment functions
|
| 16 |
- comparison functions
|
| 17 |
- modifier functions
|
| 18 |
- observer functions
|
| 19 |
- operators and other non-member functions
|
| 20 |
|
| 21 |
Descriptions of function semantics contain the following elements (as
|
| 22 |
-
appropriate):[^
|
| 23 |
|
| 24 |
- *Requires:* the preconditions for calling the function
|
| 25 |
- *Effects:* the actions performed by the function
|
| 26 |
- *Synchronization:* the synchronization operations (
|
| 27 |
[[intro.multithread]]) applicable to the function
|
|
@@ -30,24 +30,23 @@ appropriate):[^5]
|
|
| 30 |
- *Throws:* any exceptions thrown by the function, and the conditions
|
| 31 |
that would cause the exception
|
| 32 |
- *Complexity:* the time and/or space complexity of the function
|
| 33 |
- *Remarks:* additional semantic constraints on the function
|
| 34 |
- *Error conditions:* the error conditions for error codes reported by
|
| 35 |
-
the function
|
| 36 |
-
- *Notes:* non-normative comments about the function
|
| 37 |
|
| 38 |
Whenever the *Effects:* element specifies that the semantics of some
|
| 39 |
function `F` are *Equivalent to* some code sequence, then the various
|
| 40 |
elements are interpreted as follows. If `F`’s semantics specifies a
|
| 41 |
*Requires:* element, then that requirement is logically imposed prior to
|
| 42 |
the *equivalent-to* semantics. Next, the semantics of the code sequence
|
| 43 |
-
are determined by the *Requires:* , *Effects:* , *
|
| 44 |
-
*
|
| 45 |
-
|
| 46 |
contained in the code sequence. The value returned from `F` is specified
|
| 47 |
by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
|
| 48 |
-
non-`void` return from `F` is specified by the
|
| 49 |
the code sequence. If `F`’s semantics contains a *Throws:* ,
|
| 50 |
*Postconditions:* , or *Complexity:* element, then that supersedes any
|
| 51 |
occurrences of that element in the code sequence.
|
| 52 |
|
| 53 |
For non-reserved replacement and handler functions, Clause
|
|
@@ -58,11 +57,11 @@ describes a function definition provided by the implementation. The
|
|
| 58 |
provided by either the implementation or a C++program. Where no
|
| 59 |
distinction is explicitly made in the description, the behavior
|
| 60 |
described is the required behavior.
|
| 61 |
|
| 62 |
If the formulation of a complexity requirement calls for a negative
|
| 63 |
-
number of operations, the actual requirement is zero operations.[^
|
| 64 |
|
| 65 |
Complexity requirements specified in the library clauses are upper
|
| 66 |
bounds, and implementations that provide better complexity guarantees
|
| 67 |
satisfy the requirements.
|
| 68 |
|
|
|
|
| 1 |
#### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
|
| 2 |
|
| 3 |
The detailed specifications each contain the following elements:
|
| 4 |
|
| 5 |
- name and brief description
|
| 6 |
+
- synopsis (class definition or function declaration, as appropriate)
|
| 7 |
- restrictions on template arguments, if any
|
| 8 |
- description of class invariants
|
| 9 |
- description of function semantics
|
| 10 |
|
| 11 |
Descriptions of class member functions follow the order (as
|
| 12 |
+
appropriate):[^3]
|
| 13 |
|
| 14 |
- constructor(s) and destructor
|
| 15 |
- copying, moving & assignment functions
|
| 16 |
- comparison functions
|
| 17 |
- modifier functions
|
| 18 |
- observer functions
|
| 19 |
- operators and other non-member functions
|
| 20 |
|
| 21 |
Descriptions of function semantics contain the following elements (as
|
| 22 |
+
appropriate):[^4]
|
| 23 |
|
| 24 |
- *Requires:* the preconditions for calling the function
|
| 25 |
- *Effects:* the actions performed by the function
|
| 26 |
- *Synchronization:* the synchronization operations (
|
| 27 |
[[intro.multithread]]) applicable to the function
|
|
|
|
| 30 |
- *Throws:* any exceptions thrown by the function, and the conditions
|
| 31 |
that would cause the exception
|
| 32 |
- *Complexity:* the time and/or space complexity of the function
|
| 33 |
- *Remarks:* additional semantic constraints on the function
|
| 34 |
- *Error conditions:* the error conditions for error codes reported by
|
| 35 |
+
the function
|
|
|
|
| 36 |
|
| 37 |
Whenever the *Effects:* element specifies that the semantics of some
|
| 38 |
function `F` are *Equivalent to* some code sequence, then the various
|
| 39 |
elements are interpreted as follows. If `F`’s semantics specifies a
|
| 40 |
*Requires:* element, then that requirement is logically imposed prior to
|
| 41 |
the *equivalent-to* semantics. Next, the semantics of the code sequence
|
| 42 |
+
are determined by the *Requires:* , *Effects:* , *Synchronization:* ,
|
| 43 |
+
*Postconditions:* , *Returns:* , *Throws:* , *Complexity:* , *Remarks:*
|
| 44 |
+
, and *Error conditions:* specified for the function invocations
|
| 45 |
contained in the code sequence. The value returned from `F` is specified
|
| 46 |
by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
|
| 47 |
+
non-`void` return from `F` is specified by the `return` statements in
|
| 48 |
the code sequence. If `F`’s semantics contains a *Throws:* ,
|
| 49 |
*Postconditions:* , or *Complexity:* element, then that supersedes any
|
| 50 |
occurrences of that element in the code sequence.
|
| 51 |
|
| 52 |
For non-reserved replacement and handler functions, Clause
|
|
|
|
| 57 |
provided by either the implementation or a C++program. Where no
|
| 58 |
distinction is explicitly made in the description, the behavior
|
| 59 |
described is the required behavior.
|
| 60 |
|
| 61 |
If the formulation of a complexity requirement calls for a negative
|
| 62 |
+
number of operations, the actual requirement is zero operations.[^5]
|
| 63 |
|
| 64 |
Complexity requirements specified in the library clauses are upper
|
| 65 |
bounds, and implementations that provide better complexity guarantees
|
| 66 |
satisfy the requirements.
|
| 67 |
|