Unless otherwise specified,
the behavior of a C++ program is undefined if it adds declarations or definitions to namespace
std
or to a namespace within namespace
std.
Unless explicitly prohibited,
a program may add a template specialization for
any standard library class template
to namespace
std provided that
(a) the added declaration
depends on at least one program-defined type
and
(b) the specialization meets the standard library requirements
for the original template.160
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
and
(b) the instantiation meets the standard library requirements for the
original template.
Let F denote
a standard library function ([global.functions]),
a standard library static member function,
or an instantiation
of a standard library function template.
Unless F is designated
an addressable function,
the behavior of a C++ program is unspecified (possibly ill-formed)
if it explicitly or implicitly attempts
to form a pointer
to F.
Moreover,
the behavior of a C++ program is unspecified (possibly ill-formed)
if it attempts to form a reference
to F
or
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.
Any
library code that instantiates other library templates
must be prepared to work adequately with any user-supplied specialization
that meets the minimum requirements of this document.
The behavior of a C++ program is undefined if it adds declarations or definitions to namespace
posix
or to a namespace within namespace
posix
unless otherwise specified.
The namespace posix is reserved for use by
ISO/IEC/IEEE 9945 and other POSIX standards.
The name stossc is reserved as a
member function for previous standardization, and may not be used as a name for
function-like macros in portable code.
A translation unit shall not #define or #undef
names lexically identical
to keywords,
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,161
both in namespace std and in the global namespace.
Each
global function signature declared with
external linkage in a header is reserved to the
implementation to designate that function signature with
external linkage.162
Each name from the C standard library declared with external linkage
is reserved to the implementation for use as a name with
extern"C"
linkage,
both in namespace std and in the global namespace.
Each function signature from the C standard library declared with
external linkage
is reserved to the implementation for use as
a function signature with both
extern"C"
and
extern"C++"
linkage,163
or as a name of namespace scope in the global namespace.
The list of such reserved function
signatures with external linkage includes
setjmp(jmp_buf),
declared or defined in <csetjmp>,
and
va_end(va_list),
declared or defined in
<cstdarg>.
The function signatures declared in
<cuchar>,
<cwchar>,
and
<cwctype>
are always reserved, notwithstanding the restrictions imposed in subclause
4.5.1 of Amendment 1 to the C Standard for these headers.
For each type T from the C standard library,
the types
::T
and
std::T
are reserved to the implementation and, when defined,
::T
shall be identical to
std::T.
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.
Virtual member function signatures defined
for a base class in the C++ standard
library may be overridden in a derived class defined in the program ([class.virtual]).
A C++ program may provide the definition for any of the following
dynamic memory allocation function signatures declared in header
<new> ([basic.stc.dynamic], [new.syn]):
A C++ program may install different handler functions during execution, by
supplying a pointer to a function defined in the program or the library
as an argument to (respectively):
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.
For replacement functions ([new.delete]), if the installed replacement function does not
implement the semantics of the applicable
Required behavior: paragraph.
For handler functions ([new.handler], [terminate.handler]),
if the installed handler function does not implement the semantics of the applicable
Required behavior: paragraph.
If any replacement function or handler function or destructor operation exits via an exception,
unless specifically allowed
in the applicable
Required behavior: paragraph.
If an incomplete type ([basic.types.general]) is used as a template
argument when instantiating a template component or evaluating a concept, unless specifically
allowed for that component.
If an argument to a function has an invalid value (such
as a value outside the domain of the function or a pointer invalid for its
intended use), the behavior is undefined.
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 the type of a parameter is a forwarding reference ([temp.deduct.call])
that is deduced to an lvalue reference type, then
the argument is not bound to an rvalue reference.
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.
The implementation
is free to optimize away aliasing checks which would possibly be needed if the argument was
an lvalue.
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.
A sequence Args of template arguments is said to
model a concept C
if Args
satisfies C ([temp.constr.decl]) and
meets all semantic requirements (if any)
given in the specification of C.
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.
If the semantic requirements of a declaration's
constraints ([structure.requirements]) are not modeled at the point of use,
the program is ill-formed, no diagnostic required.