[description] (original) (raw)
16 Library introduction [library]
16.4 Method of description [description]
This subclause describes the conventions used to specify the C++ standard library.
[conventions] describes other editorial conventions.
16.4.1 Structure of each clause [structure]
16.4.1.1 Elements [structure.elements]
Each library clause contains the following elements, as applicable:151
- Summary
- Requirements
- Detailed specifications
- References to the C standard library
16.4.1.2 Summary [structure.summary]
The Summary provides a synopsis of the category, and introduces the first-level subclauses.
Each subclause also provides a summary, listing the headers specified in the subclause and the library entities provided in each header.
The contents of the summary and the detailed specifications include:
- macros
- values
- types and alias templates
- classes and class templates
- functions and function templates
- objects and variable templates
- concepts
16.4.1.3 Requirements [structure.requirements]
Requirements describe constraints that shall be met by a C++ program that extends the standard library.
Such extensions are generally one of the following:
- Template arguments
- Derived classes
- Containers, iterators, and algorithms that meet an interface convention or model a concept
The string and iostream components use an explicit representation of operations required of template arguments.
They use a class template char_traits to define these constraints.
Interface convention requirements are stated as generally as possible.
Instead of stating “class X has to define a member function operator++()”, the interface requires “for any object x of class X, ++x is defined”.
That is, whether the operator is a member is unspecified.
Requirements are stated in terms of well-defined expressions that define valid terms of the types that meet the requirements.
For every set of well-defined expression requirements there is either a named concept or a table that specifies an initial set of the valid expressions and their semantics.
Any generic algorithm ([algorithms]) that uses the well-defined expression requirements is described in terms of the valid expressions for its template type parameters.
The library specification uses a typographical convention for naming requirements.
Names in italic type that begin with the prefixCpp17 refer to sets of well-defined expression requirements typically presented in tabular form, possibly with additional prose semantic requirements.
For example, Cpp17Destructible (Table 32) is such a named requirement.
Names in constant width type refer to library concepts which are presented as a concept definition ([temp]), possibly with additional prose semantic requirements.
Template argument requirements are sometimes referenced by name.
In some cases the semantic requirements are presented as C++ code.
Such code is intended as a specification of equivalence of a construct to another construct, not necessarily as the way the construct must be implemented.152
Required operations of any concept defined in this document need not be total functions; that is, some arguments to a required operation may result in the required semantics failing to be met.
[ Example
:
The required < operator of the totally_orderedconcept ([concept.totallyordered]) does not meet the semantic requirements of that concept when operating on NaNs.
— end example
]
This does not affect whether a type models the concept.
A declaration may explicitly impose requirements through its associated constraints ([temp.constr.decl]).
When the associated constraints refer to a concept ([temp.concept]), the semantic constraints specified for that concept are additionally imposed on the use of the declaration.
16.4.1.4 Detailed specifications [structure.specifications]
The detailed specifications each contain the following elements:
- name and brief description
- synopsis (class definition or function declaration, as appropriate)
- restrictions on template arguments, if any
- description of class invariants
- description of function semantics
Descriptions of class member functions follow the order (as appropriate):153
- constructor(s) and destructor
- copying, moving & assignment functions
- comparison functions
- modifier functions
- observer functions
- operators and other non-member functions
Descriptions of function semantics contain the following elements (as appropriate):154
- Constraints:the conditions for the function's participation in overload resolution ([over.match]).
[ Note
:
Failure to meet such a condition results in the function's silent non-viability.
— end note
] - Mandates:the conditions that, if not met, render the program ill-formed.
[ Example
:
If the diagnostic is to be emitted only after the function has been selected by overload resolution, an implementation might express such a condition via a constraint-expressionand also define the function as deleted.
— end example
] - Preconditions:the conditions that the function assumes to hold whenever it is called.
- Effects:the actions performed by the function.
- Synchronization:the synchronization operations ([intro.multithread]) applicable to the function.
- Postconditions:the conditions (sometimes termed observable results) established by the function.
- Returns:a description of the value(s) returned by the function.
- Throws:any exceptions thrown by the function, and the conditions that would cause the exception.
- Complexity:the time and/or space complexity of the function.
- Remarks:additional semantic constraints on the function.
- Error conditions:the error conditions for error codes reported by the function.
Whenever the Effects element specifies that the semantics of some functionF are Equivalent to some code sequence, then the various elements are interpreted as follows.
If F's semantics specifies any Constraints or Mandates elements, then those requirements are logically imposed prior to the equivalent-to semantics.
Next, the semantics of the code sequence are determined by theConstraints, Mandates, Preconditions, Effects,Synchronization, Postconditions, Returns, Throws,Complexity, Remarks, and Error conditionsspecified for the function invocations contained in the code sequence.
The value returned from F is specified by F's Returns element, or if F has no Returns element, a non-void return from F is specified by thereturn statements ([stmt.return]) in the code sequence.
If F's semantics contains a Throws,Postconditions, or Complexity element, then that supersedes any occurrences of that element in the code sequence.
For non-reserved replacement and handler functions,[support] specifies two behaviors for the functions in question: their required and default behavior.
The default behaviordescribes a function definition provided by the implementation.
The required behaviordescribes the semantics of a function definition provided by either the implementation or a C++ program.
Where no distinction is explicitly made in the description, the behavior described is the required behavior.
If the formulation of a complexity requirement calls for a negative number of operations, the actual requirement is zero operations.155
Complexity requirements specified in the library clauses are upper bounds, and implementations that provide better complexity guarantees meet the requirements.
Error conditions specify conditions where a function may fail.
The conditions are listed, together with a suitable explanation, as the enum class errcconstants ([syserr]).
16.4.2 Other conventions [conventions]
This subclause describes several editorial conventions used to describe the contents of the C++ standard library.
These conventions are for describingimplementation-defined types, and member functions.
16.4.2.1 Exposition-only functions [expos.only.func]
Several function templates defined in [support] through [thread] and [depr]are only defined for the purpose of exposition.
The declaration of such a function is followed by a comment ending in exposition only.
The following are defined for exposition only to aid in the specification of the library:
template constexpr decay_t decay-copy(T&& v)
noexcept(is_nothrow_convertible_v<T, decay_t>)
{ return std::forward(v); }
constexpr auto synth-three-way = []<class T, class U>(const T& t, const U& u) requires requires { { t < u } -> boolean-testable; { u < t } -> boolean-testable; } { if constexpr (three_way_comparable_with<T, U>) { return t <=> u; } else { if (t < u) return weak_ordering::less; if (u < t) return weak_ordering::greater; return weak_ordering::equivalent; } };
template<class T, class U=T> using synth-three-way-result = decltype(synth-three-way(declval<T&>(), declval<U&>()));
16.4.2.2 Type descriptions [type.descriptions]
16.4.2.2.1 General [type.descriptions.general]
The Requirements subclauses may describe names that are used to specify constraints on template arguments.156
These names are used in library Clauses to describe the types that may be supplied as arguments by a C++ program when instantiating template components from the library.
Certain types defined in [input.output] are used to describe implementation-defined types.
They are based on other types, but with added constraints.
16.4.2.2.2 Exposition-only types [expos.only.types]
Several types defined in [support] through [thread]and [depr] are defined for the purpose of exposition.
The declaration of such a type is followed by a comment ending in exposition only.
[ Example
:
namespace std {
extern "C" using some-handler = int(int, void*, double);
}
The type placeholder some-handler can now be used to specify a function that takes a callback parameter with C language linkage.
— end example
]
16.4.2.2.3 Enumerated types [enumerated.types]
Each enumerated type may be implemented as an enumeration or as a synonym for an enumeration.157
The enumerated type enumerated can be written:
enum enumerated { , , , , … };
inline const (); inline const (); inline const (); inline const (); ⋮
Here, the names ,, etc. representenumerated elementsfor this particular enumerated type.
All such elements have distinct values.
16.4.2.2.4 Bitmask types [bitmask.types]
Each bitmask type can be implemented as an enumerated type that overloads certain operators, as an integer type, or as abitset.
The bitmask type bitmask can be written:
enum bitmask : int_type { = 1 << 0, = 1 << 1, = 1 << 2, = 1 << 3, … };
inline constexpr (); inline constexpr (); inline constexpr (); inline constexpr (); ⋮
constexpr bitmask operator&(bitmask X, bitmask Y) {
return static_cast(
static_cast(X) & static_cast(Y));
}
constexpr bitmask operator|(bitmask X, bitmask Y) {
return static_cast(
static_cast(X) | static_cast(Y));
}
constexpr bitmask operator^(bitmask X, bitmask Y){
return static_cast(
static_cast(X) ^ static_cast(Y));
}
constexpr bitmask operator(bitmask X){
return static_cast(static_cast(X));
}
bitmask& operator&=(bitmask& X, bitmask Y){
X = X & Y; return X;
}
bitmask& operator|=(bitmask& X, bitmask Y) {
X = X | Y; return X;
}
bitmask& operator^=(bitmask& X, bitmask Y) {
X = X ^ Y; return X;
}
Here, the names ,, etc. representbitmask elementsfor this particular bitmask type.
All such elements have distinct, nonzero values such that, for any pair and where , & is nonzero and & is zero.
Additionally, the value 0 is used to represent an empty bitmask, in which no bitmask elements are set.
The following terms apply to objects and values of bitmask types:
- To seta value Y in an object Xis to evaluate the expression X |= Y.
- To cleara value Y in an objectX is to evaluate the expression X &= ~Y.
- The value Y is set in the objectX if the expression X & Y is nonzero.
16.4.2.2.5 Character sequences [character.seq]
The C standard library makes widespread useof characters and character sequences that follow a few uniform conventions:
- A letter is any of the 26 lowercase or 26uppercase letters in the basic execution character set.
- Thedecimal-point characteris the (single-byte) character used by functions that convert between a (single-byte) character sequence and a value of one of the floating-point types.
It is used in the character sequence to denote the beginning of a fractional part.
It is represented in [support] through [thread]and [depr] by a period,'.', which is also its value in the "C"locale, but may change during program execution by a call tosetlocale(int, const char*),158or by a change to alocaleobject, as described in [locales] and [input.output]. - Acharacter sequenceis an array object A that can be declared asT A[N], where T is any of the typeschar,unsigned char, orsigned char ([basic.fundamental]), optionally qualified by any combination ofconstorvolatile.
The initial elements of the array have defined contents up to and including an element determined by some predicate.
A character sequence can be designated by a pointer valueS that points to its first element.
16.4.2.2.5.1 Byte strings [byte.strings]
A null-terminated byte string, or ntbs, is a character sequence whose highest-addressed element with defined content has the value zero (the terminating null character); no other element in the sequence has the value zero.159
The length of an ntbsis the number of elements that precede the terminating null character.
An empty ntbshas a length of zero.
The value of an ntbsis the sequence of values of the elements up to and including the terminating null character.
A static ntbsis an ntbs with static storage duration.160
16.4.2.2.5.2 Multibyte strings [multibyte.strings]
A null-terminated multibyte string, or ntmbs, is an ntbs that constitutes a sequence of valid multibyte characters, beginning and ending in the initial shift state.161
A static ntmbsis an ntmbs with static storage duration.
16.4.2.2.6 Customization Point Object types [customization.point.object]
A customization point object is a function object ([function.objects]) with a literal class type that interacts with program-defined types while enforcing semantic requirements on that interaction.
The type of a customization point object, ignoring cv-qualifiers, shall modelsemiregular ([concepts.object]).
All instances of a specific customization point object type shall be equal ([concepts.equality]).
The type T of a customization point object shall modelinvocable<const T&, Args...> ([concept.invocable]) when the types in Args... meet the requirements specified in that customization point object's definition.
When the types of Args... do not meet the customization point object's requirements, T shall not have a function call operator that participates in overload resolution.
Each customization point object type constrains its return type to model a particular concept.
[ Note
:
Many of the customization point objects in the library evaluate function call expressions with an unqualified name which results in a call to a program-defined function found by argument dependent name lookup ([basic.lookup.argdep]).
To preclude such an expression resulting in a call to unconstrained functions with the same name in namespace std, customization point objects specify that lookup for these expressions is performed in a context that includes deleted overloads matching the signatures of overloads defined in namespace std.
When the deleted overloads are viable, program-defined overloads need be more specialized ([temp.func.order]) or more constrained ([temp.constr.order]) to be used by a customization point object.
— end note
]
16.4.2.3 Functions within classes [functions.within.classes]
For the sake of exposition, [support] through [thread]and [depr] do not describe copy/move constructors, assignment operators, or (non-virtual) destructors with the same apparent semantics as those that can be generated by default ([class.copy.ctor], [class.copy.assign], [class.dtor]).
It is unspecified whether the implementation provides explicit definitions for such member function signatures, or for virtual destructors that can be generated by default.
16.4.2.4 Private members [objects.within.classes]
An implementation may define static or non-static class members, or both, as needed to implement the semantics of the member functions specified in [support]through [thread] and [depr].
For the sake of exposition, some subclauses provide representative declarations, and semantic requirements, for private members of classes that meet the external specifications of the classes.
The declarations for such members are followed by a comment that ends with exposition only, as in:
streambuf* sb;
An implementation may use any technique that provides equivalent observable behavior.