16 Library introduction [library]

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.

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

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.

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.