20 Library introduction [library]

20.4 Method of description (Informative) [description]

20.4.1 Structure of each clause [structure]

20.4.1.4 Detailed specifications [structure.specifications]

The detailed specifications each contain the following elements:

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

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

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 a Requires element, then that requirement is logically imposed prior to the equivalent-to semantics. Next, the semantics of the code sequence are determined by the Requires, 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 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, Clause [language.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.159

Complexity requirements specified in the library clauses are upper bounds, and implementations that provide better complexity guarantees satisfy 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]).

To save space, items that do not apply to a class are omitted. For example, if a class does not specify any comparison functions, there will be no “Comparison functions” subclause.

To save space, items that do not apply to a function are omitted. For example, if a function does not specify any further preconditions, there will be no Requires: paragraph.

This simplifies the presentation of complexity requirements in some cases.