20 Library introduction [library]

Each library clause contains the following elements, as applicable:155

• (1.1)
  Summary
• (1.2)
  Requirements
• (1.3)
  Detailed specifications
• (1.4)
  References to the C standard library

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.

Paragraphs labeled “Note(s):” or “Example(s):” are informative, other paragraphs are normative.

The contents of the summary and the detailed specifications include:

Requirements describe constraints that shall be met by a C++ program that extends the standard library.

Such extensions are generally one of the following:

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 satisfy the requirements.

For every set of well-defined expression requirements there is a table that specifies an initial set of the valid expressions and their semantics.

Any generic algorithm (Clause [algorithms]) that uses the well-defined expression requirements is described in terms of the valid expressions for its template type parameters.

Template argument requirements are sometimes referenced by name.

See [type.descriptions].

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

The detailed specifications each contain the following elements:

• (1.1)
  name and brief description
• (1.2)
  synopsis (class definition or function declaration, as appropriate)
• (1.3)
  restrictions on template arguments, if any
• (1.4)
  description of class invariants
• (1.5)
  description of function semantics

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

• (2.1)
  constructor(s) and destructor
• (2.2)
  copying, moving & assignment functions
• (2.3)
  comparison 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):158

• (3.1)
  Requires: the preconditions for calling the function
• (3.2)
  Effects: the actions performed by the function
• (3.3)
  Synchronization: the synchronization operations ([intro.multithread]) applicable to the function
• (3.4)
  Postconditions: the observable results established by the function
• (3.5)
  Returns: a description of the value(s) returned by the function
• (3.6)
  Throws: any exceptions thrown by the function, and the conditions that would cause the exception
• (3.7)
  Complexity: the time and/or space complexity of the function
• (3.8)
  Remarks: additional semantic constraints on the function
• (3.9)
  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 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]).

Paragraphs labeled “See also:” contain cross-references to the relevant portions of this International Standard and the ISO C standard.