[conforming] (original) (raw)
16 Library introduction [library]
16.4 Library-wide requirements [requirements]
16.4.6 Conforming implementations [conforming]
16.4.6.1 Overview [conforming.overview]
Subclause [conforming] describes the constraints upon, and latitude of, implementations of the C++ standard library.
An implementation's use of
- headers is discussed in [res.on.headers],
- macros in [res.on.macro.definitions],
- non-member functions in [global.functions],
- member functions in [member.functions],
- data race avoidance in [res.on.data.races],
- access specifiers in [protection.within.classes],
- class derivation in [derivation],
- exceptions in [res.on.exception.handling], and
- contract assertions in [res.contract.assertions].
16.4.6.3 Restrictions on macro definitions [res.on.macro.definitions]
The names and global function signatures described in [contents] are reserved to the implementation.
All object-like macros defined by the C standard library and described in this Clause as expanding to integral constant expressions are also suitable for use in #if preprocessing directives, unless explicitly stated otherwise.
16.4.6.4 Non-member functions [global.functions]
It is unspecified whether any non-member functions in the C++ standard library are defined asinline.
A call to a non-member function signature described in [support] through [exec] and[depr] shall behave as if the implementation declared no additional non-member function signatures.155
An implementation shall not declare a non-member function signature with additional default arguments.
Unless otherwise specified, calls made by functions in the standard library to non-operator, non-member functions do not use functions from another namespace which are found through argument-dependent name lookup ([basic.lookup.argdep]).
Effects: *out_stream << value;if (delim != 0) *out_stream << delim;return *this;
— _end note_]
16.4.6.5 Member functions [member.functions]
It is unspecified whether any member functions in the C++ standard library are defined asinline.
For a non-virtual member function described in the C++ standard library, an implementation may declare a different set of member function signatures, provided that any call to the member function that would select an overload from the set of declarations described in this document behaves as if that overload were selected.
[Note 1:
For instance, an implementation can add parameters with default values, or replace a member function with default arguments with two or more member functions with equivalent behavior, or add additional signatures for a member function name.
— _end note_]
16.4.6.7 Constexpr functions and constructors [constexpr.functions]
This document explicitly requires that certain standard library functions areconstexpr ([dcl.constexpr]).
An implementation shall not declare any standard library function signature as constexpr except for those where it is explicitly required.
Within any header that provides any non-defining declarations of constexpr functions or constructors an implementation shall provide corresponding definitions.
16.4.6.8 Requirements for stable algorithms [algorithm.stable]
When the requirements for an algorithm state that it is “stable” without further elaboration, it means:
- For the sort algorithms the relative order of equivalent elements is preserved.
- For the remove and copy algorithms the relative order of the elements that are not removed is preserved.
- For the merge algorithms, for equivalent elements in the original two ranges, the elements from the first range (preserving their original order) precede the elements from the second range (preserving their original order).
16.4.6.9 Reentrancy [reentrancy]
Except where explicitly specified in this document, it is implementation-defined which functions in the C++ standard library may be recursively reentered.
16.4.6.10 Data race avoidance [res.on.data.races]
This subclause specifies requirements that implementations shall meet to preventdata races.
Every standard library function shall meet each requirement unless otherwise specified.
Implementations may prevent data races in cases other than those specified below.
A C++ standard library function shall not directly or indirectly access objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's arguments, including this.
A C++ standard library function shall not directly or indirectly modify objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments, including this.
[Note 1:
This means, for example, that implementations can't use an object with static storage duration for internal purposes without synchronization because doing so can cause a data race even in programs that do not explicitly share objects between threads.
— _end note_]
A C++ standard library function shall not access objects indirectly accessible via its arguments or via elements of its container arguments except by invoking functions required by its specification on those container elements.
Operations on iterators obtained by calling a standard library container or string member function may access the underlying container, but shall not modify it.
[Note 2:
In particular, container operations that invalidate iterators conflict with operations on iterators associated with that container.
— _end note_]
Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races.
Unless otherwise specified, C++ standard library functions shall perform all operations solely within the current thread if those operations have effects that arevisible to users.
[Note 3:
This allows implementations to parallelize operations if there are no visibleside effects.
— _end note_]
16.4.6.11 Properties of library classes [library.class.props]
Unless explicitly stated otherwise, it is unspecified whether any class described in [support] through [exec] and[depr] is a trivially copyable class, a standard-layout class, or an implicit-lifetime class ([class.prop]).
Unless explicitly stated otherwise, it is unspecified whether any class for which trivial relocation (i.e., the effects oftrivially_relocate ([obj.lifetime])) would be semantically equivalent to move-construction of the destination object followed by destruction of the source object is a trivially relocatable class ([class.prop]).
Unless explicitly stated otherwise, it is unspecified whether a class Cis a replaceable class ([class.prop]) if assigning an xvalue a of type C to an object b of type C is semantically equivalent to destroying b and then constructing from a inb's place.
16.4.6.13 Derived classes [derivation]
An implementation may derive any class in the C++ standard library from a class with a name reserved to the implementation.
Certain classes defined in the C++ standard library are required to be derived from other classes in the C++ standard library.
An implementation may derive such a class directly from the required base or indirectly through a hierarchy of base classes with names reserved to the implementation.
In any case:
- Every base class described asvirtualshall be virtual;
- Every base class not specified asvirtual shall not be virtual;
- Unless explicitly stated otherwise, types with distinct names shall be distinct types.
All types specified in the C++ standard library shall be non-final types unless otherwise specified.
16.4.6.14 Restrictions on exception handling [res.on.exception.handling]
Any of the functions defined in the C++ standard librarycan report a failure by throwing an exception of a type described in its Throws: paragraph, or of a type derived from a type named in the Throws: paragraph that would be caught by a handler ([except.handle]) for the base type.
Functions from the C standard library shall not throw exceptions156except when such a function calls a program-supplied function that throws an exception.157
Destructor operations defined in the C++ standard library shall not throw exceptions.
Every destructor in the C++ standard library shall behave as if it had a non-throwing exception specification ([except.spec]).
Functions defined in the C++ standard librarythat do not have a Throws: paragraph but do have a potentially-throwing exception specification may throw implementation-defined exceptions.158
An implementation may strengthen the exception specification for a non-virtual function by adding a non-throwing exception specification.
16.4.6.16 Value of error codes [value.error.codes]
Certain functions in the C++ standard library report errors via astd::error_code object.
That object'scategory() member shall return std::system_category() for errors originating from the operating system, or a reference to animplementation-defined error_category object for errors originating elsewhere.
The implementation shall define the possible values of value() for each of these error categories.
[Example 1:
For operating systems that are based on POSIX, implementations should define the std::system_category() values as identical to the POSIX errno values, with additional values as defined by the operating system's documentation.
Implementations for operating systems that are not based on POSIX should define values identical to the operating system's values.
For errors that do not originate from the operating system, the implementation may provide enums for the associated values.
— _end example_]
16.4.6.17 Moved-from state of library types [lib.types.movedfrom]
Objects of types defined in the C++ standard library may be moved from ([class.copy.ctor]).
Move operations may be explicitly specified or implicitly generated.
Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state ([defns.valid]).
An object of a type defined in the C++ standard library may be move-assigned ([class.copy.assign]) to itself.
Unless otherwise specified, such an assignment places the object in a valid but unspecified state.