Unless explicitly prohibited,
a program may add a template specialization for
any standard library class template
std provided that
(a) the added declaration
depends on at least one program-defined type
(b) the specialization meets the standard library requirements
for the original template.163
The behavior of a C++ program is undefined
if it declares an explicit or partial specialization
of any standard library variable template,
except where explicitly permitted by the specification of that variable template.
A program may explicitly instantiate
a class template defined in the standard library
only if the declaration
(a) depends on the name of at least one program-defined type
(b) the instantiation meets the standard library requirements for the
the behavior of a C++ program is unspecified (possibly ill-formed)
if it attempts to form a reference
if it attempts to form a pointer-to-member designating
either a standard library non-static member function ([member.functions])
or an instantiation of a standard library member function template.
Other than in namespace std
or in a namespace
within namespace std,
a program may provide
an overload for any library function template
designated as a customization point,
the overload's declaration depends
on at least one user-defined type
the overload meets the standard library requirements
for the customization point.164
Any library customization point
must be prepared
to work adequately
with any user-defined overload
that meets the minimum requirements
of this document.
an implementation can elect,
under the as-if rule ([intro.execution]),
to provide any customization point
in the form
of an instantiated function object ([function.objects])
even though the customization point's specification
is in the form
of a function template.
The template parameters
of each such function object
and the function parameters
and return type
of the object's operator()
must match those
of the corresponding customization point's specification.
A translation unit shall not #define or #undef
names lexically identical
to the identifiers listed in Table 4, or
to the attribute-tokens described in [dcl.attr],
except that the names likely and unlikely may be
defined as function-like macros ([cpp.replace]).
Each name declared as an object with external linkage
in a header is reserved to the implementation to designate that library
object with external linkage,165
both in namespace std and in the global namespace.
Each function signature from the C standard library declared with
is reserved to the implementation for use as
a function signature with both
or as a name of namespace scope in the global namespace.
The function signatures declared in
are always reserved, notwithstanding the restrictions imposed in subclause
4.5.1 of Amendment 1 to the C Standard for these headers.
If a file with a name
equivalent to the derived file name for one of the C++ standard library headers
is not provided as part of the implementation, and a file with that name
is placed in any of the standard places for a source file to be included,
the behavior is undefined.
In certain cases (replacement functions, handler functions, operations on types used to
instantiate standard library template components), the C++ standard library depends on
components supplied by a C++ program.
If these components do not meet their requirements, this document places no requirements
on the implementation.
If a function argument is described as being an array,
the pointer actually passed to the function shall have a value such that all
address computations and accesses to objects (that would be valid if the
pointer did point to the first element of such an array) are in fact valid.
If a function argument is bound to an rvalue reference parameter, the implementation may
assume that this parameter is a unique reference to this argument,
except that the argument passed to a move-assignment operator may be
a reference to *this ([lib.types.movedfrom]).
If a program casts
an lvalue to an xvalue while passing that lvalue to a library function
(e.g., by calling the function with the argument std::move(x)), the program
is effectively asking that function to treat that lvalue as a temporary object.
is free to optimize away aliasing checks which would possibly be needed if the argument was
Modifying an object of a standard library type that is
shared between threads risks undefined behavior unless objects of that type are explicitly
specified as being shareable without data races or the user supplies a locking mechanism.
If an object of a standard library type is accessed, and
the beginning of the object's lifetime
does not happen before the access, or
the access does not happen before the end of the object's lifetime,
the behavior is undefined unless otherwise specified.
If the validity or meaning of a program
depends on whether a sequence of template arguments models a concept, and
the concept is satisfied but not modeled,
the program is ill-formed, no diagnostic required.