tmp/tmptcr6xmex/{from.md → to.md}
RENAMED
|
@@ -1,37 +1,62 @@
|
|
| 1 |
#### Requirements <a id="structure.requirements">[[structure.requirements]]</a>
|
| 2 |
|
| 3 |
-
Requirements describe constraints that shall be met by a C++
|
| 4 |
-
extends the standard library. Such extensions are generally one of
|
| 5 |
-
following:
|
| 6 |
|
| 7 |
- Template arguments
|
| 8 |
- Derived classes
|
| 9 |
- Containers, iterators, and algorithms that meet an interface
|
| 10 |
-
convention
|
| 11 |
|
| 12 |
The string and iostream components use an explicit representation of
|
| 13 |
operations required of template arguments. They use a class template
|
| 14 |
`char_traits` to define these constraints.
|
| 15 |
|
| 16 |
Interface convention requirements are stated as generally as possible.
|
| 17 |
-
Instead of stating “class X has to define a member function
|
| 18 |
`operator++()`”, the interface requires “for any object `x` of class
|
| 19 |
`X`, `++x` is defined”. That is, whether the operator is a member is
|
| 20 |
unspecified.
|
| 21 |
|
| 22 |
Requirements are stated in terms of well-defined expressions that define
|
| 23 |
-
valid terms of the types that
|
| 24 |
-
well-defined expression requirements there is a
|
| 25 |
-
initial set of the valid expressions and their
|
| 26 |
-
algorithm
|
| 27 |
-
requirements is described in terms of the valid
|
| 28 |
-
template type parameters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 29 |
|
| 30 |
Template argument requirements are sometimes referenced by name. See
|
| 31 |
[[type.descriptions]].
|
| 32 |
|
| 33 |
In some cases the semantic requirements are presented as C++ code. Such
|
| 34 |
code is intended as a specification of equivalence of a construct to
|
| 35 |
another construct, not necessarily as the way the construct must be
|
| 36 |
implemented.[^2]
|
| 37 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
#### Requirements <a id="structure.requirements">[[structure.requirements]]</a>
|
| 2 |
|
| 3 |
+
Requirements describe constraints that shall be met by a C++ program
|
| 4 |
+
that extends the standard library. Such extensions are generally one of
|
| 5 |
+
the following:
|
| 6 |
|
| 7 |
- Template arguments
|
| 8 |
- Derived classes
|
| 9 |
- Containers, iterators, and algorithms that meet an interface
|
| 10 |
+
convention or model a concept
|
| 11 |
|
| 12 |
The string and iostream components use an explicit representation of
|
| 13 |
operations required of template arguments. They use a class template
|
| 14 |
`char_traits` to define these constraints.
|
| 15 |
|
| 16 |
Interface convention requirements are stated as generally as possible.
|
| 17 |
+
Instead of stating “class `X` has to define a member function
|
| 18 |
`operator++()`”, the interface requires “for any object `x` of class
|
| 19 |
`X`, `++x` is defined”. That is, whether the operator is a member is
|
| 20 |
unspecified.
|
| 21 |
|
| 22 |
Requirements are stated in terms of well-defined expressions that define
|
| 23 |
+
valid terms of the types that meet the requirements. For every set of
|
| 24 |
+
well-defined expression requirements there is either a named concept or
|
| 25 |
+
a table that specifies an initial set of the valid expressions and their
|
| 26 |
+
semantics. Any generic algorithm [[algorithms]] that uses the
|
| 27 |
+
well-defined expression requirements is described in terms of the valid
|
| 28 |
+
expressions for its template type parameters.
|
| 29 |
+
|
| 30 |
+
The library specification uses a typographical convention for naming
|
| 31 |
+
requirements. Names in *italic* type that begin with the prefix *Cpp17*
|
| 32 |
+
refer to sets of well-defined expression requirements typically
|
| 33 |
+
presented in tabular form, possibly with additional prose semantic
|
| 34 |
+
requirements. For example, *Cpp17Destructible* ([[cpp17.destructible]])
|
| 35 |
+
is such a named requirement. Names in `constant width` type refer to
|
| 36 |
+
library concepts which are presented as a concept definition [[temp]],
|
| 37 |
+
possibly with additional prose semantic requirements. For example,
|
| 38 |
+
`destructible` [[concept.destructible]] is such a named requirement.
|
| 39 |
|
| 40 |
Template argument requirements are sometimes referenced by name. See
|
| 41 |
[[type.descriptions]].
|
| 42 |
|
| 43 |
In some cases the semantic requirements are presented as C++ code. Such
|
| 44 |
code is intended as a specification of equivalence of a construct to
|
| 45 |
another construct, not necessarily as the way the construct must be
|
| 46 |
implemented.[^2]
|
| 47 |
|
| 48 |
+
Required operations of any concept defined in this document need not be
|
| 49 |
+
total functions; that is, some arguments to a required operation may
|
| 50 |
+
result in the required semantics failing to be met.
|
| 51 |
+
|
| 52 |
+
[*Example 1*: The required `<` operator of the `totally_ordered`
|
| 53 |
+
concept [[concept.totallyordered]] does not meet the semantic
|
| 54 |
+
requirements of that concept when operating on NaNs. — *end example*]
|
| 55 |
+
|
| 56 |
+
This does not affect whether a type models the concept.
|
| 57 |
+
|
| 58 |
+
A declaration may explicitly impose requirements through its associated
|
| 59 |
+
constraints [[temp.constr.decl]]. When the associated constraints refer
|
| 60 |
+
to a concept [[temp.concept]], the semantic constraints specified for
|
| 61 |
+
that concept are additionally imposed on the use of the declaration.
|
| 62 |
+
|