This subclause describes the conventions used to specify the C++ standard library. [structure] describes the structure of the normative Clauses [language.support] through [thread] and Annex [depr]. [conventions] describes other editorial conventions.
Each library clause contains the following elements, as applicable:161
Summary
Requirements
Detailed specifications
References to the Standard C library
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.
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.
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
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.162
Although in some cases the code given is unambiguously the optimum implementation.
The detailed specifications each contain the following elements:
name and brief description
synopsis (class definition or function prototype, 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):163
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):164
Requires: the preconditions for calling the function
Effects: the actions performed by the function
Synchronization: the synchronization operations ([intro.multithread]) applicable to the function
Postconditions: the 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.
Notes: non-normative comments about 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:, Postconditions:, Returns:, Throws:, Complexity:, Remarks:, Error conditions:, and Notes: 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 Returns: elements 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.165
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.
Paragraphs labeled “See also:” contain cross-references to the relevant portions of this International Standard and the ISO C standard, which is incorporated into this International Standard by reference.
This subclause describes several editorial conventions used to describe the contents of the C++ standard library. These conventions are for describing implementation-defined types ([type.descriptions]), and member functions ([functions.within.classes]).
The Requirements subclauses may describe names that are used to specify constraints on template arguments.166 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 Clause [input.output] are used to describe implementation-defined types. They are based on other types, but with added constraints.
Examples from [utility.requirements] include: EqualityComparable, LessThanComparable, CopyConstructible. Examples from [iterator.requirements] include: InputIterator, ForwardIterator, Function, Predicate.
Several types defined in Clause [input.output] are enumerated types. Each enumerated type may be implemented as an enumeration or as a synonym for an enumeration.167
The enumerated type enumerated can be written:
enum enumerated { V0, V1, V2, V3, ..... }; static const enumerated C0 (V0); static const enumerated C1 (V1); static const enumerated C2 (V2); static const enumerated C3 (V3); .....
Here, the names C0, C1, etc. represent enumerated elements for this particular enumerated type. All such elements have distinct values.
Such as an integer type, with constant integer values ([basic.fundamental]).
Several types defined in Clauses [language.support] through [thread] and Annex [depr] are bitmask types. Each bitmask type can be implemented as an enumerated type that overloads certain operators, as an integer type, or as a bitset ([template.bitset]).
The bitmask type bitmask can be written:
// For exposition only. // int_type is an integral type capable of // representing all values of the bitmask type. enum bitmask : int_type { V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 << 3, ..... }; constexpr bitmask C0(V0); constexpr bitmask C1(V1); constexpr bitmask C2(V2); constexpr bitmask C3(V3); ..... constexpr bitmask operator&(bitmask X, bitmask Y) { return static_cast<bitmask>( static_cast<int_type>(X) & static_cast<int_type>(Y)); } constexpr bitmask operator|(bitmask X, bitmask Y) { return static_cast<bitmask>( static_cast<int_type>(X) | static_cast<int_type>(Y)); } constexpr bitmask operator^(bitmask X, bitmask Y){ return static_cast<bitmask>( static_cast<int_type>(X) ^ static_cast<int_type>(Y)); } constexpr bitmask operator~(bitmask X){ return static_cast<bitmask>(~static_cast<int_type>(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 C0, C1, etc. represent bitmask elements for this particular bitmask type. All such elements have distinct, nonzero values such that, for any pair Ci and Cj where i != j, Ci & Ci is nonzero and Ci & Cj is zero. Additionally, the value 0 is used to represent an empty bitmask, in which no bitmask elements are set.
The C standard library makes widespread use of characters and character sequences that follow a few uniform conventions:
A letter is any of the 26 lowercase or 26 uppercase letters in the basic execution character set.168
The decimal-point character is 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 Clauses [language.support] through [thread] and Annex [depr] by a period, '.', which is also its value in the "C" locale, but may change during program execution by a call to setlocale(int, const char*),169 or by a change to a locale object, as described in Clauses [locales] and [input.output].
A character sequence is an array object ([dcl.array]) A that can be declared as T A[N], where T is any of the types char, unsigned char, or signed char ([basic.fundamental]), optionally qualified by any combination of const or volatile. 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 value S that points to its first element.
Note that this definition differs from the definition in ISO C 7.1.1.
declared in <clocale> ([c.locales]).
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.170
The length of an ntbs is the number of elements that precede the terminating null character. An empty ntbs has a length of zero.
The value of an ntbs is the sequence of values of the elements up to and including the terminating null character.
Many of the objects manipulated by function signatures declared in <cstring> ([c.strings]) are character sequences or ntbss. The size of some of these character sequences is limited by a length value, maintained separately from the character sequence.
A string literal, such as "abc", is a static ntbs.
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.172
An ntbs that contains characters only from the basic execution character set is also an ntmbs. Each multibyte character then consists of a single byte.
For the sake of exposition, Clauses [language.support] through [thread] and Annex [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.ctor], [class.dtor], [class.copy]).
Clauses [language.support] through [thread] and Annex [depr] do not specify the representation of classes, and intentionally omit specification of class members ([class.mem]). An implementation may define static or non-static class members, or both, as needed to implement the semantics of the member functions specified in Clauses [language.support] through [thread] and Annex [depr].
Objects of certain classes are sometimes required by the external specifications of their classes to store data, apparently in member objects. For the sake of exposition, some subclauses provide representative declarations, and semantic requirements, for private member objects of classes that meet the external specifications of the classes. The declarations for such member objects and the definitions of related member types are followed by a comment that ends with exposition only, as in:
streambuf* sb; // exposition only
An implementation may use any technique that provides equivalent external behavior.