[structure]

To save space, items that do not apply to a Clause are omitted.

For example, if a Clause does not specify any requirements, there will be no “Requirements” subclause.

16.3.2.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:

(2.1)
macros
(2.2)
values
(2.3)
types and alias templates
(2.4)
classes and class templates
(2.5)
functions and function templates
(2.6)
objects and variable templates
(2.7)
concepts

16.3.2.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:

(1.1)
Template arguments
(1.2)
Derived classes
(1.3)
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 prefix Cpp17 refer to sets of well-defined expression requirements typically presented in tabular form, possibly with additional prose semantic requirements.

For example, Cpp17Destructible (Table 35) 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.

For example, destructible ([concept.destructible]) is such a named requirement.

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.125

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 1:

The required < operator of the totally_ordered concept ([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.

125)125)

Although in some cases the code given is unambiguously the optimum implementation.

16.3.2.4 Detailed specifications [structure.specifications]

Descriptions of class member functions follow the order (as appropriate):126

(2.1)
constructor(s) and destructor
(2.2)
copying, moving & assignment functions
(2.3)
comparison operator functions
(2.4)
modifier functions
(2.5)
observer functions
(2.6)
operators and other non-member functions

Descriptions of function semantics contain the following elements (as appropriate):127

(3.1)
Constraints: the conditions for the function's participation in overload resolution ([over.match]).

[Note 1:
Failure to meet such a condition results in the function's silent non-viability.
— end note]

[Example 1:
An implementation can express such a condition via a constraint-expression ([temp.constr.decl]).
— end example]
(3.2)
Mandates: the conditions that, if not met, render the program ill-formed.

[Example 2:
An implementation can express such a condition via the constant-expression in a static_assert-declaration ([dcl.pre]).

If the diagnostic is to be emitted only after the function has been selected by overload resolution, an implementation can express such a condition via a constraint-expression ([temp.constr.decl]) and also define the function as deleted.
— end example]
(3.3)
Constant When: the conditions that are required for a call to the function to be a constant subexpression ([defns.const.subexpr]).
(3.4)
Preconditions: conditions that the function assumes to hold whenever it is called; violation of any preconditions results in undefined behavior.

[Example 3:
An implementation can express some such conditions via the use of a contract assertion, such as a precondition assertion ([dcl.contract.func]).
— end example]
(3.5)
Hardened preconditions: conditions that the function assumes to hold whenever it is called.
- (3.5.1)
  When invoking the function in a hardened implementation, prior to any other observable side effects of the function, contract assertions whose predicates are as described in the hardened precondition are evaluated with a terminating semantic ([basic.contract.eval]).
- (3.5.2)
  When invoking the function in a non-hardened implementation, if any hardened precondition is violated, the program has undefined behavior.
(3.6)
Effects: the actions performed by the function.
(3.7)
Synchronization: the synchronization operations ([intro.multithread]) applicable to the function.
(3.8)
Postconditions: the conditions (sometimes termed observable results) established by the function.

[Example 4:
An implementation can express some such conditions via the use of a contract assertion, such as a postcondition assertion ([dcl.contract.func]).
— end example]
(3.9)
Result: for a typename-specifier, a description of the named type; for an expression, a description of the type and value category of the expression; the expression is an lvalue if the type is an lvalue reference type, an xvalue if the type is an rvalue reference type, and a prvalue otherwise.
(3.10)
Returns: a description of the value(s) returned by the function.
(3.11)
Throws: any exceptions thrown by the function, and the conditions that would cause the exception.
(3.12)
Complexity: the time and/or space complexity of the function.
(3.13)
Remarks: additional semantic constraints on the function.
(3.14)
Error conditions: the error conditions for error codes reported by the function.

Whenever the Effects element specifies that the semantics of some function F 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 the Constraints, Mandates, Constant When, Preconditions, Hardened preconditions, Effects, Synchronization, Postconditions, Returns, Throws, Complexity, Remarks, and Error conditions specified 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 the return 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 behavior describes a function definition provided by the implementation.

The required behavior describes 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.128

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 errc constants ([syserr]).

126)126)

To save space, items that do not apply to a class are omitted.

For example, if a class does not specify any comparison operator functions, there will be no “Comparison operator functions” subclause.

127)127)

To save space, elements that do not apply to a function are omitted.

For example, if a function specifies no preconditions, there will be no Preconditions: element.

128)128)

This simplifies the presentation of complexity requirements in some cases.

16.3.2.5 C library [structure.see.also]

Paragraphs labeled “See also” contain cross-references to the relevant portions of other standards ([intro.refs]).