The C++ standard library provides a wide range of facilities that are usable in standard C++.
Category
The
provides components that are required by certain parts of the C++ language, such as memory allocation (
/
) and
.
The
describes library components that C++ programs may use to perform compile-time validation of
and perform function dispatch based on properties of types.
(since C++20)The
provides a consistent framework for reporting errors in a C++ program, including
.
The
provides components for memory management, including
and
(since C++11).
The
includes components used by other library elements, such as a
for dynamic storage management, and components used as infrastructure in C++ programs, such as
and(since C++11)
.
The
,
,
(since C++20), and
libraries provide a C++ program with access to a subset of the most widely used algorithms and data structures.
The
provides support for manipulating text represented as homogeneous sequences of following types: char, char8_t(since C++20), char16_t, char32_t(since C++11), wchar_t, and any other character-like types.
The
provides
matching and searching(since C++11), utilities for
(since C++20) and
(since C++26), and
.
The
provides
and
components that extend support for numeric processing. The
component provides support for n-at-a-time processing, potentially implemented as parallel operations on platforms that support such processing. The
provides facilities for generating pseudo-random numbers.(since C++11)
The
provides generally useful time utilities.
The
provides the
that are the primary mechanism for C++ program input and output. They can be used with other elements of the library, particularly strings, locales, and iterators.
The
library provides a framework for managing asynchronous execution on generic execution resources.
(since C++26)Library contents
The C++ standard library provides definitions for the
and
described in the synopses of the
, unless otherwise specified.
All library entities except
and
are defined within the namespace std or
nested within namespace std (except the entities for the C standard library facilities, see below). It is unspecified whether names declared in a specific namespace are declared directly in that namespace or in an
inside that namespace.(since C++11)
Each element of the C++ standard library is declared or defined (as appropriate) in a header. A header is not necessarily a source file, nor are the sequences delimited by < and > in header names necessarily valid source file names.
The C++ standard library provides the C++ library headers and additional C++ headers for C library facilities (see “
” page for descriptions):
C++ library headers
Headers added in C++11
Headers added in C++14
Headers added in C++17
Headers added in C++20
Headers added in C++23
Headers added in C++26
Removed headers
(since C++11)(deprecated in C++17)(removed in C++26)
(deprecated in C++98)(removed in C++26)C++ headers for C library facilities
Headers added in C++11
Removed headers
(since C++11)(deprecated in C++17)(removed in C++20)
(removed in C++20)
(since C++11)(deprecated in C++17)(removed in C++20)
(since C++11)(deprecated in C++17)(removed in C++20)
(since C++11)(deprecated in C++17)(removed in C++20)A
has an implementation-defined set of headers, see
for the minimal requirement on the set of headers.
C standard library
The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to ensure static type safety. The descriptions of many library functions rely on the C standard library for the semantics of those functions.
In some cases, the signatures specified in standard C++ may be different from the signatures in the C standard library, and additional overloads may be declared, but the behavior and the preconditions (including those implied by C's
)(since C++17) are the same unless otherwise stated.
For compatibility with the C standard library, the C++ standard library provides the C headers listed below. The intended use of these headers is for interoperability only. It is possible that C++ source files need to include one of these headers in order to be valid ISO C. Source files that are not intended to also be valid ISO C should not use any of the C headers. See
for descriptions.
C headers
Headers added in C++11
Headers added in C++23
Headers added in C++26
Except otherwise noted, the contents of each header cxxx is the same as that of the corresponding header xxx.h as specified in the
. In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope of the namespace std. It is unspecified whether these names (including any overloads added) are first declared within the global namespace scope and are then injected into namespace std by explicit
.
Names which are defined as macros in C (
,
,
,
,
and
) must be defined as macros in the C++ standard library, even if C grants license for implementation as functions.
Names that are defined as functions in C must be defined as functions in the C++ standard library. This disallows the practice, allowed in C, of providing a masking macro in addition to the function prototype. The only way to achieve equivalent inline behavior in C++ is to provide a definition as an extern
.
Identifiers that are keywords or operators in C++ cannot be defined as macros in C++ standard library headers. In particular, including the standard header
has no effect.
Names associated with safe functions in standard C (since C++17)
If any C++ header is included, it is implementation-defined whether any of the following C standard Annex K names is declared in the global namespace (none of them is declared in namespace std):
C standard Annex K names
Using the library
The entities in the C++ standard library are defined in headers, whose contents are made available to a translation unit when it contains the appropriate
preprocessing directive.
A translation unit may include library headers in any order. Each may be included more than once, with no effect different from being included exactly once, except that the effect of including either
or
depends each time on the lexically current definition of NDEBUG.
A translation unit can only include a header outside of any declaration or definition, and lexically before the first reference in that translation unit to any of the entities declared in that header. No diagnostic is required.
The
, or, for a freestanding implementation, the subset of such headers that are provided by the implementation, are collectively known as the importable C++ library headers.
The contents of importable C++ library headers are made available to a translation unit when it contains the appropriate
.
(since C++20)Importing modules
The C++ standard library provides the following C++ library modules:
The
std exports declarations in namespace std that are provided by the importable C++ library headers (e.g.
from
) and the
C++ headers for C library facilities
(e.g.
from
). It additionally exports declarations in the global namespace for the storage
and
functions that are provided by
(e.g.
).
The named module std.compat exports the same declarations as the named module std, and additionally exports declarations in the global namespace corresponding to the declarations in namespace std that are provided by the C++ headers for C library facilities (e.g.
).
For each declaration in the standard library,
the module it
is unspecified, and
it denotes the same
regardless of whether it was made reachable through including a header, importing a header unit, or importing a C++ library module.
(since C++23)Linkage
Entities in the C++ standard library have
storage duration#external linkage
. Unless otherwise specified, objects and functions have the default extern"C++"
.
Whether a name from the C standard library declared with external linkage has extern"C" or extern"C++" linkage is implementation-defined. The C++ standard recommends using extern"C++" in this case.
Objects and functions defined in the library and required by a C++ program are included in the program prior to program startup.
Requirements on standard library implementations
Guarantees
A C++ header must provide
and
that appear in
the synopsis of that header, or
the synopsis of another header which is appeared to be included in the synopsis of that header.
For types and macros defined in multiple headers (such as
), including any number of these headers in any order never violates the
.
Unless otherwise specified, all
defined by the C standard library that expand to integral
can be used in
preprocessing directives.
Calling a standard library non-member function signature always results in actually calling that function. Therefore a conforming standard library implementation cannot define additional non-member functions that may be called by a valid C++ program.
Non-member function signatures are never declared with additional
.
Unless otherwise specified, calls made by functions in the standard library to non-operator, non-member functions do not use functions from another
which are found through
argument-dependent name lookup
.
For each
of a function (template) within a class (template) definition, no other declaration is provided for that function (template).
Standard library function signatures can only be declared as constexpr if they are required to be
(libstdc++ cmath
here). If a header provides any non-defining declarations of constexpr functions or constructors, the corresponding definitions should also be provided within that header.
Unless otherwise specified, each standard library function should meet each of the following requirements to prevent
:
A C++ standard library function cannot (directly or indirectly) access objects 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 cannot (directly or indirectly) modify objects 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. For example, an object with static storage duration cannot be used for internal purposes without synchronization because doing so can cause a data race even in programs that do not explicitly share objects between threads.
A C++ standard library function cannot access objects indirectly accessible via its arguments or via elements of its
arguments except by invoking functions required by its specification on those container elements.
An operation on
obtained by calling a standard library container or string member function can access, but not modify, the underlying container. In particular, container operations that invalidate iterators conflict with operations on iterators associated with that container.
A C++ standard library function can only perform all operations solely within the current thread if those operations have effects that are
to users. Operations without visible side effects can be parallelized.
(since C++11)For each class defined in the C++ standard library required to be
from another class defined in the C++ standard library,
the base class must be
if it is specified as virtual,
the base class cannot be virtual if it is not specified as virtual, and
unless otherwise specified, types with distinct names shall be distinct types.
Unless otherwise specified, all types specified in the C++ standard library are non-
types.
(since C++11)If a function defined in the C++ standard library is specified to throw an
(in a particular situation) of a given type, the exception thrown can only have that type or a type derived from that type so that an exception handler for the base type can catch it.
Functions from the C standard library can only throw exceptions when such a function calls a program-supplied function that throws an exception (
and
meet this condition).
Destructor operations defined in the C++ standard library never throw exceptions. Every destructor in the C++ standard library behaves as if it had a
non-throwing exception specification
.
If a function in the C++ standard library report errors via a
object, that object's
member must return
for errors originating from the operating system, or a reference to an implementation-defined
object for errors originating elsewhere. The possible values of
for each of these error categories should be defined.
Objects of types defined in the C++ standard library may be
. Move operations can either be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects will be placed in a valid but unspecified state.
An object of a type defined in the C++ standard library may be
to itself. Unless otherwise specified, such an assignment places the object in a valid but unspecified state.
(since C++11)Implementation freedom
It is unspecified whether any member or non-member functions in the C++ standard library are defined as
.
For a non-
C++ standard library member function, a different set of member function signatures can be declared, provided that any call to that member function that would select an overload from the given set of declarations behaves as if that overload was selected. This allows, for instance:
adding parameters with default arguments,
replacing a member function with default arguments with two or more member functions with equivalent behavior, or
adding additional signatures for a member function name.
Unless otherwise specified, it is implementation-defined which functions in the C++ standard library may be recursively reentered.
C++ standard library implementations can share their own internal objects between threads if the objects are not visible to users and are protected against data races.
(since C++11)It is unspecified whether any function signature or class in the C++ standard library is a friend of another class in the C++ standard library.
The names and global function signatures described
are reserved to the implementation.
Any class in the C++ standard library can be derived from a class with a name reserved to the implementation. If a class defined in the C++ standard library is required to be derived from other classes in the C++ standard library, that class can be derived directly from the required base or indirectly through a hierarchy of base classes with names reserved to the implementation.
If a function defined in the C++ standard library is not specified to throw an exception but does not have a non-throwing exception specification, the exception thrown is implementation-defined, but its type should be
or any type derived from
.
The exception specification for a non-virtual function can be strengthened by adding a non-throwing exception specification.
Standard library hardening
An implementation can be a hardened implementation , whether the implementation is hardened is implementation-defined.
Some standard library functions (and function templates) have hardened precondition . When such a function is invoked:
If the implementation is hardened, prior to any other observable side effects of the function,
whose predicates are as described in the hardened precondition are evaluated with a terminating semantic.
If the implementation is not hardened, when a hardened precondition is violated, the behavior is undefined.
Functions with hardened preconditions
- all overloads have hardened preconditions - some overloads have hardened preconditions Category Sequence containers Container views Range utilities Iterator adaptors String (view) classes General utilities Stacktrace Smart pointers Numeric arrays Class
Creation constructor
static helper
Elementaccess operator*
operator->
operator[]
front
back
error
Subviews first
last
subspan
Modifiers operator=
operator+=
operator-=
operator++
pop_front
pop_back
remove_prefix
remove_suffix
Non-member operator==
operator-
iter_move
iter_swap
(since C++26)Notes
macro ValueStdFeature
(C++23)Standard library modules std and std.compatHardened implementation only
(C++26)Hardened
__cpp_lib_hardened_basic_stacktrace
(C++26)Hardened std::basic_stacktrace
__cpp_lib_hardened_basic_string
(C++26)Hardened
__cpp_lib_hardened_basic_string_view
(C++26)Hardened
(C++26)Hardened
__cpp_lib_hardened_common_iterator
(C++26)Hardened
__cpp_lib_hardened_counted_iterator
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
__cpp_lib_hardened_forward_list
(C++26)Hardened
__cpp_lib_hardened_inplace_vector
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
(C++26)Hardened
__cpp_lib_hardened_view_interface
(C++26)Hardened std::ranges::view_interfaceExample
Run this code
importstd;structStr:std::string// OK, std::string cannot be final{~Str();// Guaranteed to be noexcept};intmain(){std::puts("Hello stdlib!");// ::puts("Hello stdlib!"); // Requires std.compat module or stdio.h header// constexpr auto& void_info = std::any().type(); // any::type cannot be constexprstd::stringp,q;q=std::move(p);// OK, p is left in a valid (but unspecified) state// This includes self move assignment q = std::move(q)// return EXIT_SUCCESS; // Macro EXIT_SUCCESS is not provided by either stdlib module}Output:
Hello stdlib! Defect reports
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
DR Applied to Behavior as published Correct behavior
C++98 the language linkages of the names from
the C standard library were unspecified they are
implementation-defined
C++98 the exception specifications of virtual
functions could be strengthened only allowed for
non-virtual functions
C++98 the specification on non-member
functions only considered global functions also considers
non-global functions
C++98 standard library functions might call non-member functions
from other namespaces due to argument-dependent lookup prohibited unless
otherwise specified
C++98
was not a C++ library header it is a C++ library header
C++98 library header dependencies were not specified specified (listed in synopses)
C++98 C++ headers for C library facilities could
only provide definitions in namespace stdallowed to define in global namespace
and then inject into namespace std
C++98 identifiers that are keywords or operators in C++ could
be defined as macros in C++ standard library headers
(only
is required not to define them as macros) all C++ standard
library headers cannot
define them as macros
C++98 C++ headers must include a C++ header
that contains any needed definition C++ headers must provide declarations
and definitions that are directly or
indirectly included in its synopsis
C++11 it was unspecified whether the functions not
required by the standard to be constexpr can
be declared constexpr by the standard library prohibited
C++98 a diagnostic was required if a header
is included at an incorrect position no diagnostic is
required in this case