C++11

C++11 is a version of the ISO/IEC 14882 standard for the C++ programming language. C++11 replaced
the prior version of the C++ standard, called C++03,[1] and was later replaced by C++14. The name
follows the tradition of naming language versions by the publication year of the specification, though it was
formerly named C++0x because it was expected to be published before 2010.[2]

Although one of the design goals was to prefer changes to the libraries over changes to the core
language,[3] C++11 does make several additions to the core language. Areas of the core language that were
significantly improved include multithreading support, generic programming support, uniform initialization,
and performance. Significant changes were also made to the C++ Standard Library, incorporating most of
the C++ Technical Report 1 (TR1) libraries, except the library of mathematical special functions.[4]

C++11 was published as ISO/IEC 14882:2011[5] in September 2011 and is available for a fee. The working
draft most similar to the published C++11 standard is N3337, dated 16 January 2012;[6] it has only editorial
corrections from the C++11 standard.[7]

C++11 is fully supported by Clang 3.3 and later.[8] C++11 is fully supported by GCC 4.8.1 and later.[9]

Design goals
The design committee attempted to stick to a number of goals in designing C++11:

Maintain stability and compatibility with C++98 and possibly with C

Prefer introducing new features via the standard library, rather than extending the core
language
Prefer changes that can evolve programming technique
Improve C++ to facilitate systems and library design, rather than introduce new features
useful only to specific applications
Increase type safety by providing safer alternatives to earlier unsafe techniques
Increase performance and the ability to work directly with hardware
Provide proper solutions for real-world problems
Implement zero-overhead principle (further support needed by some utilities must be used
only if the utility is used)
Make C++ easy to teach and to learn without removing any utility needed by expert
programmers

Attention to beginners is considered important, because most computer programmers will always be such,
and because many beginners never widen their knowledge, limiting themselves to work in aspects of the
language in which they specialize.[1]

Extensions to the C++ core language

One function of the C++ committee is the development of the language core. Areas of the core language
that were significantly improved include multithreading support, generic programming support, uniform
initialization, and performance.

Core language runtime performance enhancements

These language features primarily exist to provide some kind of performance benefit, either of memory or
of computational speed.

Rvalue references and move constructors

In C++03 (and before), temporaries (termed "rvalues", as they often lie on the right side of an assignment)
were intended to never be modifiable — just as in C — and were considered to be indistinguishable from
const T& types; nevertheless, in some cases, temporaries could have been modified, a behavior that was
even considered to be a useful loophole.[10] C++11 adds a new non-const reference type called an rvalue
reference, identified by T&&. This refers to temporaries that are permitted to be modified after they are
initialized, for the purpose of allowing "move semantics".

A chronic performance problem with C++03 is the costly and unneeded deep copies that can happen
implicitly when objects are passed by value. To illustrate the issue, consider that an std::vector<T>
is, internally, a wrapper around a C-style array with a defined size. If an std::vector<T> temporary is
created or returned from a function, it can be stored only by creating a new std::vector<T> and
copying all the rvalue's data into it. Then the temporary and all its memory is destroyed. (For simplicity, this
discussion neglects the return value optimization.)

In C++11, a move constructor of std::vector<T> that takes an rvalue reference to an

std::vector<T> can copy the pointer to the internal C-style array out of the rvalue into the new
std::vector<T>, then set the pointer inside the rvalue to null. Since the temporary will never again be
used, no code will try to access the null pointer, and because the pointer is null, its memory is not deleted
when it goes out of scope. Hence, the operation not only forgoes the expense of a deep copy, but is safe and
invisible.

Rvalue references can provide performance benefits to existing code without needing to make any changes
outside the standard library. The type of the returned value of a function returning an std::vector<T>
temporary does not need to be changed explicitly to std::vector<T> && to invoke the move
constructor, as temporaries are considered rvalues automatically. (However, if std::vector<T> is a
C++03 version without a move constructor, then the copy constructor will be invoked with an const
std::vector<T>&, incurring a significant memory allocation.)

For safety reasons, some restrictions are imposed. A named variable will never be considered to be an
rvalue even if it is declared as such. To get an rvalue, the function template std::move() should be
used. Rvalue references can also be modified only under certain circumstances, being intended to be used
primarily with move constructors.

Due to the nature of the wording of rvalue references, and to some modification to the wording for lvalue
references (regular references), rvalue references allow developers to provide perfect function forwarding.
When combined with variadic templates, this ability allows for function templates that can perfectly forward
arguments to another function that takes those particular arguments. This is most useful for forwarding
constructor parameters, to create factory functions that will automatically call the correct constructor for
those particular arguments. This is seen in the emplace_back (http://en.cppreference.com/w/cpp/container/v
ector/emplace_back) set of the C++ standard library methods.

constexpr – Generalized constant expressions

C++ has always had the concept of constant expressions. These are expressions such as 3+4 that will
always yield the same results, at compile time and at run time. Constant expressions are optimization
opportunities for compilers, and compilers frequently execute them at compile time and hardcode the results
in the program. Also, in several places, the C++ specification requires using constant expressions. Defining
an array requires a constant expression, and enumerator values must be constant expressions.

However, a constant expression has never been allowed to contain a function call or object constructor. So a
piece of code as simple as this is invalid:

int get_five() {return 5;}

int some_value[get_five() + 7]; // Create an array of 12 integers. Ill-formed C++

This was not valid in C++03, because get_five() + 7 is not a constant expression. A C++03
compiler has no way of knowing if get_five() actually is constant at runtime. In theory, this function
could affect a global variable, call other non-runtime constant functions, etc.

C++11 introduced the keyword constexpr, which allows the user to guarantee that a function or object
constructor is a compile-time constant.[11] The above example can be rewritten as follows:

constexpr int get_five() {return 5;}

int some_value[get_five() + 7]; // Create an array of 12 integers. Valid C++11

This allows the compiler to understand, and verify, that get_five() is a compile-time constant.

Using constexpr on a function imposes some limits on what that function can do. First, the function
must have a non-void return type. Second, the function body cannot declare variables or define new types.
Third, the body may contain only declarations, null statements and a single return statement. There must
exist argument values such that, after argument substitution, the expression in the return statement produces
a constant expression.

Before C++11, the values of variables could be used in constant expressions only if the variables are
declared const, have an initializer which is a constant expression, and are of integral or enumeration type.
C++11 removes the restriction that the variables must be of integral or enumeration type if they are defined
with the constexpr keyword:

constexpr double earth_gravitational_acceleration = 9.8;

constexpr double moon_gravitational_acceleration = earth_gravitational_acceleration / 6.0;

Such data variables are implicitly const, and must have an initializer which must be a constant expression.

To construct constant expression data values from user-defined types, constructors can also be declared with
constexpr. A constexpr constructor's function body can contain only declarations and null
statements, and cannot declare variables or define types, as with a constexpr function. There must exist
argument values such that, after argument substitution, it initializes the class's members with constant
expressions. The destructors for such types must be trivial.

The copy constructor for a type with any constexpr constructors should usually also be defined as a
constexpr constructor, to allow objects of the type to be returned by value from a constexpr function.
Any member function of a class, such as copy constructors, operator overloads, etc., can be declared as
constexpr, so long as they meet the requirements for constexpr functions. This allows the compiler to
copy objects at compile time, perform operations on them, etc.

If a constexpr function or constructor is called with arguments which aren't constant expressions, the call
behaves as if the function were not constexpr, and the resulting value is not a constant expression. Likewise,
if the expression in the return statement of a constexpr function does not evaluate to a constant expression
for a given invocation, the result is not a constant expression.

constexpr differs from consteval, introduced in C++20, in that the latter must always produce a
compile time constant, while constexpr does not have this restriction.

Modification to the definition of plain old data

In C++03, a class or struct must follow a number of rules for it to be considered a plain old data (POD)
type. Types that fit this definition produce object layouts that are compatible with C, and they could also be
initialized statically. The C++03 standard has restrictions on what types are compatible with C or can be
statically initialized despite there being no technical reason a compiler couldn't accept the program; if
someone were to create a C++03 POD type and add a non-virtual member function, this type would no
longer be a POD type, could not be statically initialized, and would be incompatible with C despite no
change to the memory layout.

C++11 relaxed several of the POD rules, by dividing the POD concept into two separate concepts: trivial
and standard-layout.

A type that is trivial can be statically initialized. It also means that it is valid to copy data around via
memcpy, rather than having to use a copy constructor. The lifetime of a trivial type begins when its storage
is defined, not when a constructor completes.

A trivial class or struct is defined as one that:

1. Has a trivial default constructor. This may use the default constructor syntax
(SomeConstructor() = default;).
2. Has trivial copy and move constructors, which may use the default syntax.
3. Has trivial copy and move assignment operators, which may use the default syntax.
4. Has a trivial destructor, which must not be virtual.

Constructors are trivial only if there are no virtual member functions of the class and no virtual base classes.
Copy/move operations also require all non-static data members to be trivial.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with
C. A class or struct is standard-layout, by definition, provided:

1. It has no virtual functions

2. It has no virtual base classes
3. All its non-static data members have the same access control (public, private, protected)
 4. All its non-static data members, including any in its base classes, are in the same one class
in the hierarchy
5. The above rules also apply to all the base classes and to all non-static data members in the
class hierarchy
6. It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members
and base classes are PODs.

By separating these concepts, it becomes possible to give up one without losing the other. A class with
complex move and copy constructors may not be trivial, but it could be standard-layout and thus
interoperate with C. Similarly, a class with public and private non-static data members would not be
standard-layout, but it could be trivial and thus memcpy-able.

Core language build-time performance enhancements

Extern template

In C++03, the compiler must instantiate a template whenever a fully specified template is encountered in a
translation unit. If the template is instantiated with the same types in many translation units, this can
dramatically increase compile times. There is no way to prevent this in C++03, so C++11 introduced extern
template declarations, analogous to extern data declarations.

C++03 has this syntax to oblige the compiler to instantiate a template:

template class std::vector<MyClass>;

C++11 now provides this syntax:

extern template class std::vector<MyClass>;

which tells the compiler not to instantiate the template in this translation unit.

Core language usability enhancements

These features exist for the primary purpose of making the language easier to use. These can improve type
safety, minimize code repetition, make erroneous code less likely, etc.

Initializer lists

C++03 inherited the initializer-list feature from C. A struct or array is given a list of arguments in braces, in
the order of the members' definitions in the struct. These initializer-lists are recursive, so an array of structs
or struct containing other structs can use them.

struct Object
{
float first;
int second;
};
 Object scalar = {0.43f, 10}; //One Object, with first=0.43f and second=10
Object anArray[] = {{13.4f, 3}, {43.28f, 29}, {5.934f, 17}}; //An array of three Objects

This is very useful for static lists, or initializing a struct to some value. C++ also provides constructors to
initialize an object, but they are often not as convenient as the initializer list. However, C++03 allows
initializer-lists only on structs and classes that conform to the Plain Old Data (POD) definition; C++11
extends initializer-lists, so they can be used for all classes including standard containers like
std::vector.

C++11 binds the concept to a template, called std::initializer_list. This allows constructors
and other functions to take initializer-lists as parameters. For example:

class SequenceClass
{
public:
SequenceClass(std::initializer_list<int> list);
};

This allows SequenceClass to be constructed from a sequence of integers, such as:

SequenceClass some_var = {1, 4, 5, 6};

This constructor is a special kind of constructor, called an initializer-list-constructor. Classes with such a
constructor are treated specially during uniform initialization (see below)

The template class std::initializer_list<> is a first-class C++11 standard library type. They
can be constructed statically by the C++11 compiler via use of the {} syntax without a type name in
contexts where such braces will deduce to an std::initializer_list, or by explicitly specifying
the type like std::initializer_list<SomeType>{args} (and so on for other varieties of
construction syntax).

The list can be copied once constructed, which is cheap and will act as a copy-by-reference (the class is
typically implemented as a pair of begin/end pointers). An std::initializer_list is constant: its
members cannot be changed once it is created, and nor can the data in those members be changed (which
rules out moving from them, requiring copies into class members, etc.).

Although its construction is specially treated by the compiler, an std::initializer_list is a real

type, and so it can be used in other places besides class constructors. Regular functions can take typed
std::initializer_lists as arguments. For example:

void function_name(std::initializer_list<float> list); // Copying is cheap; see above

function_name({1.0f, -3.45f, -0.4f});

Examples of this in the standard library include the std::min() and std::max() templates taking
std::initializer_lists of numeric type.

Standard containers can also be initialized in these ways:

std::vector<std::string> v = { "xyzzy", "plugh", "abracadabra" };

std::vector<std::string> v({ "xyzzy", "plugh", "abracadabra" });
 std::vector<std::string> v{ "xyzzy", "plugh", "abracadabra" }; // see "Uniform
initialization" below

Uniform initialization

C++03 has a number of problems with initializing types. Several ways to do this exist, and some produce
different results when interchanged. The traditional constructor syntax, for example, can look like a function
declaration, and steps must be taken to ensure that the compiler's most vexing parse rule will not mistake it
for such. Only aggregates and POD types can be initialized with aggregate initializers (using SomeType
var = {/*stuff*/};).

C++11 provides a syntax that allows for fully uniform type initialization that works on any object. It
expands on the initializer list syntax:

struct BasicStruct
{
int x;
double y;
};

struct AltStruct
{
AltStruct(int x, double y)
: x_{x}
, y_{y}
{}

private:
int x_;
double y_;
};

BasicStruct var1{5, 3.2};

AltStruct var2{2, 4.3};

The initialization of var1 behaves exactly as though it were aggregate-initialization. That is, each data
member of an object, in turn, will be copy-initialized with the corresponding value from the initializer-list.
Implicit type conversion will be used where needed. If no conversion exists, or only a narrowing
conversion exists, the program is ill-formed. The initialization of var2 invokes the constructor.

One can also do this:

struct IdString
{
std::string name;
int identifier;
};

IdString get_string()
{
return {"foo", 42}; //Note the lack of explicit type.
}

Uniform initialization does not replace constructor syntax, which is still needed at times. If a class has an
initializer list constructor (TypeName(initializer_list<SomeType>);), then it takes priority
over other forms of construction, provided that the initializer list conforms to the sequence constructor's
type. The C++11 version of std::vector has an initializer list constructor for its template type. Thus
this code:
 std::vector<int> the_vec{4};

will call the initializer list constructor, not the constructor of std::vector that takes a single size
parameter and creates the vector with that size. To access the latter constructor, the user will need to use the
standard constructor syntax directly.

Type inference

In C++03 (and C), to use a variable, its type must be specified explicitly. However, with the advent of
template types and template metaprogramming techniques, the type of something, particularly the well-
defined return value of a function, may not be easily expressed. Thus, storing intermediates in variables is
difficult, possibly needing knowledge of the internals of a given metaprogramming library.

C++11 allows this to be mitigated in two ways. First, the definition of a variable with an explicit
initialization can use the auto keyword.[12][13] This creates a variable of the specific type of the initializer:

auto some_strange_callable_type = std::bind(&some_function, _2, _1, some_object);

auto other_variable = 5;

The type of some_strange_callable_type is simply whatever the particular template function

override of std::bind returns for those particular arguments. This type is easily determined procedurally
by the compiler as part of its semantic analysis duties, but is not easy for the user to determine upon
inspection. The type of other_variable is also well-defined, but it is easier for the user to determine.
It is an int, which is the same type as the integer literal.

This use of the keyword auto in C++ re-purposes the semantics of this keyword, which was originally
used in the typeless predecessor language B in a related role of denoting an untyped automatic variable
definition.

Further, the keyword decltype can be used to determine the type of expression at compile-time. For
example:

int some_int;
decltype(some_int) other_integer_variable = 5;

This is more useful in conjunction with auto, since the type of auto variable is known only to the
compiler. However, decltype can also be very useful for expressions in code that makes heavy use of
operator overloading and specialized types.

auto is also useful for reducing the verbosity of the code. For instance, instead of writing

for (std::vector<int>::const_iterator itr = myvec.cbegin(); itr != myvec.cend(); ++itr)

the programmer can use the shorter

for (auto itr = myvec.cbegin(); itr != myvec.cend(); ++itr)

which can be further compacted since "myvec" implements begin/end iterators:

 for (const auto& x : myvec)

This difference grows as the programmer begins to nest containers, though in such cases typedefs are a
good way to decrease the amount of code.

The type denoted by decltype can be different from the type deduced by auto.

#include <vector>
int main()
{
const std::vector<int> v(1);
auto a = v[0]; // a has type int
decltype(v[0]) b = 1; // b has type const int&, the return type of
// std::vector<int>::operator[](size_type) const
auto c = 0; // c has type int
auto d = c; // d has type int
decltype(c) e; // e has type int, the type of the entity named by c
decltype((c)) f = c; // f has type int&, because (c) is an lvalue
decltype(0) g; // g has type int, because 0 is an rvalue
}

Range-based for loop

C++11 extends the syntax of the for statement to allow for easy iteration over a range of elements:

int my_array[5] = {1, 2, 3, 4, 5};

// double the value of each element in my_array:
for (int& x : my_array)
x *= 2;

// similar but also using type inference for array elements

for (auto& x : my_array)
x *= 2;

This form of for, called the “range-based for”, will iterate over each element in the list. It will work for C-
style arrays, initializer lists, and any type that has begin() and end() functions defined for it that return
iterators. All the standard library containers that have begin/end pairs will work with the range-based for
statement.

Lambda functions and expressions

C++11 provides the ability to create anonymous functions, called lambda functions.[14] These are defined
as follows:

[](int x, int y) -> int { return x + y; }

The return type (-> int in this example) can be omitted as long as all return expressions return the
same type. A lambda can optionally be a closure.

Alternative function syntax

Standard C function declaration syntax was perfectly adequate for the feature set of the C language. As
C++ evolved from C, it kept the basic syntax and extended it where needed. However, as C++ grew more
complex, it exposed several limits, especially regarding template function declarations. For example, in
C++03 this is invalid:

template<class Lhs, class Rhs>

Ret adding_func(const Lhs &lhs, const Rhs &rhs) {return lhs + rhs;} //Ret must be the type
of lhs+rhs

The type Ret is whatever the addition of types Lhs and Rhs will produce. Even with the aforementioned
C++11 functionality of decltype, this is not possible:

template<class Lhs, class Rhs>

decltype(lhs+rhs) adding_func(const Lhs &lhs, const Rhs &rhs) {return lhs + rhs;} //Not
valid C++11

This is not valid C++ because lhs and rhs have not yet been defined; they will not be valid identifiers
until after the parser has parsed the rest of the function prototype.

To work around this, C++11 introduced a new function declaration syntax, with a trailing-return-type:[15]

template<class Lhs, class Rhs>

auto adding_func(const Lhs &lhs, const Rhs &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}

This syntax can be used for more mundane function declarations and definitions:

struct SomeStruct
{
auto func_name(int x, int y) -> int;
};

auto SomeStruct::func_name(int x, int y) -> int

{
return x + y;
}

The use of the “auto” keyword in this case is just part of the syntax and does not perform automatic type
deduction in C++11. However, starting with C++14, the trailing return type can be removed entirely and the
compiler will deduce the return type automatically.[16]

Object construction improvement

In C++03, constructors of a class are not allowed to call other constructors in an initializer list of that class.
Each constructor must construct all of its class members itself or call a common member function, as
follows:

class SomeType
{
public:
SomeType(int new_number)
{
Construct(new_number);
}

SomeType()
 {
Construct(42);
}

private:
void Construct(int new_number)
{
number = new_number;
}

int number;
};

Constructors for base classes cannot be directly exposed to derived classes; each derived class must
implement constructors even if a base class constructor would be appropriate. Non-constant data members
of classes cannot be initialized at the site of the declaration of those members. They can be initialized only
in a constructor.

C++11 provides solutions to all of these problems.

C++11 allows constructors to call other peer constructors (termed delegation). This allows constructors to
utilize another constructor's behavior with a minimum of added code. Delegation has been used in other
languages e.g., Java and Objective-C.

This syntax is as follows:

class SomeType
{
int number;

public:
SomeType(int new_number) : number(new_number) {}
SomeType() : SomeType(42) {}
};

In this case, the same effect could have been achieved by making new_number a default parameter. The
new syntax, however, allows the default value (42) to be expressed in the implementation rather than the
interface — a benefit to maintainers of library code since default values for function parameters are “baked
in” to call sites, whereas constructor delegation allows the value to be changed without recompilation of the
code using the library.

This comes with a caveat: C++03 considers an object to be constructed when its constructor finishes
executing, but C++11 considers an object constructed once any constructor finishes execution. Since
multiple constructors will be allowed to execute, this will mean that each delegating constructor will be
executing on a fully constructed object of its own type. Derived class constructors will execute after all
delegation in their base classes is complete.

For base-class constructors, C++11 allows a class to specify that base class constructors will be inherited.
Thus, the C++11 compiler will generate code to perform the inheritance and the forwarding of the derived
class to the base class. This is an all-or-nothing feature: either all of that base class's constructors are
forwarded or none of them are. Also, an inherited constructor will be shadowed if it matches the signature
of a constructor of the derived class, and restrictions exist for multiple inheritance: class constructors cannot
be inherited from two classes that use constructors with the same signature.

The syntax is as follows:

class BaseClass
{
 public:
BaseClass(int value);
};

class DerivedClass : public BaseClass

{
public:
using BaseClass::BaseClass;
};

For member initialization, C++11 allows this syntax:

class SomeClass
{
public:
SomeClass() {}
explicit SomeClass(int new_value) : value(new_value) {}

private:
int value = 5;
};

Any constructor of the class will initialize value with 5, if the constructor does not override the
initialization with its own. So the above empty constructor will initialize value as the class definition
states, but the constructor that takes an int will initialize it to the given parameter.

It can also use constructor or uniform initialization, instead of the assignment initialization shown above.

Explicit overrides and final

In C++03, it is possible to accidentally create a new virtual function, when one intended to override a base
class function. For example:

struct Base
{
virtual void some_func(float);
};

struct Derived : Base

{
virtual void some_func(int);
};

Suppose the Derived::some_func is intended to replace the base class version. But instead, because
it has a different signature, it creates a second virtual function. This is a common problem, particularly when
a user goes to modify the base class.

C++11 provides syntax to solve this problem.

struct Base
{
virtual void some_func(float);
};

struct Derived : Base

{
virtual void some_func(int) override; // ill-formed - doesn't override a base class
method
};
The override special identifier means that the compiler will check the base class(es) to see if there is a
virtual function with this exact signature. And if there is not, the compiler will indicate an error.

C++11 also adds the ability to prevent inheriting from classes or simply preventing overriding methods in
derived classes. This is done with the special identifier final. For example:

struct Base1 final { };

struct Derived1 : Base1 { }; // ill-formed because the class Base1 has been marked final

struct Base2
{
virtual void f() final;
};

struct Derived2 : Base2

{
void f(); // ill-formed because the virtual function Base2::f has been marked final
};

In this example, the virtual void f() final; statement declares a new virtual function, but it
also prevents derived classes from overriding it. It also has the effect of preventing derived classes from
using that particular function name and parameter combination.

Neither override nor final are language keywords. They are technically identifiers for declarator
attributes:

they gain special meaning as attributes only when used in those specific trailing contexts
(after all type specifiers, access specifiers, member declarations (for struct, class and enum
types) and declarator specifiers, but before initialization or code implementation of each
declarator in a comma-separated list of declarators);
they do not alter the declared type signature and do not declare or override any new
identifier in any scope;
the recognized and accepted declarator attributes may be extended in future versions of C++
(some compiler-specific extensions already recognize added declarator attributes, to provide
code generation options or optimization hints to the compiler, or to generate added data into
the compiled code, intended for debuggers, linkers, and deployment of the compiled code, or
to provide added system-specific security attributes, or to enhance reflection abilities at
runtime, or to provide added binding information for interoperability with other programming
languages and runtime systems; these extensions may take parameters between
parentheses after the declarator attribute identifier; for ANSI conformance, these compiler-
specific extensions should use the double underscore prefix convention).
In any other location, they can be valid identifiers for new declarations (and later use if they
are accessible).

Null pointer constant and type

For the purposes of this section and this section alone, every occurrence of “0” is meant as “a constant
expression which evaluates to 0, which is of type int”. In reality, the constant expression can be of any
integral type.
Since the dawn of C in 1972, the constant 0 has had the double role of constant integer and null pointer
constant. The ambiguity inherent in the double meaning of 0 was dealt with in C by using the preprocessor
macro NULL, which commonly expands to either ((void*)0) or 0. C++ forbids implicit conversion
from void * to other pointer types, thus removing the benefit of casting 0 to void *. As a
consequence, only 0 is allowed as a null pointer constant. This interacts poorly with function overloading:

void foo(char *);

void foo(int);

If NULL is defined as 0 (which is usually the case in C++), the statement foo(NULL); will call
foo(int), which is almost certainly not what the programmer intended, and not what a superficial
reading of the code suggests.

C++11 corrects this by introducing a new keyword to serve as a distinguished null pointer constant:
nullptr. It is of type nullptr_t, which is implicitly convertible and comparable to any pointer type
or pointer-to-member type. It is not implicitly convertible or comparable to integral types, except for bool.
While the original proposal specified that an rvalue of type nullptr_t should not be convertible to
bool, the core language working group decided that such a conversion would be desirable, for
consistency with regular pointer types. The proposed wording changes were unanimously voted into the
Working Paper in June 2008.[2] A similar proposal was also brought to the C standard working group and
was accepted for inclusion in C23.[17]

For backwards compatibility reasons, 0 remains a valid null pointer constant.

char *pc = nullptr; // OK

int *pi = nullptr; // OK
bool b = nullptr; // OK. b is false.
int i = nullptr; // error

foo(nullptr); // calls foo(nullptr_t), not foo(int);

/*
Note that foo(nullptr_t) will actually call foo(char *) in the example above using an
implicit conversion,
only if no other functions are overloading with compatible pointer types in scope.
If multiple overloadings exist, the resolution will fail as it is ambiguous,
unless there is an explicit declaration of foo(nullptr_t).

In standard types headers for C++11, the nullptr_t type should be declared as:
typedef decltype(nullptr) nullptr_t;
but not as:
typedef int nullptr_t; // prior versions of C++ which need NULL to be defined as 0
typedef void *nullptr_t; // ANSI C which defines NULL as ((void*)0)
*/

Strongly typed enumerations

In C++03, enumerations are not type-safe. They are effectively integers, even when the enumeration types
are distinct. This allows the comparison between two enum values of different enumeration types. The only
safety that C++03 provides is that an integer or a value of one enum type does not convert implicitly to
another enum type. Further, the underlying integral type is implementation-defined; code that depends on
the size of the enumeration is thus non-portable. Lastly, enumeration values are scoped to the enclosing
scope. Thus, it is not possible for two separate enumerations in the same scope to have matching member
names.
C++11 allows a special classification of enumeration that has none of these issues. This is expressed using
the enum class (enum struct is also accepted as a synonym) declaration:

enum class Enumeration

{
Val1,
Val2,
Val3 = 100,
Val4 // = 101
};

This enumeration is type-safe. Enum class values are not implicitly converted to integers. Thus, they cannot
be compared to integers either (the expression Enumeration::Val4 == 101 gives a compile error).

The underlying type of enum classes is always known. The default type is int; this can be overridden to a
different integral type as can be seen in this example:

enum class Enum2 : unsigned int {Val1, Val2};

With old-style enumerations the values are placed in the outer scope. With new-style enumerations they are
placed within the scope of the enum class name. So in the above example, Val1 is undefined, but
Enum2::Val1 is defined.

There is also a transitional syntax to allow old-style enumerations to provide explicit scoping, and the
definition of the underlying type:

enum Enum3 : unsigned long {Val1 = 1, Val2};

In this case the enumerator names are defined in the enumeration's scope (Enum3::Val1), but for
backwards compatibility they are also placed in the enclosing scope.

Forward-declaring enums is also possible in C++11. Formerly, enum types could not be forward-declared
because the size of the enumeration depends on the definition of its members. As long as the size of the
enumeration is specified either implicitly or explicitly, it can be forward-declared:

enum Enum1; // Invalid in C++03 and C++11; the underlying type cannot be
determined.
enum Enum2 : unsigned int; // Valid in C++11, the underlying type is specified
explicitly.
enum class Enum3; // Valid in C++11, the underlying type is int.
enum class Enum4 : unsigned int; // Valid in C++11.
enum Enum2 : unsigned short; // Invalid in C++11, because Enum2 was formerly declared
with a different underlying type.

Right angle bracket

C++03's parser defines “>>” as the right shift operator or stream extraction operator in all cases. However,
with nested template declarations, there is a tendency for the programmer to neglect to place a space
between the two right angle brackets, thus causing a compiler syntax error.

C++11 improves the specification of the parser so that multiple right angle brackets will be interpreted as
closing the template argument list where it is reasonable. This can be overridden by using parentheses
around parameter expressions using the “>”, “>=” or “>>” binary operators:
 template<bool Test> class SomeType;
std::vector<SomeType<1>2>> x1; // Interpreted as a std::vector of SomeType<true>,
// followed by "2 >> x1", which is not valid syntax for a declarator. 1 is true.
std::vector<SomeType<(1>2)>> x1; // Interpreted as std::vector of SomeType<false>,
// followed by the declarator "x1", which is valid C++11 syntax. (1>2) is false.

Explicit conversion operators

C++98 added the explicit keyword as a modifier on constructors to prevent single-argument

constructors from being used as implicit type conversion operators. However, this does nothing for actual
conversion operators. For example, a smart pointer class may have an operator bool() to allow it to
act more like a primitive pointer: if it includes this conversion, it can be tested with if
(smart_ptr_variable) (which would be true if the pointer was non-null and false otherwise).
However, this allows other, unintended conversions as well. Because C++ bool is defined as an arithmetic
type, it can be implicitly converted to integral or even floating-point types, which allows for mathematical
operations that are not intended by the user.

In C++11, the explicit keyword can now be applied to conversion operators. As with constructors, it
prevents using those conversion functions in implicit conversions. However, language contexts that
specifically need a boolean value (the conditions of if-statements and loops, and operands to the logical
operators) count as explicit conversions and can thus use a bool conversion operator.

For example, this feature solves cleanly the safe bool issue.

Template aliases

In C++03, it is possible to define a typedef only as a synonym for another type, including a synonym for a
template specialization with all actual template arguments specified. It is not possible to create a typedef
template. For example:

template <typename First, typename Second, int Third>

class SomeType;

template <typename Second>

typedef SomeType<OtherType, Second, 5> TypedefName; // Invalid in C++03

This will not compile.

C++11 adds this ability with this syntax:

template <typename First, typename Second, int Third>

class SomeType;

template <typename Second>

using TypedefName = SomeType<OtherType, Second, 5>;

The using syntax can also be used as type aliasing in C++11:

 typedef void (*FunctionType)(double); // Old style
using FunctionType = void (*)(double); // New introduced syntax

Unrestricted unions

In C++03, there are restrictions on what types of objects can be members of a union. For example, unions
cannot contain any objects that define a non-trivial constructor or destructor. C++11 lifts some of these
restrictions.[3]

If a union member has a non trivial special member function, the compiler will not generate the equivalent
member function for the union and it must be manually defined.

This is a simple example of a union permitted in C++11:

#include <new> // Needed for placement 'new'.

struct Point
{
Point() {}
Point(int x, int y): x_(x), y_(y) {}
int x_, y_;
};

union U
{
int z;
double w;
Point p; // Invalid in C++03; valid in C++11.
U() {} // Due to the Point member, a constructor definition is now needed.
U(const Point& pt) : p(pt) {} // Construct Point object using initializer list.
U& operator=(const Point& pt) { new(&p) Point(pt); return *this; } // Assign Point object
using placement 'new'.
};

The changes will not break any existing code since they only relax current rules.

Core language functionality improvements

These features allow the language to do things that were formerly impossible, exceedingly verbose, or
needed non-portable libraries.

Variadic templates

In C++11, templates can take variable numbers of template parameters. This also allows the definition of
type-safe variadic functions.

New string literals

C++03 offers two kinds of string literals. The first kind, contained within double quotes, produces a null-
terminated array of type const char. The second kind, defined as L"", produces a null-terminated
array of type const wchar_t, where wchar_t is a wide-character of undefined size and semantics.
Neither literal type offers support for string literals with UTF-8, UTF-16, or any other kind of Unicode
encodings.
C++11 supports three Unicode encodings: UTF-8, UTF-16, and UTF-32. The definition of the type char
has been modified to explicitly express that it is at least the size needed to store an eight-bit coding of UTF-
8, and large enough to contain any member of the compiler's basic execution character set. It was formerly
defined as only the latter in the C++ standard itself, then relying on the C standard to guarantee at least 8
bits. Furthermore, C++11 adds two new character types: char16_t and char32_t. These are designed
to store UTF-16 and UTF-32 respectively.

Creating string literals for each of the supported encodings can be done thus:

u8"I'm a UTF-8 string."

u"This is a UTF-16 string."
U"This is a UTF-32 string."

The type of the first string is the usual const char[]. The type of the second string is const
char16_t[] (note lower case 'u' prefix). The type of the third string is const char32_t[] (upper
case 'U' prefix).

When building Unicode string literals, it is often useful to insert Unicode code points directly into the string.
To do this, C++11 allows this syntax:

u8"This is a Unicode Character: \u2018."

u"This is a bigger Unicode Character: \u2018."
U"This is a Unicode Character: \U00002018."

The number after the \u is a hexadecimal number; it does not need the usual 0x prefix. The identifier \u
represents a 16-bit Unicode code point; to enter a 32-bit code point, use \U and a 32-bit hexadecimal
number. Only valid Unicode code points can be entered. For example, code points on the range U+D800–
U+DFFF are forbidden, as they are reserved for surrogate pairs in UTF-16 encodings.

It is also sometimes useful to avoid escaping strings manually, particularly for using literals of XML files,
scripting languages, or regular expressions. C++11 provides a raw string literal:

R"(The String Data \ Stuff " )"

R"delimiter(The String Data \ Stuff " )delimiter"

In the first case, everything between the "( and the )" is part of the string. The " and \ characters do not
need to be escaped. In the second case, the "delimiter( starts the string, and it ends only when
)delimiter" is reached. The string delimiter can be any string up to 16 characters in length,
including the empty string. This string cannot contain spaces, control characters, (, ), or the \ character.
Using this delimiter string, the user can have the sequence )" within raw string literals. For example,
R"delimiter("(a-z)")delimiter" is equivalent to "\"(a-z)\"".

Raw string literals can be combined with the wide literal or any of the Unicode literal prefixes:

u8R"XXX(I'm a "raw UTF-8" string.)XXX"

uR"*(This is a "raw UTF-16" string.)*"
UR"(This is a "raw UTF-32" string.)"

User-defined literals
C++03 provides a number of literals. The characters 12.5 are a literal that is resolved by the compiler as a
type double with the value of 12.5. However, the addition of the suffix f, as in 12.5f, creates a value
of type float that contains the value 12.5. The suffix modifiers for literals are fixed by the C++
specification, and C++03 code cannot create new literal modifiers.

By contrast, C++11 enables the user to define new kinds of literal modifiers that will construct objects based
on the string of characters that the literal modifies.

Transformation of literals is redefined into two distinct phases: raw and cooked. A raw literal is a sequence
of characters of some specific type, while the cooked literal is of a separate type. The C++ literal 1234, as
a raw literal, is this sequence of characters '1', '2', '3', '4'. As a cooked literal, it is the integer 1234.
The C++ literal 0xA in raw form is '0', 'x', 'A', while in cooked form it is the integer 10.

Literals can be extended in both raw and cooked forms, with the exception of string literals, which can be
processed only in cooked form. This exception is due to the fact that strings have prefixes that affect the
specific meaning and type of the characters in question.

All user-defined literals are suffixes; defining prefix literals is not possible. All suffixes starting with any
character except underscore (_) are reserved by the standard. Thus, all user-defined literals must have
suffixes starting with an underscore (_).[18]

User-defined literals processing the raw form of the literal are defined via a literal operator, which is written
as operator "". An example follows:

OutputType operator "" _mysuffix(const char * literal_string)

{
// assumes that OutputType has a constructor that takes a const char *
OutputType ret(literal_string);
return ret;
}

OutputType some_variable = 1234_mysuffix;

// assumes that OutputType has a get_value() method that returns a double
assert(some_variable.get_value() == 1234.0)

The assignment statement OutputType some_variable = 1234_mysuffix; executes the

code defined by the user-defined literal function. This function is passed "1234" as a C-style string, so it
has a null terminator.

An alternative mechanism for processing integer and floating point raw literals is via a variadic template:

template<char...> OutputType operator "" _tuffix();

OutputType some_variable = 1234_tuffix;

OutputType another_variable = 2.17_tuffix;

This instantiates the literal processing function as operator "" _tuffix<'1', '2', '3',
'4'>(). In this form, there is no null character terminating the string. The main purpose for doing this is
to use C++11's constexpr keyword to ensure that the compiler will transform the literal entirely at
compile time, assuming OutputType is a constexpr-constructible and copyable type, and the literal
processing function is a constexpr function.
For numeric literals, the type of the cooked literal is either unsigned long long for integral literals
or long double for floating point literals. (Note: There is no need for signed integral types because a
sign-prefixed literal is parsed as an expression containing the sign as a unary prefix operator and the
unsigned number.) There is no alternative template form:

OutputType operator "" _suffix(unsigned long long);

OutputType operator "" _suffix(long double);

OutputType some_variable = 1234_suffix; // Uses the 'unsigned long long' overload.

OutputType another_variable = 3.1416_suffix; // Uses the 'long double' overload.

In accord with the formerly mentioned new string prefixes, for string literals, these are used:

OutputType operator "" _ssuffix(const char * string_values, size_t num_chars);

OutputType operator "" _ssuffix(const wchar_t * string_values, size_t num_chars);
OutputType operator "" _ssuffix(const char16_t * string_values, size_t num_chars);
OutputType operator "" _ssuffix(const char32_t * string_values, size_t num_chars);

OutputType some_variable = "1234"_ssuffix; // Uses the 'const char *' overload.

OutputType some_variable = u8"1234"_ssuffix; // Uses the 'const char *' overload.
OutputType some_variable = L"1234"_ssuffix; // Uses the 'const wchar_t *' overload.
OutputType some_variable = u"1234"_ssuffix; // Uses the 'const char16_t *' overload.
OutputType some_variable = U"1234"_ssuffix; // Uses the 'const char32_t *' overload.

There is no alternative template form. Character literals are defined similarly.

Multithreading memory model

C++11 standardizes support for multithreaded programming.

There are two parts involved: a memory model which allows multiple threads to co-exist in a program and
library support for interaction between threads. (See this article's section on threading facilities.)

The memory model defines when multiple threads may access the same memory location, and specifies
when updates by one thread become visible to other threads.

Thread-local storage

In a multi-threaded environment, it is common for every thread to have some unique variables. This already
happens for the local variables of a function, but it does not happen for global and static variables.

A new thread-local storage duration (in addition to the existing static, dynamic and automatic) is indicated
by the storage specifier thread_local.

Any object which could have static storage duration (i.e., lifetime spanning the entire execution of the
program) may be given thread-local duration instead. The intent is that like any other static-duration
variable, a thread-local object can be initialized using a constructor and destroyed using a destructor.

Explicitly defaulted special member functions

In C++03, the compiler provides, for classes that do not provide them for themselves, a default constructor,
a copy constructor, a copy assignment operator (operator=), and a destructor. The programmer can
override these defaults by defining custom versions. C++ also defines several global operators (such as
operator new) that work on all classes, which the programmer can override.

However, there is very little control over creating these defaults. Making a class inherently non-copyable,
for example, may be done by declaring a private copy constructor and copy assignment operator and not
defining them. Attempting to use these functions is a violation of the One Definition Rule (ODR). While a
diagnostic message is not required,[19] violations may result in a linker error.

In the case of the default constructor, the compiler will not generate a default constructor if a class is defined
with any constructors. This is useful in many cases, but it is also useful to be able to have both specialized
constructors and the compiler-generated default.

C++11 allows the explicit defaulting and deleting of these special member functions.[20] For example, this
class explicitly declares that a default constructor can be used:

class SomeType
{
SomeType() = default; //The default constructor is explicitly stated.
SomeType(OtherType value);
};

Explicitly deleted functions

A function can be explicitly disabled. This is useful for preventing implicit type conversions. The =
delete specifier can be used to prohibit calling a function with particular parameter types.[20] For
example:

void noInt(double i);

void noInt(int) = delete;

An attempt to call noInt() with an int parameter will be rejected by the compiler, instead of
performing a silent conversion to double. Calling noInt() with a float still works.

It is possible to prohibit calling the function with any type other than double by using a template:

double onlyDouble(double d) {return d;}

template<typename T> double onlyDouble(T) = delete;

calling onlyDouble(1.0) will work, while onlyDouble(1.0f) will generate a compiler error.

Class member functions and constructors can also be deleted. For example, it is possible to prevent copying
class objects by deleting the copy constructor and operator =:

class NonCopyable
{
NonCopyable();
NonCopyable(const NonCopyable&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
};

Type long long int

In C++03, the largest integer type is long int. It is guaranteed to have at least as many usable bits as
int. This resulted in long int having size of 64 bits on some popular implementations and 32 bits on
others. C++11 adds a new integer type long long int to address this issue. It is guaranteed to be at
least as large as a long int, and have no fewer than 64 bits. The type was originally introduced by C99
to the standard C, and most C++ compilers supported it as an extension already.[21][22]

Static assertions

C++03 provides two methods to test assertions: the macro assert and the preprocessor directive
#error. However, neither is appropriate for use in templates: the macro tests the assertion at execution-
time, while the preprocessor directive tests the assertion during preprocessing, which happens before
instantiation of templates. Neither is appropriate for testing properties that are dependent on template
parameters.

The new utility introduces a new way to test assertions at compile-time, using the new keyword
static_assert. The declaration assumes this form:

static_assert (constant-expression, error-message);

Here are some examples of how static_assert can be used:

static_assert((GREEKPI > 3.14) && (GREEKPI < 3.15), "GREEKPI is inaccurate!");

template<class T>
struct Check
{
static_assert(sizeof(int) <= sizeof(T), "T is not big enough!");
};

template<class Integral>
Integral foo(Integral x, Integral y)
{
static_assert(std::is_integral<Integral>::value, "foo() parameter must be an integral
type.");
}

When the constant expression is false the compiler produces an error message. The first example is
similar to the preprocessor directive #error, although the preprocessor does only support integral
types.[23] In contrast, in the second example the assertion is checked at every instantiation of the template
class Check.

Static assertions are useful outside of templates also. For instance, a given implementation of an algorithm
might depend on the size of a long long being larger than an int, something the standard does not
guarantee. Such an assumption is valid on most systems and compilers, but not all.

Allow sizeof to work on members of classes without an explicit object

In C++03, the sizeof operator can be used on types and objects. But it cannot be used to do this:
 struct SomeType { OtherType member; };

sizeof(SomeType::member); // Does not work with C++03. Okay with C++11

This should return the size of OtherType. C++03 disallows this, so it is a compile error. C++11 allows it.
It is also allowed for the alignof operator introduced in C++11.

Control and query object alignment

C++11 allows variable alignment to be queried and controlled with alignof and alignas.

The alignof operator takes the type and returns the power of 2 byte boundary on which the type
instances must be allocated (as a std::size_t). When given a reference type alignof returns the
referenced type's alignment; for arrays it returns the element type's alignment.

The alignas specifier controls the memory alignment for a variable. The specifier takes a constant or a
type; when supplied a type alignas(T) is shorthand for alignas(alignof(T)). For example, to
specify that a char array should be properly aligned to hold a float:

alignas(float) unsigned char c[sizeof(float)]

Allow garbage collected implementations

Prior C++ standards provided for programmer-driven garbage collection via set_new_handler, but
gave no definition of object reachability for the purpose of automatic garbage collection. C++11 defines
conditions under which pointer values are "safely derived" from other values. An implementation may
specify that it operates under strict pointer safety, in which case pointers that are not derived according to
these rules can become invalid.

Attributes

C++11 provides a standardized syntax for compiler/tool extensions to the language. Such extensions were
traditionally specified using #pragma directive or vendor-specific keywords (like __attribute__ for
GNU and __declspec for Microsoft). With the new syntax, added information can be specified in a
form of an attribute enclosed in double square brackets. An attribute can be applied to various elements of
source code:

int [[attr1]] i [[attr2, attr3]];

[[attr4(arg1, arg2)]] if (cond)

{
[[vendor::attr5]] return i;
}

In the example above, attribute attr1 applies to the type of variable i, attr2 and attr3 apply to the
variable itself, attr4 applies to the if statement and vendor::attr5 applies to the return statement.
In general (but with some exceptions), an attribute specified for a named entity is placed after the name, and
before the entity otherwise, as shown above, several attributes may be listed inside one pair of double
square brackets, added arguments may be provided for an attribute, and attributes may be scoped by
vendor-specific attribute namespaces.

It is recommended that attributes have no language semantic meaning and do not change the sense of a
program when ignored. Attributes can be useful for providing information that, for example, helps the
compiler to issue better diagnostics or optimize the generated code.

C++11 provides two standard attributes itself: noreturn to specify that a function does not return, and
carries_dependency to help optimizing multi-threaded code by indicating that function arguments
or return value carry a dependency.

C++ standard library changes

A number of new features were introduced in the C++11 standard library. Many of these could have been
implemented under the old standard, but some rely (to a greater or lesser extent) on new C++11 core
features.

A large part of the new libraries was defined in the document C++ Standards Committee's Library
Technical Report (called TR1), which was published in 2005. Various full and partial implementations of
TR1 are currently available using the namespace std::tr1. For C++11 they were moved to namespace
std. However, as TR1 features were brought into the C++11 standard library, they were upgraded where
appropriate with C++11 language features that were not available in the initial TR1 version. Also, they may
have been enhanced with features that were possible under C++03, but were not part of the original TR1
specification.

Upgrades to standard library components

C++11 offers a number of new language features that the currently existing standard library components
can benefit from. For example, most standard library containers can benefit from Rvalue reference based
move constructor support, both for quickly moving heavy containers around and for moving the contents of
those containers to new memory locations. The standard library components were upgraded with new
C++11 language features where appropriate. These include, but are not necessarily limited to:

Rvalue references and the associated move support

Support for the UTF-16 encoding unit, and UTF-32 encoding unit Unicode character types
Variadic templates (coupled with Rvalue references to allow for perfect forwarding)
Compile-time constant expressions
decltype
explicit conversion operators
Functions declared defaulted or deleted

Further, much time has passed since the prior C++ standard. Much code using the standard library has been
written. This has revealed parts of the standard libraries that could use some improving. Among the many
areas of improvement considered were standard library allocators. A new scope-based model of allocators
was included in C++11 to supplement the prior model.

Threading facilities
While the C++03 language provides a memory model that supports threading, the primary support for
actually using threading comes with the C++11 standard library.

A thread class (std::thread) is provided, which takes a function object (and an optional series of
arguments to pass to it) to run in the new thread. It is possible to cause a thread to halt until another
executing thread completes, providing thread joining support via the std::thread::join() member
function. Access is provided, where feasible, to the underlying native thread object(s) for platform-specific
operations by the std::thread::native_handle() member function.

For synchronization between threads, appropriate mutexes (std::mutex,

std::recursive_mutex, etc.) and condition variables (std::condition_variable and
std::condition_variable_any) are added to the library. These are accessible via Resource
Acquisition Is Initialization (RAII) locks (std::lock_guard and std::unique_lock) and
locking algorithms for easy use.

For high-performance, low-level work, communicating between threads is sometimes needed without the
overhead of mutexes. This is done using atomic operations on memory locations. These can optionally
specify the minimum memory visibility constraints needed for an operation. Explicit memory barriers may
also be used for this purpose.

The C++11 thread library also includes futures and promises for passing asynchronous results between
threads, and std::packaged_task for wrapping up a function call that can generate such an
asynchronous result. The futures proposal was criticized because it lacks a way to combine futures and
check for the completion of one promise inside a set of promises.[24]

Further high-level threading facilities such as thread pools have been remanded to a future C++ technical
report. They are not part of C++11, but their eventual implementation is expected to be built entirely on top
of the thread library features.

The new std::async facility provides a convenient method of running tasks and tying them to a
std::future. The user can choose whether the task is to be run asynchronously on a separate thread or
synchronously on a thread that waits for the value. By default, the implementation can choose, which
provides an easy way to take advantage of hardware concurrency without oversubscription, and provides
some of the advantages of a thread pool for simple usages.

Tuple types

Tuples are collections composed of heterogeneous objects of pre-arranged dimensions. A tuple can be
considered a generalization of a struct's member variables.

The C++11 version of the TR1 tuple type benefited from C++11 features like variadic templates. To
implement reasonably, the TR1 version required an implementation-defined maximum number of contained
types, and substantial macro trickery. By contrast, the implementation of the C++11 version requires no
explicit implementation-defined maximum number of types. Though compilers will have an internal
maximum recursion depth for template instantiation (which is normal), the C++11 version of tuples will not
expose this value to the user.

Using variadic templates, the declaration of the tuple class looks as follows:

template <class ...Types> class tuple;

An example of definition and use of the tuple type:

typedef std::tuple <int, double, long &, const char *> test_tuple;
long lengthy = 12;
test_tuple proof (18, 6.5, lengthy, "Ciao!");

lengthy = std::get<0>(proof); // Assign to 'lengthy' the value 18.

std::get<3>(proof) = " Beautiful!"; // Modify the tuple’s fourth element.

It's possible to create the tuple proof without defining its contents, but only if the tuple elements' types
possess default constructors. Moreover, it's possible to assign a tuple to another tuple: if the two tuples’
types are the same, each element type must possess a copy constructor; otherwise, each element type of the
right-side tuple must be convertible to that of the corresponding element type of the left-side tuple or that the
corresponding element type of the left-side tuple has a suitable constructor.

typedef std::tuple <int , double, string > tuple_1 t1;

typedef std::tuple <char, short , const char * > tuple_2 t2 ('X', 2, "Hola!");
t1 = t2; // Ok, first two elements can be converted,
// the third one can be constructed from a 'const char *'.

Just like std::make_pair for std::pair, there exists std::make_tuple to automatically

create std::tuples using type deduction and auto helps to declare such a tuple. std::tie creates
tuples of lvalue references to help unpack tuples. std::ignore also helps here. See the example:

auto record = std::make_tuple("Hari Ram", "New Delhi", 3.5, 'A');

std::string name ; float gpa ; char grade ;
std::tie(name, std::ignore, gpa, grade) = record ; // std::ignore helps drop the place name
std::cout << name << ' ' << gpa << ' ' << grade << std::endl ;

Relational operators are available (among tuples with the same number of elements), and two expressions
are available to check a tuple's characteristics (only during compilation):

std::tuple_size<T>::value returns the number of elements in the tuple T,

std::tuple_element<I, T>::type returns the type of the object number I of the
tuple T.

Hash tables

Including hash tables (unordered associative containers) in the C++ standard library is one of the most
recurring requests. It was not adopted in C++03 due to time constraints only. Although hash tables are less
efficient than a balanced tree in the worst case (in the presence of many collisions), they perform better in
many real applications.

Collisions are managed only via linear chaining because the committee didn't consider it to be opportune to
standardize solutions of open addressing that introduce quite a lot of intrinsic problems (above all when
erasure of elements is admitted). To avoid name clashes with non-standard libraries that developed their
own hash table implementations, the prefix “unordered” was used instead of “hash”.

The new library has four types of hash tables, differentiated by whether or not they accept elements with the
same key (unique keys or equivalent keys), and whether they map each key to an associated value. They
correspond to the four existing binary search tree based associative containers, with an unordered_
prefix.
 Type of hash table Associated values Equivalent keys

std::unordered_set No No

std::unordered_multiset No Yes

std::unordered_map Yes No

std::unordered_multimap Yes Yes

The new classes fulfill all the requirements of a container class, and have all the methods needed to access
elements: insert, erase, begin, end.

This new feature didn't need any C++ language core extensions (though implementations will take
advantage of various C++11 language features), only a small extension of the header <functional>
and the introduction of headers <unordered_set> and <unordered_map>. No other changes to
any existing standard classes were needed, and it doesn't depend on any other extensions of the standard
library.

Regular expressions

The new library, defined in the new header <regex>, is made of a couple of new classes:

regular expressions are represented by instance of the template class std::regex;

occurrences are represented by instance of the template class std::match_results,
std::regex_iterator is used to iterate over all matches of a regex

The function std::regex_search is used for searching, while for ‘search and replace’ the function
std::regex_replace is used which returns a new string.[25]

Here is an example of the use of std::regex_iterator:

#include <regex>
const char *pattern = R"([^ ,.\t\n]+)"; // find words separated by space, comma, period tab
newline

std::regex rgx(pattern); // throws exception on invalid pattern

const char *target = "Unseen University - Ankh-Morpork";

// Use a regex_iterator to identify all words of 'target' separated by characters of

'pattern'.
auto iter =
std::cregex_iterator(target, target + strlen(target), rgx);

// make an end of sequence iterator

auto end =
std::cregex_iterator();

for (; iter != end; ++iter)

{
std::string match_str = iter->str();
std::cout << match_str << '\n';
}
The library <regex> requires neither alteration of any existing header (though it will use them where
appropriate) nor an extension of the core language. In POSIX C, regular expressions are also available via
the C POSIX library#regex.h.

General-purpose smart pointers

C++11 provides std::unique_ptr, and improvements to std::shared_ptr and

std::weak_ptr from TR1. std::auto_ptr is deprecated.

Extensible random number facility

The C standard library provides the ability to generate pseudorandom numbers via the function rand.
However, the algorithm is delegated entirely to the library vendor. C++ inherited this functionality with no
changes, but C++11 provides a new method for generating pseudorandom numbers.

C++11's random number functionality is split into two parts: a generator engine that contains the random
number generator's state and produces the pseudorandom numbers; and a distribution, which determines the
range and mathematical distribution of the outcome. These two are combined to form a random number
generator object.

Unlike the C standard rand, the C++11 mechanism will come with three base generator engine
algorithms:

linear_congruential_engine,
subtract_with_carry_engine, and
mersenne_twister_engine.

C++11 also provides a number of standard distributions:

uniform_int_distribution,
uniform_real_distribution,
bernoulli_distribution,
binomial_distribution,
geometric_distribution,
negative_binomial_distribution,
poisson_distribution,
exponential_distribution,
gamma_distribution,
weibull_distribution,
extreme_value_distribution,
normal_distribution,
lognormal_distribution,
chi_squared_distribution,
cauchy_distribution,
fisher_f_distribution,
student_t_distribution,
 discrete_distribution,
piecewise_constant_distribution and
piecewise_linear_distribution.

The generator and distributions are combined as in this example:

#include <random>
#include <functional>

std::uniform_int_distribution<int> distribution(0, 99);

std::mt19937 engine; // Mersenne twister MT19937
auto generator = std::bind(distribution, engine);
int random = generator(); // Generate a uniform integral variate between 0 and 99.
int random2 = distribution(engine); // Generate another sample directly using the
distribution and the engine objects.

Wrapper reference

A wrapper reference is obtained from an instance of the class template reference_wrapper. Wrapper
references are similar to normal references (‘&’) of the C++ language. To obtain a wrapper reference from
any object the function template ref is used (for a constant reference cref is used).

Wrapper references are useful above all for function templates, where references to parameters rather than
copies are needed:

// This function will take a reference to the parameter 'r' and increment it.
void func (int &r) { r++; }

// Template function.
template<class F, class P> void g (F f, P t) { f(t); }

int main()
{
int i = 0;
g (func, i); // 'g<void (int &r), int>' is instantiated
// then 'i' will not be modified.
std::cout << i << std::endl; // Output -> 0

g (func, std::ref(i)); // 'g<void(int &r),reference_wrapper<int>>' is instantiated

// then 'i' will be modified.
std::cout << i << std::endl; // Output -> 1
}

This new utility was added to the existing <functional> header and didn't need further extensions of
the C++ language.

Polymorphic wrappers for function objects

Polymorphic wrappers for function objects are similar to function pointers in semantics and syntax, but are
less tightly bound and can indiscriminately refer to anything which can be called (function pointers, member
function pointers, or functors) whose arguments are compatible with those of the wrapper.

An example can clarify its characteristics:

std::function<int (int, int)> func; // Wrapper creation using

// template class 'function'.
 std::plus<int> add; // 'plus' is declared as 'template<class T> T plus( T, T ) ;'
// then 'add' is type 'int add( int x, int y )'.
func = add; // OK - Parameters and return types are the same.

int a = func (1, 2); // NOTE: if the wrapper 'func' does not refer to any function,
// the exception 'std::bad_function_call' is thrown.

std::function<bool (short, short)> func2 ;

if (!func2)
{
// True because 'func2' has not yet been assigned a function.

bool adjacent(long x, long y);

func2 = &adjacent; // OK - Parameters and return types are convertible.

struct Test
{
bool operator()(short x, short y);
};
Test car;
func = std::ref(car); // 'std::ref' is a template function that returns the wrapper
// of member function 'operator()' of struct 'car'.
}
func = func2; // OK - Parameters and return types are convertible.

The template class function was defined inside the header <functional>, without needing any
change to the C++ language.

Type traits for metaprogramming

Metaprogramming consists of creating a program that creates or modifies another program (or itself). This
can happen during compilation or during execution. The C++ Standards Committee has decided to
introduce a library for metaprogramming during compiling via templates.

Here is an example of a meta-program using the C++03 standard: a recursion of template instances for
calculating integer exponents:

template<int B, int N>

struct Pow
{
// recursive call and recombination.
enum{ value = B*Pow<B, N-1>::value };
};

template< int B >

struct Pow<B, 0>
{
// ''N == 0'' condition of termination.
enum{ value = 1 };
};
int quartic_of_three = Pow<3, 4>::value;

Many algorithms can operate on different types of data; C++'s templates support generic programming and
make code more compact and useful. Nevertheless, it is common for algorithms to need information on the
data types being used. This information can be extracted during instantiation of a template class using type
traits.

Type traits can identify the category of an object and all the characteristics of a class (or of a struct). They
are defined in the new header <type_traits>.

In the next example there is the template function ‘elaborate’ which, depending on the given data types, will
instantiate one of the two proposed algorithms (Algorithm::do_it).
 // First way of operating.
template< bool B > struct Algorithm
{
template<class T1, class T2> static int do_it (T1 &, T2 &) { /*...*/ }
};

// Second way of operating.

template<> struct Algorithm<true>
{
template<class T1, class T2> static int do_it (T1, T2) { /*...*/ }
};

// Instantiating 'elaborate' will automatically instantiate the correct way to operate.

template<class T1, class T2>
int elaborate (T1 A, T2 B)
{
// Use the second way only if 'T1' is an integer and if 'T2' is
// in floating point, otherwise use the first way.
return Algorithm<std::is_integral<T1>::value &&
std::is_floating_point<T2>::value>::do_it( A, B ) ;
}

Via type traits, defined in header <type_traits>, it's also possible to create type transformation
operations (static_cast and const_cast are insufficient inside a template).

This type of programming produces elegant and concise code; however, the weak point of these techniques
is the debugging: it's uncomfortable during compilation and very difficult during program execution.

Uniform method for computing the return type of function objects

Determining the return type of a template function object at compile-time is not intuitive, particularly if the
return value depends on the parameters of the function. As an example:

struct Clear
{
int operator()(int) const; // The parameter type is
double operator()(double) const; // equal to the return type.
};

template <class Obj>

class Calculus
{
public:
template<class Arg> Arg operator()(Arg& a) const
{
return member(a);
}
private:
Obj member;
};

Instantiating the class template Calculus<Clear>, the function object of calculus will have
always the same return type as the function object of Clear. However, given class Confused below:

struct Confused
{
double operator()(int) const; // The parameter type is not
int operator()(double) const; // equal to the return type.
};
Attempting to instantiate Calculus<Confused> will cause the return type of Calculus to not be
the same as that of class Confused. The compiler may generate warnings about the conversion from int
to double and vice versa.

TR1 introduces, and C++11 adopts, the template class std::result_of that allows one to determine
and use the return type of a function object for every declaration. The object CalculusVer2 uses the
std::result_of object to derive the return type of the function object:

template< class Obj >

class CalculusVer2
{
public:
template<class Arg>
typename std::result_of<Obj(Arg)>::type operator()(Arg& a) const
{
return member(a);
}
private:
Obj member;
};

In this way in instances of function object of CalculusVer2<Confused> there are no conversions,

warnings, or errors.

The only change from the TR1 version of std::result_of is that the TR1 version allowed an
implementation to fail to be able to determine the result type of a function call. Due to changes to C++ for
supporting decltype, the C++11 version of std::result_of no longer needs these special cases;
implementations are required to compute a type in all cases.

Improved C compatibility
For compatibility with C, from C99, these were added:[26]

Preprocessor:[27]
variadic macros,
concatenation of adjacent narrow/wide string literals,
_Pragma() – equivalent of #pragma.
long long – integer type that is at least 64 bits long.
__func__ – macro evaluating to the name of the function it is in.
Headers:
cstdbool (stdbool.h),
cstdint (stdint.h),
cinttypes (inttypes.h).

Features originally planned but removed or not included

Heading for a separate TR:

Modules (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)
Decimal types
 Math special functions

Postponed:

Concepts
More complete or required garbage collection support
Reflection
Macro scopes

Features removed or deprecated

The term sequence point was removed, being replaced by specifying that either one operation is sequenced
before another, or that two operations are unsequenced.[28]

The former use of the keyword export was removed.[29] The keyword itself remains, being reserved for
potential future use.

Dynamic exception specifications are deprecated.[29] Compile-time specification of non-exception-throwing

functions is available with the noexcept keyword, which is useful for optimization.

std::auto_ptr is deprecated, having been superseded by std::unique_ptr.

Function object base classes (std::unary_function, std::binary_function), adapters to

pointers to functions and adapters to pointers to members, and binder classes are all deprecated.

See also
C11

References
1. "We have an international standard: C++0x is unanimously approved" (http://herbsutter.com/
2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/). 12 August
2011. Archived (https://web.archive.org/web/20181211080242/http://herbsutter.com/2011/08/
12/we-have-an-international-standard-c0x-is-unanimously-approved/) from the original on 11
December 2018. Retrieved 12 August 2011.
2. Stroustrup, Bjarne. "C++11 FAQ" (http://www.stroustrup.com/C++11FAQ.html).
stroustrup.com. Archived (https://web.archive.org/web/20181006014513/http://www.stroustru
p.com/C++11FAQ.html) from the original on 2018-10-06. Retrieved 2014-10-15.
3. "C++11 Overview: What specific design goals guided the committee?" (https://isocpp.org/wik
i/faq/cpp11#cpp11-specific-goals). Standard C++. Archived (https://web.archive.org/web/201
90131050050/https://isocpp.org/wiki/faq/cpp11#cpp11-specific-goals) from the original on
2019-01-31. Retrieved 2015-09-04.
4. "Bjarne Stroustrup: A C++0x overview" (https://www.research.ibm.com/arl/seminar/media/stro
ustrup.pdf) (PDF). Archived (https://web.archive.org/web/20160617024131/https://www.resea
rch.ibm.com/arl/seminar/media/stroustrup.pdf) (PDF) from the original on 17 June 2016.
Retrieved 30 June 2011.
 5. "ISO/IEC 14882:2011" (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.h
tm?csnumber=50372). ISO. 2 September 2011. Archived (https://web.archive.org/web/20130
129110331/http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb
er=50372) from the original on 29 January 2013. Retrieved 3 September 2011.
6. "Working Draft, Standard for Programming Language C++" (http://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2012/n3337.pdf) (PDF). Archived (https://web.archive.org/web/2019012
1141340/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf) (PDF) from
the original on 2019-01-21. Retrieved 2012-04-26.
7. "The Standard" (http://isocpp.org/std/the-standard). Archived (https://web.archive.org/web/20
190513104847/https://isocpp.org/std/the-standard) from the original on 2019-05-13.
Retrieved 2012-11-02.
8. "Clang - C++ Programming Language Status" (https://web.archive.org/web/2023112922101
3/https://clang.llvm.org/cxx_status.html). web.archive.org. 2023-11-29. Retrieved
2023-12-01.
9. "GCC 4.8.1 released, C++11 feature complete : Standard C++" (https://isocpp.org/blog/2013/
05/gcc-4.8.1-released-c11-feature-complete). isocpp.org. Retrieved 2023-12-01.
10. Sutter, Alexandrescu "C++ coding standards" #15
11. Gabriel Dos Reis; Bjarne Stroustrup (22 March 2010). "General Constant Expressions for
System Programming Languages, Proceedings SAC '10" (http://www.stroustrup.com/sac10-
constexpr.pdf) (PDF). Archived (https://web.archive.org/web/20180613125602/http://www.str
oustrup.com/sac10-constexpr.pdf) (PDF) from the original on 13 June 2018. Retrieved
18 August 2012.
12. Jaakko Järvi; Bjarne Stroustrup; Douglas Gregor; Jeremy Siek (April 28, 2003). "Decltype
and auto, Programming Language C++, Document no: N1478=03-0061" (http://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2003/n1478.pdf) (PDF). Archived (https://web.archive.org/
web/20150528112722/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1478.pdf)
(PDF) from the original on May 28, 2015. Retrieved June 6, 2015.
13. Roger Orr (June 2013). " "Auto – A Necessary Evil?" Overload Journal #115" (http://accu.org/
index.php/journals/1859). Archived (https://web.archive.org/web/20150606155637/http://acc
u.org/index.php/journals/1859) from the original on 2015-06-06. Retrieved 2015-06-06.
14. "Document no: N1968=06-0038- Lambda expressions and closures for C++" (http://www.ope
n-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf) (PDF). Open Standards. Archived (htt
ps://web.archive.org/web/20110728051114/http://www.open-std.org/jtc1/sc22/wg21/docs/pa
pers/2006/n1968.pdf) (PDF) from the original on 2011-07-28. Retrieved 2009-04-20.
15. "Decltype (revision 5)" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pd
f) (PDF). Archived (https://web.archive.org/web/20220214133743/http://www.open-std.org/JT
C1/SC22/WG21/docs/papers/2006/n1978.pdf) (PDF) from the original on 2022-02-14.
Retrieved 2022-02-16.
16. "auto specifier (since C++11) - cppreference.com" (http://en.cppreference.com/w/cpp/langua
ge/auto). en.cppreference.com. Archived (https://web.archive.org/web/20161020050910/htt
p://en.cppreference.com/w/cpp/language/auto) from the original on 2016-10-20. Retrieved
2016-10-18.
17. Gustedt, Jens (2019-07-09). "Introduce the nullptr constant - v1" (http://www.open-std.org/jtc
1/sc22/wg14/www/docs/n2394.pdf) (PDF). ISO JTC1/SC22/WG14 Document Register.
International Organization for Standardization. Archived (https://web.archive.org/web/202007
27055706/http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2394.pdf) (PDF) from the
original on 2020-07-27. Retrieved 2020-04-19 – via open-std.org.
18. This caused a conflict with the proposed use (common in other languages) of the underscore
for digit grouping in numeric literals such as integer literals, so C++14 instead uses the
apostrophe (as an upper comma) for grouping.Daveed Vandevoorde (2012-09-21). "N3448:
Painless Digit Separation" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344
8.pdf) (PDF). Archived (https://web.archive.org/web/20150811140211/http://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2012/n3448.pdf) (PDF) from the original on 2015-08-11.
Retrieved 2015-08-13., Lawrence Crowl (2012-12-19). "N3499: Digit Separators" (http://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html). Archived (https://web.archive.
org/web/20150811114700/http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3499.ht
ml) from the original on 2015-08-11. Retrieved 2015-08-13.
19. ISO/IEC (2003). ISO/IEC 14882:2003(E): Programming Languages – C++ §3.2 One
definition rule [basic.def.odr] para. 3
20. "Defaulted and Deleted Functions – ISO/IEC JTC1 SC22 WG21 N2210 = 07-0070 – 2007-
03-11" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2210.html#%22default%
22). Archived (https://web.archive.org/web/20120819182910/http://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2007/n2210.html#%22default%22) from the original on 2012-08-19.
Retrieved 2012-12-20.
21. "Using the GNU Compiler Collection (GCC): Long Long" (https://gcc.gnu.org/onlinedocs/gcc/
Long-Long.html). gcc.gnu.org. Archived (https://web.archive.org/web/20160821113233/http://
gcc.gnu.org/onlinedocs/gcc/Long-Long.html) from the original on 2016-08-21. Retrieved
2016-07-25.
22. "Data Type Ranges (C++)" (http://msdn.microsoft.com/en-us/library/s3f49ktz(VS.80).aspx).
Archived (https://web.archive.org/web/20090221114127/http://msdn.microsoft.com/en-us/libr
ary/s3f49ktz(VS.80).aspx) from the original on 2009-02-21. Retrieved 2009-04-23.
23. Samuel P. Harbison III, Guy L. Steele Jr.: "C – A Reference Manual", 5th edition, p.251
24. Milewski, Bartosz (3 March 2009). "Broken promises–C++0x futures" (http://bartoszmilewski.
wordpress.com/2009/03/03/broken-promises-c0x-futures/). Archived (https://web.archive.org/
web/20110916155404/http://bartoszmilewski.wordpress.com/2009/03/03/broken-promises-c
0x-futures/) from the original on 16 September 2011. Retrieved 24 January 2010.
25. "C++ Regular expressions library" (https://en.cppreference.com/w/cpp/regex).
cppreference.com. Retrieved 10 December 2022.
26. "Clang - C++98, C++11, and C++14 Status" (http://clang.llvm.org/cxx_status.html).
Clang.llvm.org. 2013-05-12. Archived (https://web.archive.org/web/20190528214038/http://cl
ang.llvm.org/cxx_status.html) from the original on 2019-05-28. Retrieved 2013-06-10.
27. "Working draft changes for C99 preprocessor synchronization" (http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2004/n1653.htm). www.open-std.org. Archived (https://web.archive.o
rg/web/20200731222757/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.h
tm) from the original on 2020-07-31. Retrieved 2014-05-26.
28. Caves, Jonathan (4 June 2007). "Update on the C++-0x Language Standard" (http://blogs.m
sdn.com/b/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx).
Archived (https://web.archive.org/web/20110909141628/http://blogs.msdn.com/b/vcblog/arch
ive/2007/06/04/update-on-the-c-0x-language-standard.aspx) from the original on 9
September 2011. Retrieved 25 May 2010.
29. Sutter, Herb (3 March 2010). "Trip Report: March 2010 ISO C++ Standards Meeting" (http://h
erbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/). Archived (https://
web.archive.org/web/20180711064254/https://herbsutter.com/2010/03/13/trip-report-march-2
010-iso-c-standards-meeting/) from the original on 11 July 2018. Retrieved 24 March 2010.

External links
 The C++ Standards Committee (http://www.open-std.org/jtc1/sc22/wg21/)
C++0X: The New Face of Standard C++ (https://web.archive.org/web/20080221185141/htt
p://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=216)
Herb Sutter's blog coverage of C++11 (http://herbsutter.wordpress.com/)
Anthony Williams' blog coverage of C++11 (http://www.justsoftwaresolutions.co.uk/cplusplu
s/)
A talk on C++0x given by Bjarne Stroustrup at the University of Waterloo (http://www.csclub.u
waterloo.ca/media/C++0x%20-%20An%20Overview.html) Archived (https://web.archive.org/
web/20090123171916/http://www.csclub.uwaterloo.ca/media/C++0x%20-%20An%20Overvi
ew.html) 2009-01-23 at the Wayback Machine
The State of the Language: An Interview with Bjarne Stroustrup (15 August 2008) (http://ww
w.devx.com/SpecialReports/Article/38813/0/page/1) Archived (https://web.archive.org/web/2
0090131065906/http://www.devx.com/SpecialReports/Article/38813/0/page/1) 31 January
2009 at the Wayback Machine
Wiki page to help keep track of C++ 0x core language features and their availability in
compilers (https://web.archive.org/web/20120520004525/http://wiki.apache.org/stdcxx/C++0
xCompilerSupport)
Online C++11 standard library reference (http://en.cppreference.com)
Online C++11 compiler (http://stacked-crooked.com/)
Bjarne Stroustrup's C++11 FAQ (http://www.stroustrup.com/C++11FAQ.html)
More information on C++11 features:range-based for loop,why auto_ptr is deprecated,etc. (ht
tps://corecplusplustutorial.com)

Retrieved from "https://en.wikipedia.org/w/index.php?title=C%2B%2B11&oldid=1199214610"

C++14
C++14 is a version of the ISO/IEC 14882 standard for the C++ programming language. It is intended to be
a small extension over C++11, featuring mainly bug fixes and small improvements, and was replaced by
C++17. Its approval was announced on August 18, 2014.[1] C++14 was published as ISO/IEC 14882:2014
in December 2014.[2]

Because earlier C++ standard revisions were noticeably late, the name "C++1y" was sometimes used
instead until its approval, similarly to how the C++11 standard used to be termed "C++0x" with the
expectation of its release before 2010 (although in fact it slipped into 2010 and finally 2011).

New language features

These are the features added to the core language of C++14.

Function return type deduction

C++11 allowed lambda functions to deduce the return type based on the type of the expression given to the
return statement. C++14 provides this ability to all functions. It also extends these facilities to lambda
functions, allowing return type deduction for functions that are not of the form return
expression;.[3]

In order to induce return type deduction, the function must be declared with auto as the return type, but
without the trailing return type specifier in C++11:

auto DeduceReturnType(); // Return type to be determined.

If multiple return expressions are used in the function's implementation, then they must all deduce the same
type.[4]

Functions that deduce their return types can be forward declared, but they cannot be used until they have
been defined. Their definitions must be available to the translation unit that uses them.

Recursion can be used with a function of this type, but the recursive call must happen after at least one
return statement in the definition of the function:[4]

auto Correct(int i)
{
if (i == 1)
return i; // return type deduced as int

return Correct(i-1)+i; // ok to call it now

}

auto Wrong(int i)
{
if (i != 1)
return Wrong(i-1)+i; // Too soon to call this. No prior return statement.
 return i; // return type deduced as int
}

Alternate type deduction on declaration

In C++11, two methods of type deduction were added. auto was a way to create a variable of the
appropriate type, based on a given expression. decltype was a way to compute the type of a given
expression. However, decltype and auto deduce types in different ways. In particular, auto always
deduces a non-reference type, as though by using std::decay, while auto&& always deduces a
reference type. However, decltype can be prodded into deducing a reference or non-reference type,
based on the value category of the expression and the nature of the expression it is deducing:[5][3]

int i;
int&& f();
auto x3a = i; // decltype(x3a) is int
decltype(i) x3d = i; // decltype(x3d) is int
auto x4a = (i); // decltype(x4a) is int
decltype((i)) x4d = (i); // decltype(x4d) is int&
auto x5a = f(); // decltype(x5a) is int
decltype(f()) x5d = f(); // decltype(x5d) is int&&

C++14 adds the decltype(auto) syntax. This allows auto declarations to use the decltype rules
on the given expression.

The decltype(auto) syntax can also be used with return type deduction, by using
decltype(auto) syntax instead of auto for the function's return type deduction.[4]

Relaxed constexpr restrictions

C++11 introduced the concept of a constexpr-declared function; a function which could be executed at
compile time. Their return values could be consumed by operations that require constant expressions, such
as an integer template argument. However, C++11 constexpr functions could only contain a single
expression that is returned (as well as static_asserts and a small number of other declarations).

C++14 relaxes these restrictions. Constexpr-declared functions may now contain the following:[3]

Any declarations except:

static or thread_local variables.
Variable declarations without initializers.
The conditional branching statements if and switch.
Any looping statement, including range-based for.
Expressions which change the value of an object if the lifetime of that object began within
the constant expression function. This includes calls to any non-const constexpr-
declared non-static member functions.

goto statements are forbidden in C++14 relaxed constexpr-declared functions.

Also, C++11 stated that all non-static member functions that were declared constexpr were also
implicitly declared const, with respect to this. That has since been removed; non-static member
functions may be non-const.[6] However, per the restrictions above, a non-const constexpr
member function can only modify a class member if that object's lifetime began within the constant
expression evaluation.

Variable templates

In prior versions of C++, only functions, classes or type aliases could be templated. C++14 allows the
creation of variables that are templated. An example given in the proposal is a variable pi that can be read
to get the value of pi for various types (e.g., 3 when read as an integral type; the closest value possible with
float, double or long double precision when read as float, double or long double,
respectively; etc.).

The usual rules of templates apply to such declarations and definitions, including specialization.[7][8]

template<typename T>
constexpr T pi = T(3.141592653589793238462643383);

// Usual specialization rules apply:

template<>
constexpr const char* pi<const char*> = "pi";

Aggregate member initialization

C++11 added default member initializers, expressions to be applied to members at class scope if a
constructor did not initialize the member itself. The definition of aggregates was changed to explicitly
exclude any class with member initializers; therefore, they are not allowed to use aggregate initialization.

C++14 relaxes this restriction,[3] allowing aggregate initialization on such types. If the braced init list does
not provide a value for that argument, the member initializer takes care of it.[9]

Binary literals

Numeric literals in C++14 can be specified in binary form.[3] The syntax uses the prefixes 0b or 0B. The
syntax is also used in other languages e.g. Java, C#, Swift, Go, Scala, Ruby, Python, OCaml, and as an
unofficial extension in some C compilers since at least 2007.[10]

Digit separators

In C++14, the single-quote character may be used arbitrarily as a digit separator in numeric literals, both
integer literals and floating point literals.[11] This can make it easier for human readers to parse large
numbers through subitizing.

auto integer_literal = 1'000'000;

auto floating_point_literal = 0.000'015'3;
auto binary_literal = 0b0100'1100'0110;
auto a_dozen_crores = 12'00'00'000;

Generic lambdas
In C++11, lambda function parameters need to be declared with concrete types. C++14 relaxes this
requirement, allowing lambda function parameters to be declared with the auto type specifier.[7]

auto lambda = [](auto x, auto y) {return x + y;};

Concerning auto type deduction, generic lambdas follow the rules of template argument deduction (which
are similar, but not identical in all respects). The code above is equivalent to this:[12]

struct
{
template<typename T, typename U>
auto operator()(T x, U y) const {return x + y;}
} lambda{};

Generic lambdas are essentially templated functor lambdas.

Lambda capture expressions

C++11 lambda functions capture variables declared in their outer scope by value-copy or by reference. This
means that value members of a lambda cannot be move-only types.[13] C++14 allows captured members to
be initialized with arbitrary expressions. This allows both capture by value-move and declaring arbitrary
members of the lambda, without having a correspondingly named variable in an outer scope.[7]

This is done via the use of an initializer expression:

auto lambda = [value = 1] {return value;};

The lambda function lambda returns 1, which is what value was initialized with. The declared capture
deduces the type from the initializer expression as if by auto.

This can be used to capture by move, via the use of the standard std::move function:

std::unique_ptr<int> ptr(new int(10));

auto lambda = [value = std::move(ptr)] {return *value;};

The attribute [[deprecated]]

The deprecated attribute allows marking an entity deprecated, which makes it still legal to use but puts
users on notice that use is discouraged and may cause a warning message to be printed during compilation.
An optional string literal can appear as the argument of deprecated, to explain the rationale for
deprecation and suggest a replacement.

[[deprecated]] int f();

[[deprecated("g() is thread-unsafe. Use h() instead")]]

void g( int& x );

void h( int& x );

void test()
{
 int a = f(); // warning: 'f' is deprecated
g(a); // warning: 'g' is deprecated: g() is thread-unsafe. Use h() instead
}

New standard library features

Shared mutexes and locking

C++14 adds a shared timed mutex and a companion shared lock type.[14][15]

Heterogeneous lookup in associative containers

The C++ Standard Library defines four associative container classes. These classes allow the user to look
up a value based on a value of that type. The map containers allow the user to specify a key and a value,
where lookup is done by key and returns a value. However, the lookup is always done by the specific key
type, whether it is the key as in maps or the value itself as in sets.

C++14 allows the lookup to be done via an arbitrary type, so long as the comparison operator can compare
that type with the actual key type.[16] This would allow a map from std::string to some value to
compare against a const char* or any other type for which an operator< overload is available. It
is also useful for indexing composite objects in a std::set by the value of a single member without
forcing the user of find to create a dummy object (for example creating an entire struct Person to
find a person by name).

To preserve backwards compatibility, heterogeneous lookup is only allowed when the comparator given to
the associative container allows it. The standard library classes std::less<> and std::greater<>
are augmented to allow heterogeneous lookup.[17]

Standard user-defined literals

C++11 defined the syntax for user-defined literal suffixes, but the standard library did not use any of them.
C++14 adds the following standard literals:[16]

"s", for creating the various std::basic_string types.

"h", "min", "s", "ms", "us", "ns", for creating the corresponding std::chrono::duration
time intervals.
"if", "i", "il", for creating the corresponding std::complex<float>,
std::complex<double> and std::complex<long double> imaginary numbers.

auto str = "hello world"s; // auto deduces string

auto dur = 60s; // auto deduces chrono::seconds
auto z = 1i; // auto deduces complex<double>

The two "s" literals do not interact, as the string one only operates on string literals, and the one for seconds
operates only on numbers.[18]

Tuple addressing via type

The std::tuple type introduced in C++11 allows an aggregate of typed values to be indexed by a
compile-time constant integer. C++14 extends this to allow fetching from a tuple by type instead of by
index.[16] If the tuple has more than one element of the type, a compile-time error results:[19]

tuple<string, string, int> t("foo", "bar", 7);

int i = get<int>(t); // i == 7
int j = get<2>(t); // Same as before: j == 7
string s = get<string>(t); // Compile-time error due to ambiguity

Smaller library features

std::make_unique can be used like std::make_shared for std::unique_ptr objects.[7]

std::integral_constant gained an operator() overload to return the constant value.[16]

The class template std::integer_sequence and related alias templates were added for representing
compile-time integer sequences, such as the indices of elements in a parameter pack.[20]

The global std::begin/std::end functions were augmented with std::cbegin/std::cend

functions, which return constant iterators, and std::rbegin/std::rend and
std::crbegin/std::crend which return reverse iterators.

The std::exchange function template assigns a new value to a variable and returns the old value.[21]

New overloads of std::equal, std::mismatch, and std::is_permutation take a pair of

iterators for the second range, so that the caller does not need to separately check that the two ranges are of
the same length.[22]

The std::is_final type trait detects if a class is marked final.

The std::quoted stream I/O manipulator allows inserting and extracting strings with embedded spaces,
by placing delimiters (defaulting to double-quotes) on output and stripping them on input, and escaping any
embedded delimiters.[23]

Compiler support
Clang finished support for C++14 in 3.4 though under the standard name c++1y, and made C++14 the
default C++ standard in Clang 6.[24] GCC finished support for C++14 in GCC 5, and made C++14 the
default C++ standard in GCC 6.[25] Microsoft Visual Studio 2017 has implemented "almost all" C++14
features.[26]

References
1. Sutter, Herb (August 18, 2014), We have C++14! (https://isocpp.org/blog/2014/08/we-have-c
pp14), retrieved 2014-08-18
2. "ISO/IEC 14882:2014" (https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/stan
dard/06/40/64029.html). ISO.
 3. Wong, Michael (30 April 2013). "The View from the C++ Standard meeting April 2013 Part 1"
(https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82
276f3/entry/the_view_from_c_standard_meeting_april_2013_part_1?lang=en). C/C++ Cafe.
Retrieved 27 January 2016.
4. Merrill, Jason (17 April 2013). "N3638 Return type deduction for normal functions (Revision
5)" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3638.html). Retrieved 14 June
2013.
5. "Page 10 of: C++ auto and decltype Explained" (http://thbecker.net/articles/auto_and_decltyp
e/section_10.html).
6. Smith, Richard (18 April 2013). "N3652 Relaxing constraints on constexpr functions" (http://o
pen-std.org/JTC1/SC22/WG21/docs/papers/2013/n3652.html).
7. Sutter, Herb (20 April 2013). "Trip Report: ISO C++ Spring 2013 Meeting" (http://isocpp.org/bl
og/2013/04/trip-report-iso-c-spring-2013-meeting). isocpp.org. Retrieved 14 June 2013.
8. Dos Reis, Gabriel (19 April 2013). "N3651 Variable Templates (Revision 1)" (http://open-std.
org/JTC1/SC22/WG21/docs/papers/2013/n3651.pdf) (PDF).
9. Vandevoorde, Daveed; Voutilainen, Ville (17 April 2013). "N3653 Member initializers and
aggregates" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3653.html).
10. "23479 – Implement binary constants with a "0b" prefix" (https://gcc.gnu.org/bugzilla/show_b
ug.cgi?id=23479#c29).
11. Crowl, Lawrence; Smith, Richard; Snyder, Jeff; Vandevoorde, Daveed (25 September 2013).
"N3781 Single-Quotation-Mark as a Digit Separator" (http://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2013/n3781.pdf) (PDF).
12. Vali, Faisal; Sutter, Herb; Abrahams, Dave (19 April 2013). "N3649 Generic (Polymorphic)
Lambda Expressions (Revision 3)" (http://open-std.org/JTC1/SC22/WG21/docs/papers/201
3/n3649.html).
13. "Move capture in Lambda" (https://stackoverflow.com/questions/8640393/move-capture-in-la
mbda). Stack Overflow.
14. Wong, Michael (30 April 2013). "The View from the C++ Standard meeting April 2013 Part 3"
(https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82
276f3/entry/the_view_form_the_c_standard_meeting_april_2013_part_3?lang=en). C/C++
Cafe. Retrieved 14 June 2013.
15. Hinnant, Howard; Vollmann, Detlef; Boehm, Hans (19 April 2013). "N3659 Shared locking in
C++ (Revision 2)" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3659.html).
16. Wong, Michael (26 April 2013). "The View from the C++ Standard meeting April 2013 Part 2"
(https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82
276f3/entry/the_view_form_the_c_standrd_meeting_april_2013_part_2?lang=en). C/C++
Cafe. Retrieved 14 June 2013.
17. "N3657 Adding heterogeneous comparison lookup to associative containers (rev 4)" (http://o
pen-std.org/JTC1/SC22/WG21/docs/papers/2013/n3657.htm). 19 March 2013.
18. Sommerlad, Peter (18 April 2013). "N3642 User-defined Literals for Standard Library Types
(part 1 - version 4)" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3642.pdf)
(PDF).
19. Spertus, Mike (19 April 2013). "N3670 Wording for Addressing Tuples by Type: Revision 2"
(http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3670.html).
20. Wakely, Jonathan (18 April 2013). "N3658 Compile-time integer sequences" (http://www.ope
n-std.org/JTC1/sc22/WG21/docs/papers/2013/n3658.html). Retrieved 5 January 2016.
21. Yasskin, Jeffrey (19 April 2013). "N3668 exchange() utility function, revision 3" (http://www.op
en-std.org/JTC1/sc22/WG21/docs/papers/2013/n3668.html). Retrieved 5 January 2016.
22. Spertus, Mike; Pall, Attila (19 April 2013). "N3671 Making non-modifying sequence
operations more robust: Revision 2" (http://www.open-std.org/JTC1/sc22/WG21/docs/papers/
2013/n3671.html). Retrieved 5 January 2016.
23. Dawes, Beman (19 April 2013). "N3654 Quoted Strings Library Proposal (Revision 2)" (http://
www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3654.html). Retrieved 5 January
2016.
24. "C++ Support in Clang" (http://clang.llvm.org/cxx_status.html). Retrieved 28 May 2016.
25. "C++ Standards Support in GCC" (https://gcc.gnu.org/projects/cxx-status.html). Retrieved
28 May 2016.
26. "C++ Standards Conformance from Microsoft" (https://blogs.msdn.microsoft.com/vcblog/201
7/03/07/c-standards-conformance-from-microsoft/). 7 March 2017. Retrieved 7 March 2017.

External links
C++14: What you need to know (https://web.archive.org/web/20150814081653/http://www.dr
dobbs.com/cpp/the-c14-standard-what-you-need-to-know/240169034) Overview of features
in Dr. Dobb's, 16 Sept. 2014

Retrieved from "https://en.wikipedia.org/w/index.php?title=C%2B%2B14&oldid=1179470055"

C++17
C++17 is a version of the ISO/IEC 14882 standard for the C++ programming language. C++17 replaced
the prior version of the C++ standard, called C++14, and was later replaced by C++20.

History
Before the C++ Standards Committee fixed a 3-year release cycle, C++17's release date was uncertain. In
that time period, the C++17 revision was also called C++1z, following C++0x or C++1x for C++11 and
C++1y for C++14. The C++17 specification reached the Draft International Standard (DIS) stage in March
2017.[1][2] This DIS was unanimously approved, with only editorial comments,[3] and the final standard
was published in December 2017.[4] Few changes were made to the C++ Standard Template Library,
although some algorithms in the <algorithm> header were given support for explicit parallelization and
some syntactic enhancements were made.

New features
C++17 introduced many new features. The following lists may be incomplete.

Language
Making the text message for static_assert optional[5]
Allow typename (as an alternative to class) in a template template parameter[6]
New rules for auto deduction from braced-init-list[7][8]
Nested namespace definitions, e.g., namespace X::Y { … } instead of namespace X
{ namespace Y { … } }[8][9]
Allowing attributes for namespaces and enumerators[10][11]
New standard attributes [[fallthrough]], [[maybe_unused]] and
[[nodiscard]][12]
UTF-8 (u8) character literals[10][13] (UTF-8 string literals have existed since C++11; C++17
adds the corresponding character literals for consistency, though as they are restricted to a
single byte they can only store "Basic Latin" and C0 control codes, i.e. ASCII)
Hexadecimal floating-point literals[14][15]
Use of auto as the type for a non-type template parameter[16]
Constant evaluation for all non-type template arguments[10][17]
Fold expressions, for variadic templates[10][18]
A compile-time static if with the form if constexpr(expression)[19]
Structured binding declarations, allowing auto [a, b] =
getTwoReturnValues();[20]
Initializers in if and switch statements[21]
copy-initialization and direct-initialization of objects of type T from prvalue expressions of
type T (ignoring top-level cv-qualifiers) shall result in no copy or move constructors from the
 prvalue expression. See copy elision for more information.
Some extensions on over-aligned memory allocation[22]
Class template argument deduction (CTAD), introducing constructor deduction guides, e.g.
allowing std::pair(5.0, false) instead of requiring explicit constructor arguments
types std::pair<double, bool>(5.0, false) or an additional helper template
function std::make_pair(5.0, false).[23][24]
Inline variables, which allows the definition of variables in header files without violating the
one definition rule. The rules are effectively the same as inline functions
__has_include, allowing the availability of a header to be checked by preprocessor
directives[25]
Value of __cplusplus changed to 201703L[26]
Exception specifications were made part of the function type[27]
Lambda expressions can capture "*this" by value[28]

Library
Most of Library Fundamentals TS I, including:[29][30]
std::string_view, a read-only non-owning reference to a character sequence or
string-slice[31]
std::optional, for representing optional objects, a data type that may not always be
returned by a given algorithm with support for non-return
std::any, for holding single values of any type
std::uncaught_exceptions, as a replacement of std::uncaught_exception in
exception handling[32][10]
New insertion functions try_emplace and insert_or_assign for std::map and
std::unordered_map key-value associative data structures[33][34]
Uniform container access: std::size, std::empty and std::data[34][35]
Definition of "contiguous iterators"[34][36]
A file system library based on boost::filesystem[37]
Parallel versions of STL algorithms[38]
Additional mathematical special functions, including elliptic integrals and Bessel
functions[39]
std::variant, a tagged union container[40]
std::byte, allowing char to be replaced for data types intending to model a byte of data as
a byte rather than a character[41]
Logical operator traits: std::conjunction, std::disjunction and
std::negation[42]
<memory_resource> header, for polymorphic memory resources[43]

Removed features
This revision of C++ not only added new features but also removed a few.

Trigraphs were removed.[44][45]

 Some deprecated types and functions were removed from the standard library, including
std::auto_ptr, std::random_shuffle, and old function adaptors.[8][46] These were
superseded in C++11 by improved facilities such as std::unique_ptr, std::shuffle,
std::bind, and lambdas.
The (formerly deprecated) use of the keyword register as a storage class specifier was
removed.[47] This keyword is still reserved but now unused.

Compiler support
GCC has had complete support for C++17 language features since version 8.[48]
Clang 5 and later supports all C++17 language features.[49]
Visual Studio 2017 15.8 (MSVC 19.15) and later supports all C++17 language
features.[50][51]

Library support
libstdc++ since version 9.1 has complete support for C++17 (8.1 without Parallelism TS and
referring to C99 instead of C11) [52]
libc++ as of version 9 has partial support for C++17, with the remainder "in progress" [53]
Visual Studio 2017 15.8 (MSVC 19.15) Standard Library and later supports all C++17 library
features except for "Elementary String Conversions" and referring to C99 instead of C11.
"Elementary String Conversions" is added in Visual Studio 2019 16.4[54]

See also
C++ compilers
C11 (C standard revision)
C17 (C standard revision)

References
1. "N4661 Editors' Report -- Programming Languages -- C++" (http://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2017/n4661.html). 21 March 2017. Archived (https://web.archive.org/we
b/20200204081709/http://open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4661.html) from
the original on 2020-02-04. Retrieved 2017-03-21.
2. "ISO/IEC DIS 14882: Programming Languages — C++" (https://web.archive.org/web/201703
25025026/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4660.pdf) (PDF).
Archived from the original (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4660.
pdf) (PDF) on 2017-03-25.
3. Herb Sutter (6 September 2017). "C++17 is formally approved" (https://herbsutter.com/2017/0
9/06/c17-is-formally-approved/). Archived (https://web.archive.org/web/20200129151205/http
s://herbsutter.com/2017/09/06/c17-is-formally-approved/) from the original on 29 January
2020. Retrieved 12 September 2017.
4. "ISO/IEC 14882:2017" (https://www.iso.org/standard/68564.html). Archived (https://web.archi
ve.org/web/20130129110331/http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_d
etail.htm?csnumber=50372) from the original on 2013-01-29. Retrieved 2017-12-03.
 5. "N3928: Extending static_assert, v2 (Walter E. Brown)" (http://www.open-std.org/jtc1/sc22/wg
21/docs/papers/2014/n3928.pdf) (PDF). Archived (https://web.archive.org/web/20150811125
019/http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3928.pdf) (PDF) from the
original on 2015-08-11. Retrieved 2015-04-03.
6. "N4051: Allow typename in a template template parameter (Richard Smith)" (http://www.ope
n-std.org/jtc1/sc22/wg21/docs/papers/2014/n4051.html). Archived (https://web.archive.org/w
eb/20150811124402/http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4051.html)
from the original on 2015-08-11. Retrieved 2015-04-03.
7. "N3922: New Rules for auto deduction from braced-init-list (James Dennett)" (http://www.ope
n-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html). Archived (https://web.archive.org/w
eb/20150810183244/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html)
from the original on 2015-08-10. Retrieved 2014-11-28.
8. "Updates to my trip report" (http://isocpp.org/blog/2014/11/updates-to-my-trip-report).
Archived (https://web.archive.org/web/20150319164316/https://isocpp.org/blog/2014/11/upd
ates-to-my-trip-report) from the original on 2015-03-19. Retrieved 2014-11-28.
9. "N4230: Nested namespace definition (Robert Kawulak, Andrew Tomazos)" (http://www.ope
n-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html). Archived (https://web.archive.org/w
eb/20150803104044/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html)
from the original on 2015-08-03. Retrieved 2014-11-28.
10. "New core language papers adopted for C++17" (https://isocpp.org/blog/2014/11/new-paper
s-adopted-for-cpp17). Archived (https://web.archive.org/web/20150427234634/https://isocpp.
org/blog/2014/11/new-papers-adopted-for-cpp17) from the original on 2015-04-27. Retrieved
2014-11-15.
11. "N4266: Attributes for namespaces and enumerators (Richard Smith)" (http://isocpp.org/files/
papers/n4266.html). Archived (https://web.archive.org/web/20160306192948/https://isocpp.o
rg/files/papers/n4266.html) from the original on 2016-03-06. Retrieved 2014-11-15.
12. "N4640: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4640.pdf) (PDF). pp. 193–195. Archived (https://web.archi
ve.org/web/20170312034609/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n46
40.pdf) (PDF) from the original on 2017-03-12. Retrieved 2017-03-09.
13. "N4267: Adding u8 character literals (Richard Smith)" (http://isocpp.org/files/papers/n4267.ht
ml). Archived (https://web.archive.org/web/20151028205257/https://isocpp.org/files/papers/n
4267.html) from the original on 2015-10-28. Retrieved 2014-11-15.
14. Thomas Köppe. "Hexadecimal floating literals for C++" (http://wg21.link/p0245r1). Archived
(https://web.archive.org/web/20220921201419/https://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2016/p0245r1.html) from the original on 2022-09-21. Retrieved 2017-07-16.
15. "N4659: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4659.pdf) (PDF). §5.13.4. Archived (https://web.archive.or
g/web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.p
df) (PDF) from the original on 2017-12-07. Retrieved 2017-03-24.
16. James Touton; Mike Spertus (2016-06-23). "Declaring non-type template parameters with
auto" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r2.html). Archived (htt
ps://web.archive.org/web/20170916093650/http://www.open-std.org/jtc1/sc22/wg21/docs/pa
pers/2016/p0127r2.html) from the original on 2017-09-16. Retrieved 2020-11-08.
17. "N4268: Allow constant evaluation for all non-type template arguments (Richard Smith)" (htt
p://isocpp.org/files/papers/n4268.html). Archived (https://web.archive.org/web/201603120956
10/https://isocpp.org/files/papers/n4268.html) from the original on 2016-03-12. Retrieved
2014-11-15.
18. "N4295: Folding expressions (Andrew Sutton, Richard Smith)" (http://isocpp.org/files/papers/
n4295.html). Archived (https://web.archive.org/web/20150404075316/https://isocpp.org/files/
papers/n4295.html) from the original on 2015-04-04. Retrieved 2014-11-15.
19. "N4659: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4659.pdf) (PDF). §9.4.1. Archived (https://web.archive.or
g/web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.p
df) (PDF) from the original on 2017-12-07. Retrieved 2017-03-24.
20. "N4659: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4659.pdf) (PDF). §11.5. Archived (https://web.archive.org/
web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf)
(PDF) from the original on 2017-12-07. Retrieved 2017-03-24.
21. "Selection statements with initializer" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
016/p0305r1.html). Archived (https://web.archive.org/web/20171006024728/http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html) from the original on 2017-10-06.
Retrieved 2018-10-09.
22. "Dynamic memory allocation for over-aligned data" (http://www.open-std.org/jtc1/sc22/wg21/
docs/papers/2016/p0035r4.html). Archived (https://web.archive.org/web/20170908201146/htt
p://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0035r4.html) from the original on
2017-09-08. Retrieved 2017-03-13.
23. "Class template argument deduction" (https://en.cppreference.com/w/cpp/language/class_te
mplate_argument_deduction). Archived (https://web.archive.org/web/20190131040627/http
s://en.cppreference.com/w/cpp/language/class_template_argument_deduction) from the
original on 2019-01-31. Retrieved 2019-01-30.
24. "CppCon 2018: Timur Doumler "Class template argument deduction in C++17" " (https://ww
w.youtube.com/watch?v=UDs90b0yjjQ). YouTube. Archived (https://web.archive.org/web/20
190821042758/https://www.youtube.com/watch?v=UDs90b0yjjQ&gl=US&hl=en) from the
original on 2019-08-21. Retrieved 2019-01-30.
25. "N4640: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4640.pdf) (PDF). pp. 431–433. Archived (https://web.archi
ve.org/web/20170312034609/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n46
40.pdf) (PDF) from the original on 2017-03-12. Retrieved 2017-03-09.
26. "N4659: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4659.pdf) (PDF). §19.8. Archived (https://web.archive.org/
web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf)
(PDF) from the original on 2017-12-07. Retrieved 2017-03-24.
27. "P0012R1: Make exception specifications be part of the type system, version 5" (http://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html). Archived (https://web.archive.or
g/web/20170912064524/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.
html) from the original on 2017-09-12. Retrieved 2018-12-17.
28. "P0018R3: Lambda Capture of *this by Value as [=,*this], version 3" (http://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2016/p0018r3.html). Archived (https://web.archive.org/web/20
170822153946/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0018r3.html)
from the original on 2017-08-22. Retrieved 2021-06-21.
29. "Adopt Library Fundamentals V1 TS Components for C++17 (R1)" (https://isocpp.org/files/pa
pers/p0220r1.html). Archived (https://web.archive.org/web/20160405060908/https://isocpp.or
g/files/papers/p0220r1.html) from the original on 2016-04-05. Retrieved 2016-03-23.
30. "Current Status" (https://isocpp.org/std/status). Archived (https://web.archive.org/web/202009
08083135/https://isocpp.org/std/status) from the original on 2020-09-08.
31. "std::basic_string_view - cppreference.com" (http://en.cppreference.com/w/cpp/string/basic_s
tring_view). en.cppreference.com. Archived (https://web.archive.org/web/20160617220428/h
ttp://en.cppreference.com/w/cpp/string/basic_string_view) from the original on 2016-06-17.
Retrieved 2016-06-23.
32. "N4259: Wording for std::uncaught_exceptions (Herb Sutter)" (http://isocpp.org/files/papers/n
4259.pdf) (PDF). Archived (https://web.archive.org/web/20141129022746/http://isocpp.org/fil
es/papers/n4259.pdf) (PDF) from the original on 2014-11-29. Retrieved 2014-11-15.
33. "N4279: Improved insertion interface for unique-key maps (Thomas Köppe)" (https://isocpp.o
rg/files/papers/n4279.html). Archived (https://web.archive.org/web/20150427234153/https://is
ocpp.org/files/papers/n4279.html) from the original on 2015-04-27. Retrieved 2014-11-15.
34. "New standard library papers adopted for C++17" (https://isocpp.org/blog/2014/11/new-stand
ard-library-papers-adopted-for-cpp17). Archived (https://web.archive.org/web/201411290226
47/https://isocpp.org/blog/2014/11/new-standard-library-papers-adopted-for-cpp17) from the
original on 2014-11-29. Retrieved 2014-11-15.
35. "N4280: Non-member size() and more (Riccardo Marcangelo)" (https://isocpp.org/files/paper
s/n4280.pdf) (PDF). Archived (https://web.archive.org/web/20150309065322/http://isocpp.or
g/files/papers/n4280.pdf) (PDF) from the original on 2015-03-09. Retrieved 2014-11-15.
36. "N4284: Contiguous Iterators (Jens Maurer)" (https://isocpp.org/files/papers/n4284.html).
Archived (https://web.archive.org/web/20141129022748/https://isocpp.org/files/papers/n428
4.html) from the original on 2014-11-29. Retrieved 2014-11-15.
37. "Filesystem Library Proposal (Beman Dawes)" (http://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2013/n3505.html). Archived (https://web.archive.org/web/20160720075346/http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html) from the original on 2016-07-
20. Retrieved 2015-12-12.
38. "The Parallelism TS Should be Standardized" (https://isocpp.org/files/papers/P0024R2.htm
l). Archived (https://web.archive.org/web/20160405100743/https://isocpp.org/files/papers/P0
024R2.html) from the original on 2016-04-05. Retrieved 2016-03-23.
39. "Mathematical Special Functions for C++17, v5" (https://isocpp.org/files/papers/P0226R1.pd
f) (PDF). Archived (https://web.archive.org/web/20160405090715/https://isocpp.org/files/pap
ers/P0226R1.pdf) (PDF) from the original on 2016-04-05. Retrieved 2016-03-23.
40. "N4659: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4659.pdf) (PDF). §23.7. Archived (https://web.archive.org/
web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf)
(PDF) from the original on 2017-12-07. Retrieved 2017-03-24.
41. "A byte type definition" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0298r3.pd
f) (PDF). Archived (https://web.archive.org/web/20170325202328/http://open-std.org/JTC1/S
C22/WG21/docs/papers/2017/p0298r3.pdf) (PDF) from the original on 2017-03-25.
Retrieved 2017-03-25.
42. "N4659: Working Draft, Standard for Programming Language C++" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2017/n4659.pdf) (PDF). §23.15.8. Archived (https://web.archive.
org/web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.
pdf) (PDF) from the original on 2017-12-07. Retrieved 2017-03-24.
43. "PMR (Polymorphic Memory Resources) fully described -- Nico Josuttis" (https://isocpp.org/b
log/2018/10/pmr-polymorphic-memory-resources). Archived (https://web.archive.org/web/202
10828223659/https://isocpp.org/blog/2018/10/pmr-polymorphic-memory-resources) from the
original on 2021-08-28. Retrieved 2020-11-16.
44. "N3981: Removing trigraphs??! (Richard Smith)" (http://www.open-std.org/JTC1/SC22/WG2
1/docs/papers/2014/n3981.html). 2014-05-06. Archived (https://web.archive.org/web/201807
09123422/http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3981.html) from
the original on 2018-07-09. Retrieved 2015-04-03.
45. IBM comment on preparing for a Trigraph-adverse future in C++17 (http://www.open-std.org/jt
c1/sc22/wg21/docs/papers/2014/n4210.pdf) Archived (https://web.archive.org/web/20180911
053619/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4210.pdf) 2018-09-11 at
the Wayback Machine, IBM paper N4210, 2014-10-10. Authors: Michael Wong, Hubert Tong,
Rajan Bhakta, Derek Inglis
46. "N4190: Removing auto_ptr, random_shuffle(), And Old <functional> Stuff (Stephan T.
Lavavej)" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4190.htm). Archived
(https://web.archive.org/web/20171020150616/http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2014/n4190.htm) from the original on 2017-10-20. Retrieved 2014-11-28.
47. "C++ Keywords: register" (https://en.cppreference.com/w/cpp/keyword/register). Archived (htt
ps://web.archive.org/web/20180903114706/https://en.cppreference.com/w/cpp/keyword/regi
ster) from the original on 2018-09-03. Retrieved 2018-09-03.
48. "C++ Standards Support in GCC - GNU Project - Free Software Foundation (FSF)" (https://g
cc.gnu.org/projects/cxx-status.html). gcc.gnu.org. Archived (https://web.archive.org/web/2018
0404073049/https://gcc.gnu.org/projects/cxx-status.html) from the original on 2018-04-04.
Retrieved 2018-04-03.
49. "Clang - C++17, C++14, C++11 and C++98 Status" (https://clang.llvm.org/cxx_status.html).
clang.llvm.org. Archived (https://web.archive.org/web/20130704124639/http://clang.llvm.org/
cxx_status.html) from the original on 2013-07-04. Retrieved 2018-06-26.
50. corob-msft. "Visual C++ Language Conformance" (https://docs.microsoft.com/en-us/cpp/visu
al-cpp-language-conformance). docs.microsoft.com. Archived (https://web.archive.org/web/2
0180619113256/https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance)
from the original on 2018-06-19. Retrieved 2018-06-19.
51. "Announcing: MSVC Conforms to the C++ Standard" (https://blogs.msdn.microsoft.com/vcblo
g/2018/05/07/announcing-msvc-conforms-to-the-c-standard/). 7 May 2018. Archived (https://
web.archive.org/web/20180826095016/https://blogs.msdn.microsoft.com/vcblog/2018/05/07/
announcing-msvc-conforms-to-the-c-standard/) from the original on 2018-08-26. Retrieved
2018-05-08.
52. "Chapter 1. Status" (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html).
gcc.gnu.org. Archived (https://web.archive.org/web/20180604111405/http://gcc.gnu.org/onlin
edocs/libstdc++/manual/status.html) from the original on 2018-06-04. Retrieved 2018-06-19.
53. "libc++ C++17 Status" (http://libcxx.llvm.org/cxx1z_status.html). llvm.org. Archived (https://we
b.archive.org/web/20190524173505/http://libcxx.llvm.org/cxx1z_status.html) from the original
on 2019-05-24. Retrieved 2019-05-24.
54. "Announcing: MSVC Conforms to the C++ Standard" (https://devblogs.microsoft.com/cppblo
g/announcing-msvc-conforms-to-the-c-standard/). devblogs.microsoft.com. 7 May 2018.
Archived (https://web.archive.org/web/20180826095016/https://blogs.msdn.microsoft.com/vc
blog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/) from the original on 2018-
08-26. Retrieved 2019-05-24.

Retrieved from "https://en.wikipedia.org/w/index.php?title=C%2B%2B17&oldid=1146735978"

C++20
C++20 is a version of the ISO/IEC 14882 standard for the C++ programming language. C++20 replaced
the prior version of the C++ standard, called C++17, and was later replaced by C++23.[1] The standard was
technically finalized[2] by WG21 at the meeting in Prague in February 2020,[3] had its final draft version
announced in March 2020,[4] was approved on 4 September 2020,[5][6] and published in December
2020.[7]

Features
C++20 adds more new major features than C++14 or C++17.[8] Changes that have been accepted into
C++20 include:[9]

Language
concepts,[10] with terse syntax[11]
modules[12]
designated initializers[13] (based on the C99 feature, and common g++ extension)
[=, this] as a lambda capture[14]
template parameter lists on lambdas[15]
three-way comparison using the "spaceship operator", operator <=>
initialization of an additional variable within a range-based for statement[16]
lambdas in unevaluated contexts[17][18]
default constructible and assignable stateless lambdas[17][19]
allow pack expansions in lambda init-capture[17][20]
class types in non-type template parameters, also allowing string literals as template
parameters[21]
removing the need for typename in certain circumstances[22]
new standard attributes [[no_unique_address]],[23] [[likely]] and
[[unlikely]][24]
conditional explicit, allowing the explicit modifier to be contingent on a boolean
expression[25]
expanded constexpr: virtual functions,[26] union,[27] try and catch,[28]
dynamic_cast and typeid,[29] std::pointer_traits[30]
immediate functions using the new consteval keyword[31]
signed integers are now defined to be represented using two's complement (signed integer
overflow remains undefined behavior)[32]
a revised memory model[33]
various improvements to structured bindings (interaction with lambda captures, static and
thread_local storage duration)[34][35]
coroutines[36]
 using on scoped enums[37]
constinit keyword[38]

Library
ranges (The One Ranges Proposal)[39]
std::make_shared and std::allocate_shared for arrays[40]
atomic smart pointers (such as std::atomic<shared_ptr<T>> and
std::atomic<weak_ptr<T>>)[41]
std::to_address to convert a pointer to a raw pointer[42]
calendar and time-zone additions to <chrono>[43]
std::span, providing a view to a contiguous array (analogous to std::string_view
but span can mutate the referenced sequence)[44]
std::erase and std::erase_if, simplifying element erasure for most standard
containers[45]
<version> header[46]
std::bit_cast<> for type casting of object representations, with less verbosity than
memcpy() and more ability to exploit compiler internals[47]
feature test macros[48]
various constexpr library bits[49]
smart pointer creation with default initialization[50]
contains-method for associative containers[51]
bit operations, such as leading/trailing zero/one count,[52] and log2 operations[53][54][55]
std::bind_front[56]

New and changed keywords

Many new keywords added (and the new "spaceship operator", operator <=>), such as concept,
constinit,[38] consteval, co_await, co_return, co_yield, requires (plus changed
meaning for export), and char8_t (for UTF-8 support).[57] And explicit can take an expression
since C++20.[58] Most of the uses of the volatile keyword have been deprecated.[59]

In addition to keywords, there are identifiers with special meaning, including new import and module.

New attributes in C++20: [[likely]], [[unlikely]], and [[no_unique_address]][60]

Removed and deprecated

Removed features:[61]

The C-derived headers <ccomplex>, <ciso646>, <cstdalign>, <cstdbool> and

<ctgmath> were removed, as they serve no purpose in C++. (The corresponding <*.h>
headers remain, for compatibility with C.)
The use of throw() as an exception specification was removed.
 Some previously deprecated library features were removed, including
std::uncaught_exception, std::raw_storage_iterator,
std::is_literal_type, std::is_literal_type_v, std::result_of and
std::result_of_t.

Deprecated features:

Use of comma operator in subscript expressions has been deprecated[62]

(most of) volatile has been deprecated[59]

Published as Technical Specifications

Parallelism TS v2[63] (including task blocks[64])
Reflection TS v1[65]
Networking TS v1[66]

Deferred to a later standard

Contracts – a new study group (SG21) has been formed to work on a new proposal[67]
Reflection[68][69]
Metaclasses[70]
Executors[71]
Networking extensions,[72][73] including async, basic I/O services, timers, buffers and buffer-
oriented streams, sockets, and Internet protocols (blocked by executors)
Properties[74]
Extended futures[75]

Compiler support
Full support[76]

Visual Studio 2019 supports all C++20 features through its /std:c++latest option, as of
version 16.10.0.[77] An option /std:c++20 to enable C++20 mode is added in version
16.11.0.[78][79]

Microsoft's compiler does not just support Windows, also Linux (and e.g. Android and iOS), while it then
requires the "Visual C++ for Linux Development extension".[80]

Partial

Clang has partial C++20 support that can be enabled with the option -std=c++20 (version
10 and later) or -std=c++2a (version 9 and earlier).[81]
EDG started implementing C++20 features in version 5.0 and as of version 6.1 supports most
C++20 core language features.[82]
GCC added partial, experimental C++20 support in 2017[83] in version 8 through the option -
std=c++2a. Like Clang, GCC replaced this option with -std=c++20 in version 10. It also
 has an option to enable GNU extensions in addition to the experimental C++20 support, -
std=gnu++20.[84]

History
Changes applied to the C++20 working draft in July 2017 (Toronto) include:[85]

concepts (what made it into the standard is a cut-down version; also described as "Concepts
Lite"[86])
designated initializers
[=, this] as a lambda capture
template parameter lists on lambdas
std::make_shared and std::allocate_shared for arrays

Changes applied to the C++20 working draft in the fall meeting in November 2017 (Albuquerque)
include:[87][88]

three-way comparison using the "spaceship operator", operator <=>

initialization of an additional variable within a range-based for statement
lambdas in unevaluated contexts
default constructible and assignable stateless lambdas
allow pack expansions in lambda init-capture
string literals as template parameters
atomic smart pointers (such as std::atomic<shared_ptr<T>> and
std::atomic<weak_ptr<T>>)
std::to_address to convert a pointer to a raw pointer

Changes applied to the C++20 working draft in March 2018 (Jacksonville) include:[89]

removing the need for typename in certain circumstances

new standard attributes [[no_unique_address]], [[likely]] and [[unlikely]]
calendar and time-zone additions to <chrono>
std::span, providing a view to a contiguous array (analogous to std::string_view
but span can mutate the referenced sequence)
<version> header

Changes applied to the C++20 working draft in the summer meeting in June 2018 (Rapperswil) include:[90]

contracts (later deferred to a later standard)[91]

feature test macros
bit-casting of object representations, with less verbosity than memcpy() and more ability to
exploit compiler internals
conditional explicit, allowing the explicit modifier to be contingent on a boolean
expression
constexpr virtual functions

Changes applied to the C++20 working draft in the fall meeting in November 2018 (San Diego)
include:[92]
 ranges (The One Ranges Proposal)
concept terse syntax
constexpr union, try and catch, dynamic_cast, typeid and
std::pointer_traits.
various constexpr library bits
immediate functions using the new consteval keyword
signed integers are now defined to be represented using two's complement (signed integer
overflow remains undefined behavior)
refinements of the contracts facility (access control in contract conditions)[93] (see list of
features deferred to a later standard)
a revised memory model
smart pointer creation with default initialization

Changes applied to the C++20 working draft in the winter meeting in February 2019 (Kona)
include:[94][95][96]

coroutines
modules
various improvements to structured bindings (interaction with lambda captures, static and
thread_local storage duration)

Changes applied to the C++20 working draft in the summer meeting in July 2019 (Cologne)
include:[97][98][99][100]

contracts were removed (see list of features deferred to a later standard)[101]

use of comma operator in subscript expressions has been deprecated[62]
constexpr additions (trivial default initialization,[102] unevaluated inline-assembly[103])
using scoped enums[37]
various changes to the spaceship operator[104][105]
DR: minor changes to modules[106]
constinit keyword
changes to concepts (removal of -> Type return-type-requirements[107])
(most of) volatile has been deprecated[59]
DR: [[nodiscard]] effects on constructors[108]
The new standard library concepts will not use PascalCase (rather standard_case, as
the rest of the standard library)[109]
text formatting (std::format, [110][111] chrono integration,[112] corner case fixes[113])
bit operations[52]
constexpr INVOKE[114]
math constants[115]
consistency additions to atomics (std::atomic_ref<T>,[116]
std::atomic<std::shared_ptr<T>>[117])
add the <=> operator to the standard library[118]
header units for the standard library[119]
 synchronization facilities[120] (merged from: Efficient atomic waiting and semaphores,[121]
latches and barriers,[122] Improving atomic_flag,[123] Don't Make C++ Unimplementable
On Small CPUs[124])
std::source_location[125]
constexpr containers (std::string,[126] std::vector[127])
std::stop_token and joining thread (std::jthread)[128]

Changes applied during the NB comment resolution in the fall meeting in November 2019 (Belfast)
include:[129][130][131][132]

Class Types in Non-Type Template Parameters (NTTP): The restriction of no user-defined

operator== allowed has been removed as the meaning of template argument equality has
been divorced from operator==.[133] This allows also for array members in class-type
NTTP.
Floating-point types,[134] pointers and references and unions and union-like classes (class
types containing anonymous unions) are now allowed as NTTP.
Function identity now also includes trailing requires-clauses (P1971)
Constrained non-template functions have been removed
<compare> is now available in freestanding implementations[135]
std::spans typedef was changed from index_type to size_type to be consistent with
the rest of the standard library[136]
Concept traits have been renamed to follow the renaming of the concepts as a result from the
Cologne meeting
Several fixes and additions to ranges (P1456R1: Move-only views,[137] P1391R4: Range
constructor for std::string_view (constructor from iterator-pair of characters),[138]
P1394R4: Range constructor for std::span<ref>,[139] P1870R1: forwarding-range<T> is
too subtle[140])
Initialization for std::atomic<T> has been changed to make it work with default and list
initialization,[141] std::latch and std::barrier can now report the maximum number
of threads that the implementation supports through the new member function max()
std::weak_equality and std::strong_equality have been removed as they are
not used anymore
Algorithms in <numeric> have been made constexpr
Missing feature-test macros for new or changed features of C++20 have been added[142]

References
1. "The Standard" (https://isocpp.org/std/the-standard). isocpp.org. Archived (https://web.archiv
e.org/web/20200919050617/https://isocpp.org/std/the-standard) from the original on 19
September 2020. Retrieved 7 September 2020.
2. Sutter, Herb (2019-10-01). "P1000R3: C++ IS schedule" (https://www.open-std.org/jtc1/sc22/
wg21/docs/papers/2019/p1000r3.pdf) (PDF). Archived (https://web.archive.org/web/2019111
4141143/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1000r3.pdf) (PDF) from
the original on 2019-11-14. Retrieved 2020-02-13.
 3. Dusíková, Hana (2019-11-06). "N4817: 2020 Prague Meeting Invitation and Information" (htt
ps://open-std.org/JTC1/SC22/WG21/docs/papers/2019/n4817.pdf) (PDF). Archived (https://w
eb.archive.org/web/20191229102449/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
019/n4817.pdf) (PDF) from the original on 2019-12-29. Retrieved 2020-02-13.
4. "N4859 Editors' Report -- Programming Languages -- C++" (https://www.open-std.org/jtc1/sc
22/wg21/docs/papers/2020/n4859.html). Archived (https://web.archive.org/web/2022120913
2251/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4859.html) from the
original on 2022-12-09. Retrieved 2023-09-22.
5. "Current Status" (https://isocpp.org/std/status). isocpp.org. Archived (https://web.archive.org/
web/20200908083135/https://isocpp.org/std/status) from the original on 8 September 2020.
Retrieved 7 September 2020.
6. "C++20 Approved -- Herb Sutter" (https://isocpp.org/blog/2020/09/cpp20-approved-herb-sutte
r). isocpp.org. Archived (https://web.archive.org/web/20200911150359/https://isocpp.org/blo
g/2020/09/cpp20-approved-herb-sutter) from the original on 11 September 2020. Retrieved
8 September 2020.
7. "ISO/IEC 14882:2020" (https://www.iso.org/standard/79358.html). Archived (https://web.archi
ve.org/web/20201216154357/https://www.iso.org/standard/79358.html) from the original on
2020-12-16. Retrieved 2020-12-16.
8. "Why does the C++ standard ship every three years?" (https://herbsutter.com/2019/07/13/draf
t-faq-why-does-the-c-standard-ship-every-three-years/). 13 July 2019. Archived (https://web.a
rchive.org/web/20190713161618/https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-
standard-ship-every-three-years/) from the original on 13 July 2019. Retrieved 19 July 2019.
9. "P0592R0: To boldly suggest an overall plan for C++20" (https://www.open-std.org/jtc1/sc22/
wg21/docs/papers/2017/p0592r0.html). Archived (https://web.archive.org/web/20170308143
910/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0592r0.html) from the
original on 2017-03-08. Retrieved 2017-05-06.
10. "P0606R0: Concepts Are Ready" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/201
7/p0606r0.pdf) (PDF). Archived (https://web.archive.org/web/20170328144243/http://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2017/p0606r0.pdf) (PDF) from the original on 2017-
03-28. Retrieved 2017-05-06.
11. "P1141R1 - Yet another approach for constrained declarations" (http://open-std.org/JTC1/SC
22/WG21/docs/papers/2018/p1141r1.html). Archived (https://web.archive.org/web/20181111
133625/http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1141r1.html) from the
original on 2018-11-11. Retrieved 2018-11-11.
12. "N4720: Working Draft, Extensions to C++ for Modules" (https://isocpp.org/files/papers/n472
0.pdf) (PDF). Archived (https://web.archive.org/web/20190430095053/https://isocpp.org/files/
papers/n4720.pdf) (PDF) from the original on 2019-04-30. Retrieved 2019-04-30.
13. Tim Shen; Richard Smith. "Designated Initialization Wording" (https://wg21.link/p0329).
Archived (https://web.archive.org/web/20171015165744/https://wg21.link/p0329) from the
original on 2017-10-15. Retrieved 2017-07-16.
14. Thomas Köppe. "Allow lambda capture [=, this]" (https://wg21.link/p0409). Archived (https://w
eb.archive.org/web/20190209180040/https://wg21.link/p0409) from the original on 2019-02-
09. Retrieved 2017-07-16.
15. "Familiar template syntax for generic lambdas" (https://wg21.link/p0428). Archived (https://we
b.archive.org/web/20181121022051/https://wg21.link/p0428) from the original on 2018-11-
21. Retrieved 2017-07-16.
16. "Range-based for statements with initializer" (https://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2017/p0614r0.html). Archived (https://web.archive.org/web/20170406231710/http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r0.html) from the original on 2017-
04-06. Retrieved 2019-10-30.
17. "Trip Report: C++ Standards Meeting in Albuquerque, November 2017" (https://botondballo.
wordpress.com/2017/11/20/trip-report-c-standards-meeting-in-albuquerque-november-201
7/). There's Waldo!. 2017-11-20. Archived (https://web.archive.org/web/20171211161242/htt
ps://botondballo.wordpress.com/2017/11/20/trip-report-c-standards-meeting-in-albuquerque-
november-2017/) from the original on 2017-12-11. Retrieved 2017-12-11.
18. "Wording for lambdas in unevaluated contexts" (https://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2017/p0315r4.pdf) (PDF). Archived (https://web.archive.org/web/2017121203142
8/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0315r4.pdf) (PDF) from the
original on 2017-12-12. Retrieved 2017-12-11.
19. "Default constructible and assignable stateless lambdas" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2017/p0624r2.pdf) (PDF). Archived (https://web.archive.org/web/20171
212031425/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0624r2.pdf) (PDF)
from the original on 2017-12-12. Retrieved 2017-12-11.
20. "Pack expansion in lambda init-capture" (https://www.open-std.org/jtc1/sc22/wg21/docs/pap
ers/2017/p0780r0.html). www.open-std.org. Archived (https://web.archive.org/web/20200214
081039/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0780r0.html) from the
original on 2020-02-14. Retrieved 2017-12-11.
21. "Class Types in Non-Type Template Parameters" (https://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2018/p0732r2.pdf) (PDF). www.open-std.org. 2018-06-06. Archived (https://web.a
rchive.org/web/20220205083651/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/
p0732r2.pdf) (PDF) from the original on 2022-02-05. Retrieved 2022-02-18.
22. Nina Ranns; Daveed Vandevoorde. "Down with typename!" (https://www.open-std.org/jtc1/sc
22/wg21/docs/papers/2018/p0634r3.html). Archived (https://web.archive.org/web/201804221
80216/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0634r3.html) from the
original on 2018-04-22. Retrieved 2019-05-18.
23. "Language support for empty objects" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2018/p0840r2.html). Archived (https://web.archive.org/web/20180417180340/http://www.ope
n-std.org/jtc1/sc22/wg21/docs/papers/2018/p0840r2.html) from the original on 2018-04-17.
Retrieved 2019-08-04.
24. "Proposed wording for likely and unlikely attributes (Revision 5)" (https://www.open-std.org/jt
c1/sc22/wg21/docs/papers/2018/p0479r5.html). Archived (https://web.archive.org/web/20180
513080343/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0479r5.html) from
the original on 2018-05-13. Retrieved 2019-05-18.
25. "explicit(bool)" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0892r2.html).
www.open-std.org. Archived (https://web.archive.org/web/20180720061629/http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p0892r2.html) from the original on 2018-07-20.
Retrieved 2018-11-13.
26. "Allowing Virtual Function Calls in Constant Expressions" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2018/p1064r0.html). www.open-std.org. Archived (https://web.archive.or
g/web/20180611142757/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1064r0.
html) from the original on 2018-06-11. Retrieved 2019-03-11.
27. "P1330R0 - Changing the active member of a union inside constexpr" (https://wg21.link/p13
30). Archived (https://web.archive.org/web/20190726101620/https://wg21.link/p1330) from
the original on 2019-07-26. Retrieved 2019-07-26.
28. "P1002R0 - Try-catch blocks in constexpr functions" (https://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2018/p1002r0.pdf) (PDF). Archived (https://web.archive.org/web/2018111113
3628/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1002r0.pdf) (PDF) from the
original on 2018-11-11. Retrieved 2018-11-11.
29. "P1327R0 - Allowing dynamic_cast, polymorphic typeid in Constant Expressions" (https://wg
21.link/p1327). Archived (https://web.archive.org/web/20190726101620/https://wg21.link/p13
27) from the original on 2019-07-26. Retrieved 2019-07-26.
30. "P1006R1 - Constexpr in std::pointer_traits" (https://www.open-std.org/jtc1/sc22/wg21/docs/p
apers/2018/p1006r1.pdf) (PDF). Archived (https://web.archive.org/web/20181111133625/htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1006r1.pdf) (PDF) from the original
on 2018-11-11. Retrieved 2018-11-11.
31. "P1073R2 - Immediate functions" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/201
8/p1073r2.html). Archived (https://web.archive.org/web/20181026124307/http://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2018/p1073r2.html) from the original on 2018-10-26.
Retrieved 2018-11-11.
32. "P1236R0: Alternative Wording for P0907R4 Signed Integers are Two's Complement" (http
s://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r0.html). Archived (https://web.
archive.org/web/20181111133642/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201
8/p1236r0.html) from the original on 2018-11-11. Retrieved 2018-11-11.
33. "P0668R4: Revising the C++ memory model" (https://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2018/p0668r4.html). Archived (https://web.archive.org/web/20181111133634/http://
www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0668r4.html) from the original on
2018-11-11. Retrieved 2018-11-11.
34. "P1091R1: Extending structured bindings to be more like variable declarations" (https://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1091r1.html). www.open-std.org. Archived
(https://web.archive.org/web/20190126105655/http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2018/p1091r1.html) from the original on 2019-01-26. Retrieved 2019-02-24.
35. "P1091R2: Extending structured bindings to be more like variable declarations" (https://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1091r2.html). www.open-std.org. Archived
(https://web.archive.org/web/20190126112016/http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2018/p1091r2.html) from the original on 2019-01-26. Retrieved 2019-02-24.
36. "N4649: Working Draft, Technical Specification for C++ Extensions for Coroutines" (https://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4649.pdf) (PDF). Archived (https://web.a
rchive.org/web/20170516185504/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/
n4649.pdf) (PDF) from the original on 2017-05-16. Retrieved 2017-05-06.
37. "P1099R5: Using Enum" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1099r5.
html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/201908200019
59/http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1099r5.html) from the original
on 2019-08-20. Retrieved 2019-07-20.
38. "P1143R2: Adding the constinit keyword" (http://open-std.org/JTC1/SC22/WG21/docs/paper
s/2019/p1143r2.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/
20190820001957/http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1143r2.html)
from the original on 2019-08-20. Retrieved 2019-07-20.
39. "P0896R3" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0896r3.pdf) (PDF).
Archived (https://web.archive.org/web/20181111133612/http://www.open-std.org/jtc1/sc22/w
g21/docs/papers/2018/p0896r3.pdf) (PDF) from the original on 2018-11-11. Retrieved
2018-11-11.
40. "Extending make_shared to Support Arrays" (https://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2017/p0674r1.html). Archived (https://web.archive.org/web/20170906070027/http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0674r1.html) from the original on 2017-
09-06. Retrieved 2020-02-12.
41. Meredith, Alisdair; Sutter, Herb. "Revising atomic_shared_ptr for C++20" (https://www.open-s
td.org/jtc1/sc22/wg21/docs/papers/2017/p0718r2.html). JTC1/SC22/WG21 - The C++
Standards Committee - ISOCPP. ISO. Archived (https://web.archive.org/web/201801041841
59/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0718r2.html) from the original
on 4 January 2018. Retrieved 27 December 2018.
42. "Utility to convert a pointer to a raw pointer" (https://www.open-std.org/jtc1/sc22/wg21/docs/p
apers/2017/p0653r2.html). Archived (https://web.archive.org/web/20180220012525/http://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0653r2.html) from the original on 2018-
02-20. Retrieved 2020-02-12.
43. Howard E. Hinnant; Tomasz Kamiński. "Extending <chrono> to Calendars and Time Zones"
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html). Archived (https://
web.archive.org/web/20180513074927/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2018/p0355r7.html) from the original on 2018-05-13. Retrieved 2019-05-18.
44. Neil MacIntosh; Stephan T. Lavavej. "span: bounds-safe views for sequences of objects" (htt
p://wg21.link/p0122). Archived (https://web.archive.org/web/20190518102826/http://wg21.lin
k/p0122) from the original on 2019-05-18. Retrieved 2019-05-18.
45. Alisdair Meredith; Stephan T. Lavavej (2018-10-04). "Adopt Consistent Container Erasure
from Library Fundamentals 2 for C++20" (https://www.open-std.org/jtc1/sc22/wg21/docs/pap
ers/2018/p1209r0.html). Archived (https://web.archive.org/web/20210308123055/http://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1209r0.html) from the original on 2021-03-
08. Retrieved 2020-12-14.
46. Alan Talbot. "<version>" (http://wg21.link/p0754). Archived (https://web.archive.org/web/2019
0518102900/http://wg21.link/p0754) from the original on 2019-05-18. Retrieved 2019-05-18.
47. "Bit-casting object representations" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
018/p0476r2.html). www.open-std.org. Archived (https://web.archive.org/web/201808181904
26/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0476r2.html) from the original
on 2018-08-18. Retrieved 2018-11-10.
48. "Integrating feature-test macros into the C++ WD (rev. 2)" (https://www.open-std.org/jtc1/sc22/
wg21/docs/papers/2018/p0941r2.html). www.open-std.org. Archived (https://web.archive.org/
web/20180720144603/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0941r2.ht
ml) from the original on 2018-07-20. Retrieved 2018-11-10.
49. "P1032R1 - Misc constexpr bits" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/201
8/p1032r1.html). Archived (https://web.archive.org/web/20181026124238/http://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2018/p1032r1.html) from the original on 2018-10-26.
Retrieved 2018-11-11.
50. "Smart pointer creation with default initialization" (https://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2018/p1020r1.html). Archived (https://web.archive.org/web/20190126111714/htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1020r1.html) from the original on
2019-01-26. Retrieved 2020-02-12.
51. Mikhail Maltsev. "P0458R2: Checking for Existence of an Element in Associative
Containers" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0458r2.html).
Archived (https://web.archive.org/web/20220116211430/https://www9.open-std.org/JTC1/SC
22/WG21/docs/papers/2018/p0458r2.html) from the original on 2022-01-16. Retrieved
2022-01-02.
52. "P0553R4: Bit operations" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0553
r4.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/2019072010
1004/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0553r4.html) from the
original on 2019-07-20. Retrieved 2019-07-20.
53. "P0556R3: Integral power-of-2 operations" (https://wg21.link/p0556r3). www.open-std.org.
2018-06-06. Archived (https://web.archive.org/web/20190626184254/https://wg21.link/p0556
r3) from the original on 2019-06-26. Retrieved 2020-08-08.
54. "P1355R2 Exposing a narrow contract for ceil2" (https://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2019/p1355r2.html). www.open-std.org. 2019-06-11. Archived (https://web.archive.
org/web/20190805104347/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1355r
2.html) from the original on 2019-08-05. Retrieved 2020-08-08.
55. "On the names of low-level bit manipulation functions" (https://www.open-std.org/jtc1/sc22/w
g21/docs/papers/2020/p1956r1.pdf) (PDF). www.open-std.org. 2020-02-11. Archived (https://
web.archive.org/web/20200324173059/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2020/p1956r1.pdf) (PDF) from the original on 2020-03-24. Retrieved 2020-08-08.
56. Tomasz Kamiński (2017-11-09). "Simplified partial function application" (https://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2017/p0356r3.html). Archived (https://web.archive.org/we
b/20200928182706/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0356r3.html)
from the original on 2020-09-28. Retrieved 2020-11-08.
57. "C++ keywords - cppreference.com" (https://en.cppreference.com/w/cpp/keyword).
en.cppreference.com. Archived (https://web.archive.org/web/20120319210634/https://en.cpp
reference.com/w/cpp/keyword) from the original on 2012-03-19. Retrieved 2019-08-04.
58. "explicit specifier - cppreference.com" (https://en.cppreference.com/w/cpp/language/explicit).
en.cppreference.com. Archived (https://web.archive.org/web/20120221163715/https://en.cpp
reference.com/w/cpp/language/explicit) from the original on 2012-02-21. Retrieved
2019-08-04.
59. "P1152R4: Deprecating volatile" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/
p1152r3.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/20190
623042109/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r3.html) from
the original on 2019-06-23. Retrieved 2019-07-20.
60. "attribute specifier sequence(since C++11) - cppreference.com" (https://en.cppreference.co
m/w/cpp/language/attributes). en.cppreference.com. Archived (https://web.archive.org/web/2
0120705235229/https://en.cppreference.com/w/cpp/language/attributes) from the original on
2012-07-05. Retrieved 2019-08-04.
61. "Working Draft, Standard for Programming Language C++ (Annex C, §C.1)" (http://open-std.
org/JTC1/SC22/WG21/docs/papers/2020/n4861.pdf) (PDF). Archived (https://web.archive.or
g/web/20200427145844/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4861.p
df) (PDF) from the original on 2020-04-27. Retrieved 2020-11-18.
62. "P1161R2: Deprecate uses of the comma operator in subscripting expressions" (https://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1161r2.html). www.open-std.org. Archived
(https://web.archive.org/web/20190720101000/http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2019/p1161r2.html) from the original on 2019-07-20. Retrieved 2019-07-20.
63. "C++ Extensions for Parallelism Version 2" (https://wg21.link/N4793). Archived (https://web.a
rchive.org/web/20220921201417/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/201
8/n4793.pdf) (PDF) from the original on 2022-09-21. Retrieved 2019-07-09.
64. "Task Blocks" (http://www.modernescpp.com/index.php/task-blocks). 3 March 2017. Archived
(https://web.archive.org/web/20170919141316/http://www.modernescpp.com/index.php/task-
blocks) from the original on 2017-09-19. Retrieved 2017-07-23.
65. "C++ Extensions for Reflection" (https://wg21.link/N4818). Archived (https://web.archive.org/
web/20220921201417/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4818.pd
f) (PDF) from the original on 2022-09-21. Retrieved 2019-07-09.
66. "C++ Extensions for Networking" (https://wg21.link/N4711). Archived (https://web.archive.or
g/web/20220921201418/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4711.
pdf) (PDF) from the original on 2022-09-21. Retrieved 2019-07-09.
67. Sutter, Herb (2019-07-20). "Trip report: Summer ISO C++ standards meeting (Cologne)" (http
s://herbsutter.com/2019/07/20/trip-report-summer-iso-c-standards-meeting-cologne/). Sutter's
Mill. Archived (https://web.archive.org/web/20200417181512/https://herbsutter.com/2019/07/
20/trip-report-summer-iso-c-standards-meeting-cologne/) from the original on 2020-04-17.
Retrieved 2019-07-21.
68. "Reflections on the reflection proposals - Meeting C++" (https://meetingcpp.com/index.php/b
r/items/reflections-on-the-reflection-proposals.html). meetingcpp.com. Archived (https://web.a
rchive.org/web/20170623034739/http://meetingcpp.com/index.php/br/items/reflections-on-th
e-reflection-proposals.html) from the original on 2017-06-23. Retrieved 2017-06-30.
69. "Static reflection" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0194r6.html).
www.open-std.org. Archived (https://web.archive.org/web/20200222002039/http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p0194r6.html) from the original on 2020-02-22.
Retrieved 2018-11-10.
70. Herb Sutter. "Metaclasses" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p070
7r0.pdf) (PDF). Archived (https://web.archive.org/web/20201111204111/http://www.open-std.
org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf) (PDF) from the original on 2020-11-11.
Retrieved 2017-07-23.
71. "A Unified Executors Proposal for C++" (https://www.open-std.org/jtc1/sc22/wg21/docs/paper
s/2019/p0443r10.html). www.open-std.org. Archived (https://web.archive.org/web/202002200
55757/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0443r10.html) from the
original on 2020-02-20. Retrieved 2019-02-24.
72. "N4771: Working Draft, C++ Extensions for Networking" (https://www.open-std.org/jtc1/sc22/
wg21/docs/papers/2018/n4771.pdf) (PDF). Archived (https://web.archive.org/web/20200419
011113/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4771.pdf) (PDF) from the
original on 2020-04-19. Retrieved 2019-03-23.
73. "ISO/IEC TS 19216:2018 Programming Languages -- C++ Extensions for Networking" (http
s://www.iso.org/standard/64030.html). Archived (https://web.archive.org/web/201901152019
23/https://www.iso.org/standard/64030.html) from the original on 2019-01-15. Retrieved
2018-12-17.
74. "A General Property Customization Mechanism" (https://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2019/p1393r0.html). www.open-std.org. Archived (https://web.archive.org/web/20
200119114436/http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1393r0.html)
from the original on 2020-01-19. Retrieved 2019-02-24.
75. "A Unified Futures Proposal for C++" (https://wg21.link/P1054). Archived (https://web.archive.
org/web/20220921201420/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p105
4r0.html) from the original on 2022-09-21. Retrieved 2019-07-08.
76. "C++ compiler support - cppreference.com" (https://en.cppreference.com/w/cpp/compiler_su
pport). en.cppreference.com. Archived (https://web.archive.org/web/20220808151657/https://
en.cppreference.com/w/cpp/compiler_support) from the original on 2022-08-08. Retrieved
2022-08-12.
77. jawiddis. "Visual Studio 2019 version 16.10 Release Notes" (https://docs.microsoft.com/en-u
s/visualstudio/releases/2019/release-notes-v16.10#16.10.0). docs.microsoft.com. Archived
(https://web.archive.org/web/20210811215520/https://docs.microsoft.com/en-us/visualstudio/
releases/2019/release-notes-v16.10#16.10.0) from the original on 2021-08-11. Retrieved
2021-07-13.
78. "MSVC C++20 and the /std:c++20 Switch" (https://devblogs.microsoft.com/cppblog/msvc-cpp
20-and-the-std-cpp20-switch/). docs.microsoft.com. 2 September 2021. Archived (https://web.
archive.org/web/20210906151426/https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-t
he-std-cpp20-switch/) from the original on 2021-09-06. Retrieved 2021-09-07.
79. Visual Studio documentation for Microsoft C++ (https://github.com/MicrosoftDocs/cpp-docs/bl
ob/578dd21279a897661686617375dff80f1eb2f40c/docs/overview/cpp-conformance-improv
ements.md), Microsoft Docs, 2022-04-19, archived (https://web.archive.org/web/2022041916
1220/https://github.com/MicrosoftDocs/cpp-docs/blob/578dd21279a897661686617375dff80f
1eb2f40c/docs/overview/cpp-conformance-improvements.md) from the original on 2022-04-
19, retrieved 2022-04-19
80. "Visual Studio 2019 Compatibility" (https://docs.microsoft.com/en-us/visualstudio/releases/2
019/compatibility). docs.microsoft.com. Archived (https://web.archive.org/web/202006030601
10/https://docs.microsoft.com/en-us/visualstudio/releases/2019/compatibility) from the
original on 2020-06-03. Retrieved 2022-08-12.
81. "Clang - C++ Programming Language Status" (https://clang.llvm.org/cxx_status.html).
clang.llvm.org. Archived (https://web.archive.org/web/20130704124639/http://clang.llvm.org/
cxx_status.html) from the original on 2013-07-04. Retrieved 2022-04-19.
82. "C++ compiler support - cppreference.com" (https://en.cppreference.com/w/cpp/compiler_su
pport). en.cppreference.com. Archived (https://web.archive.org/web/20201003141955/https://
en.cppreference.com/w/cpp/compiler_support) from the original on 2020-10-03. Retrieved
2020-10-10.
83. "Andrew Sutton - [PATCH] Add -std=c++2a" (https://gcc.gnu.org/legacy-ml/gcc-patches/2017-
07/msg01234.html). gcc.gnu.org. Archived (https://web.archive.org/web/20210301065559/htt
ps://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01234.html) from the original on 2021-
03-01. Retrieved 2022-04-19.
84. "C++ Standards Support in GCC - GNU Project" (https://gcc.gnu.org/projects/cxx-status.htm
l). gcc.gnu.org. Archived (https://web.archive.org/web/20220420114133/https://gcc.gnu.org/pr
ojects/cxx-status.html) from the original on 2022-04-20. Retrieved 2022-04-19.
85. Herb Sutter (15 July 2017). "Trip report: Summer ISO C++ standards meeting (Toronto)" (http
s://herbsutter.com/2017/07/15/trip-report-summer-iso-c-standards-meeting-toronto/). Archived
(https://web.archive.org/web/20170806182136/https://herbsutter.com/2017/07/15/trip-report-s
ummer-iso-c-standards-meeting-toronto/) from the original on 2017-08-06. Retrieved
2017-07-16.
86. Andrew Sutton; Bjarne Stroustrup (2013-02-24). "Concepts Lite: Constraining Templates
with Predicates" (https://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-p
redicates-andrew-sutton-bjarne-s). isocpp.org. Archived (https://web.archive.org/web/202101
16175846/https://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicat
es-andrew-sutton-bjarne-s) from the original on 2021-01-16. Retrieved 2021-01-13.
87. Herb Sutter (11 November 2017). "Trip report: Fall ISO C++ standards meeting
(Albuquerque)" (https://herbsutter.com/2017/11/11/trip-report-fall-iso-c-standards-meeting-alb
uquerque/). Archived (https://web.archive.org/web/20190213081959/https://herbsutter.com/2
017/11/11/trip-report-fall-iso-c-standards-meeting-albuquerque/) from the original on 2019-
02-13. Retrieved 2017-12-04.
88. Smith, Richard; Perchik, Dawn; Köppe, Thomas. "N4714 Editors' Report -- Programming
Languages -- C++" (https://github.com/cplusplus/draft/blob/master/papers/n4714.md). C++
standards drafts. GitHub. Archived (https://web.archive.org/web/20220921201419/https://gith
ub.com/cplusplus/draft/blob/main/papers/n4714.md) from the original on 21 September
2022. Retrieved 27 December 2018.
89. Botond Ballo (28 March 2018). "Trip Report: C++ Standards Meeting in Jacksonville, March
2018" (https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jack
sonville-march-2018/). Archived (https://web.archive.org/web/20190518102815/https://boton
dballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-201
8/) from the original on 2019-05-18. Retrieved 2019-05-18.
90. Herb Sutter (2 July 2018). "Trip report: Summer ISO C++ standards meeting (Rapperswil)" (h
ttps://herbsutter.com/2018/07/02/trip-report-summer-iso-c-standards-meeting-rapperswil/).
Archived (https://web.archive.org/web/20200523083708/https://herbsutter.com/2018/07/02/tri
p-report-summer-iso-c-standards-meeting-rapperswil/) from the original on 2020-05-23.
Retrieved 2018-11-10.
 91. "Support for contract based programming in C++" (https://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2018/p0542r5.html). www.open-std.org. Archived (https://web.archive.org/web/20
200115232059/http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0542r5.html) from
the original on 2020-01-15. Retrieved 2018-11-10.
92. fall meeting in November 2018 (http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/n47
15.pdf)
93. "P1289R0 - Access control in contract conditions" (https://www.open-std.org/jtc1/sc22/wg21/
docs/papers/2018/p1289r0.pdf) (PDF). Archived (https://web.archive.org/web/201811111336
31/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1289r0.pdf) (PDF) from the
original on 2018-11-11. Retrieved 2018-11-11.
94. winter meeting in February 2019 (https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/
n4765.pdf)
95. "r/cpp - 2019-02 Kona ISO C++ Committee Trip Report (C++20 design is complete; Modules
in C++20; Coroutines in C++20; Reflection TS v1 published; work begins on a C++
Ecosystem Technical Report)" (https://www.reddit.com/r/cpp/comments/au0c4x/201902_kon
a_iso_c_committee_trip_report_c20/). reddit. 23 February 2019. Archived (https://web.archiv
e.org/web/20190223234513/https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_i
so_c_committee_trip_report_c20/) from the original on 2019-02-23. Retrieved 2019-02-24.
96. "Trip report: Winter ISO C++ standards meeting (Kona)" (https://herbsutter.com/2019/02/23/tri
p-report-winter-iso-c-standards-meeting-kona/). Sutter's Mill. 2019-02-23. Archived (https://w
eb.archive.org/web/20190224030105/https://herbsutter.com/2019/02/23/trip-report-winter-iso
-c-standards-meeting-kona/) from the original on 2019-02-24. Retrieved 2019-02-24.
97. "2019 Cologne Meeting Invitation and Information" (https://www.open-std.org/jtc1/sc22/wg21/

🚀
docs/papers/2018/n4783.pdf) (PDF).

Landed 🚀
98. "r/cpp - 2019-07 Cologne ISO C++ Committee Trip Report — The C++20 Eagle has
(C++20 Committee Draft shipped; Contracts Moved From C++20 to a Study
Group; 'std::format' in C++20; C++20 Synchronization Library)" (https://www.reddit.com/r/cpp/
comments/cfk9de/201907_cologne_iso_c_committee_trip_report_the/). reddit. 20 July 2019.
Archived (https://web.archive.org/web/20200420142050/https://www.reddit.com/r/cpp/comme
nts/cfk9de/201907_cologne_iso_c_committee_trip_report_the/) from the original on 2020-
04-20. Retrieved 2019-09-15.
99. Botond Ballo (26 July 2019). "Trip Report: C++ Standards Meeting in Cologne, July 2019" (ht
tps://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-
2019/). Archived (https://web.archive.org/web/20200226062236/https://botondballo.wordpres
s.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/) from the original on
2020-02-26. Retrieved 2019-08-05.
100. Sutter, Herb (20 July 2019). "Trip report: Summer ISO C++ standards meeting (Cologne)" (htt
ps://herbsutter.com/2019/07/20/trip-report-summer-iso-c-standards-meeting-cologne/).
Archived (https://web.archive.org/web/20200417181512/https://herbsutter.com/2019/07/20/tri
p-report-summer-iso-c-standards-meeting-cologne/) from the original on 2020-04-17.
Retrieved 2019-07-21.
101. Josuttis, Nicolai. "P1823R0: Remove Contracts from C++20" (https://open-std.org/JTC1/SC2
2/WG21/docs/papers/2019/p1823r0.pdf) (PDF). Archived (https://web.archive.org/web/20200
813202348/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1823r0.pdf) (PDF)
from the original on 2020-08-13. Retrieved 2019-08-20.
102. "Permitting trivial default initialization in constexpr contexts" (https://www.open-std.org/jtc1/sc
22/wg21/docs/papers/2019/p1331r1.pdf) (PDF). Archived (https://web.archive.org/web/2020
1019233314/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1331r1.pdf) (PDF)
from the original on 2020-10-19. Retrieved 2019-07-20.
103. "P1668R1: Enabling Constexpr Intrinsics By Permitting Unevaluated inline-asm in
Constexpr Functions" (http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1668r1.htm
l). www.open-std.org. Archived (https://web.archive.org/web/20200119114611/http://www.op
en-std.org/JTC1/SC22/WG21/docs/papers/2019/p1668r1.html) from the original on 2020-01-
19. Retrieved 2019-07-20.
104. "P1186R3: When do you actually use <=>?" (http://open-std.org/JTC1/SC22/WG21/docs/pap
ers/2019/p1186r3.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/we
b/20190820001956/http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1186r3.html)
from the original on 2019-08-20. Retrieved 2019-07-20.
105. "P1630R1: Spaceship needs a tune-up" (http://open-std.org/JTC1/SC22/WG21/docs/papers/
2019/p1630r1.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/2
0190820001956/http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1630r1.html) from
the original on 2019-08-20. Retrieved 2019-07-20.
106. "P1766R1: Mitigating minor modules maladies" (http://open-std.org/JTC1/SC22/WG21/docs/
papers/2019/p1766r1.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.or
g/web/20190820002001/http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1766r1.ht
ml) from the original on 2019-08-20. Retrieved 2019-07-20.
107. "P1452R2: On the non-uniform semantics of return-type-requirements" (http://open-std.org/JT
C1/SC22/WG21/docs/papers/2019/p1452r2.html). www.open-std.org. 2019-07-20. Archived
(https://web.archive.org/web/20190820001954/http://open-std.org/JTC1/SC22/WG21/docs/p
apers/2019/p1452r2.html) from the original on 2019-08-20. Retrieved 2019-07-20.
108. "P1771R1: nodiscard for constructors" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2019/p1771r1.pdf) (PDF). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/
web/20220921201418/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1771r1.
pdf) (PDF) from the original on 2022-09-21. Retrieved 2019-07-20.
109. "P1754R1: Rename concepts to standard_case for C++20, while we still can" (http://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2019/p1754r1.pdf) (PDF). www.open-std.org. 2019-
07-20. Archived (https://web.archive.org/web/20190820001957/http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2019/p1754r1.pdf) (PDF) from the original on 2019-08-20. Retrieved
2019-07-20.
110. "P0645R10: Text Formatting" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p06
45r10.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/2019082
0002001/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0645r10.html) from the
original on 2019-08-20. Retrieved 2019-07-20.
111. "std::format in C++20" (http://www.zverovich.net/2019/07/23/std-format-cpp20.html).
www.zverovich.net. 2019-07-23. Archived (https://web.archive.org/web/20190723193126/htt
p://www.zverovich.net/2019/07/23/std-format-cpp20.html) from the original on 2019-07-23.
Retrieved 2019-09-15.
112. "P1361R2: Integration of chrono with text formatting" (http://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2019/p1361r2.pdf) (PDF). www.open-std.org. 2019-07-20. Archived (https://we
b.archive.org/web/20190820002000/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
19/p1361r2.pdf) (PDF) from the original on 2019-08-20. Retrieved 2019-07-20.
113. "P1652R1: Printf corner cases in std::format" (http://www.open-std.org/jtc1/sc22/wg21/docs/p
apers/2019/p1652r1.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/
web/20190820001955/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1652r1.ht
ml) from the original on 2019-08-20. Retrieved 2019-07-20.
114. "P1965R2: constexpr INVOKE" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p
1065r2.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/201908
20001957/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1065r2.html) from the
original on 2019-08-20. Retrieved 2019-07-20.
115. "P0631R8: Math Constants" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p06
31r8.pdf) (PDF). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/web/2019
0820001958/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0631r8.pdf) (PDF)
from the original on 2019-08-20. Retrieved 2019-07-20.
116. "P1643R1: Add wait/notify to atomic_ref<T>" (http://www.open-std.org/jtc1/sc22/wg21/docs/p
apers/2019/p1643r1.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.org/
web/20190820001955/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1643r1.ht
ml) from the original on 2019-08-20. Retrieved 2019-07-20.
117. "P1664R0: Add wait/notify to atomic<shared_ptr<T>>" (http://www.open-std.org/jtc1/sc22/wg
21/docs/papers/2019/p1644r0.html). www.open-std.org. 2019-07-20. Archived (https://web.ar
chive.org/web/20211105153653/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p
1644r0.html) from the original on 2021-11-05. Retrieved 2019-07-20.
118. "P1614R2: The Mothership has Landed - Adding <=> to the Library" (http://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2019/p1614r2.html). www.open-std.org. 2019-07-20. Archived
(https://web.archive.org/web/20190820002002/http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2019/p1614r2.html) from the original on 2019-08-20. Retrieved 2019-07-20.
119. "P1502R1: Standard library header units for C++20" (http://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2019/p1502r1.html). www.open-std.org. 2019-07-20. Archived (https://web.arc
hive.org/web/20190820001955/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p
1502r1.html) from the original on 2019-08-20. Retrieved 2019-07-20.
120. "P1135R6: The C++20 Synchronization Library" (http://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2019/p1135r6.html). www.open-std.org. 2019-07-20. Archived (https://web.archive.
org/web/20190820001959/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1135r
6.html) from the original on 2019-08-20. Retrieved 2019-07-20.
121. "P0514R4: Efficient concurrent waiting for C++20" (http://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2018/p0514r4.pdf) (PDF). Archived (https://web.archive.org/web/2018081819043
7/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0514r4.pdf) (PDF) from the
original on 2018-08-18. Retrieved 2019-07-20.
122. "P0666R2: Revised Latches and Barriers for C++20" (http://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2018/p0666r2.pdf) (PDF). Archived (https://web.archive.org/web/2018081819
0352/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0666r2.pdf) (PDF) from the
original on 2018-08-18. Retrieved 2019-07-20.
123. "P0995R1: Improving atomic_flag" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201
8/p0995r1.html). Archived (https://web.archive.org/web/20190720101004/http://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2018/p0995r1.html) from the original on 2019-07-20.
Retrieved 2019-07-20.
124. "P1285R0: Don't Make C++ Unimplementable On Small CPUs" (http://www.open-std.org/jtc
1/sc22/wg21/docs/papers/2018/p1258r0.html). Archived (https://web.archive.org/web/201907
15230819/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1258r0.html) from the
original on 2019-07-15. Retrieved 2019-07-20.
125. "P1208R6: Adopt source_location from Library Fundamentals V3 for C++20" (http://open-std.
org/JTC1/SC22/WG21/docs/papers/2019/p1208r6.pdf) (PDF). Archived (https://web.archive.
org/web/20190820002002/http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1208r6.
pdf) (PDF) from the original on 2019-08-20. Retrieved 2019-08-20.
126. "P0980R1: Making std::string constexpr" (http://www.open-std.org/jtc1/sc22/wg21/docs/paper
s/2019/p0980r1.pdf) (PDF). Archived (https://web.archive.org/web/20200929222645/http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0980r1.pdf) (PDF) from the original on
2020-09-29. Retrieved 2020-07-30.
127. "P1004R2: Making std::vector constexpr" (http://www.open-std.org/jtc1/sc22/wg21/docs/pape
rs/2019/p1004r2.pdf) (PDF). Archived (https://web.archive.org/web/20200928192253/http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1004r2.pdf) (PDF) from the original on
2020-09-28. Retrieved 2020-07-30.
128. "P0660R10: Stop Token and Joining Thread" (http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2019/p0660r10.pdf) (PDF). Archived (https://web.archive.org/web/20190820001959/
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0660r10.pdf) (PDF) from the
original on 2019-08-20. Retrieved 2019-08-20.
129. fall meeting in November 2019 (https://wg21.link/n4814)
130. "r/cpp - 2019-11 Belfast ISO C++ Committee Trip Report — Started Processing Feedback on
the C++20 Committee Draft; ABI Review Group Formed" (https://www.reddit.com/r/cpp/comm
ents/dtuov8/201911_belfast_iso_c_committee_trip_report/). reddit. 9 November 2019.
Archived (https://web.archive.org/web/20191109121426/https://www.reddit.com/r/cpp/comme
nts/dtuov8/201911_belfast_iso_c_committee_trip_report/) from the original on 2019-11-09.
Retrieved 2019-11-09.
131. Sutter, Herb (2019-11-09). "Trip report: Autumn ISO C++ standards meeting (Belfast)" (https://
herbsutter.com/2019/11/09/trip-report-autumn-iso-c-standards-meeting-belfast/). Sutter's Mill.
Archived (https://web.archive.org/web/20191109130530/https://herbsutter.com/2019/11/09/tri
p-report-autumn-iso-c-standards-meeting-belfast/) from the original on 2019-11-09. Retrieved
2019-11-09.
132. botondballo (2019-11-15). "Trip Report: C++ Standards Meeting in Belfast, November 2019"
(https://botondballo.wordpress.com/2019/11/15/trip-report-c-standards-meeting-in-belfast-no
vember-2019/). There's Waldo!. Archived (https://web.archive.org/web/20191120074550/http
s://botondballo.wordpress.com/2019/11/15/trip-report-c-standards-meeting-in-belfast-novem
ber-2019/) from the original on 2019-11-20. Retrieved 2019-11-24.
133. "P1907R0: Inconsistencies with non-type template parameters" (http://www.open-std.org/jtc
1/sc22/wg21/docs/papers/2019/p1907r0.html). www.open-std.org. 2019-10-07. Archived (htt
ps://web.archive.org/web/20191109111420/http://www.open-std.org/jtc1/sc22/wg21/docs/pa
pers/2019/p1907r0.html) from the original on 2019-11-09. Retrieved 2019-11-09.
134. "P1714: NTTP are incomplete without float, double, and long double! (Revision 1)" (http://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1714r1.html). www.open-std.org. 2019-
07-19. Archived (https://web.archive.org/web/20191109111421/http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2019/p1714r1.html) from the original on 2019-11-09. Retrieved
2019-11-09.
135. "P1855R=: Make <compare> freestanding" (http://www.open-std.org/jtc1/sc22/wg21/docs/pa
pers/2019/p1855r0.html). www.open-std.org. 2019-10-05. Archived (https://web.archive.org/w
eb/20191109111422/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1855r0.htm
l) from the original on 2019-11-09. Retrieved 2019-11-09.
136. "P1872R0: span should have size_type not index_type" (http://www.open-std.org/jtc1/sc22/w
g21/docs/papers/2019/p1872r0.pdf) (PDF). www.open-std.org. 2019-09-16. Archived (https://
web.archive.org/web/20191109111423/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2019/p1872r0.pdf) (PDF) from the original on 2019-11-09. Retrieved 2019-11-09.
137. "P1456: Move-only views" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1456
r0.pdf) (PDF). www.open-std.org. 2019-01-25. Archived (https://web.archive.org/web/201911
09111425/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1456r0.pdf) (PDF)
from the original on 2019-11-09. Retrieved 2019-11-09.
138. "P1391: Range constructor for std::string_view" (http://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2019/p1391r4.pdf) (PDF). www.open-std.org. Archived (https://web.archive.org/we
b/20200104215539/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1391r4.pdf)
(PDF) from the original on 2020-01-04. Retrieved 2019-11-09.
139. "P1394: Range constructor for std::span" (http://www.open-std.org/jtc1/sc22/wg21/docs/pape
rs/2019/p1394r3.pdf) (PDF). www.open-std.org. 2019-08-02. Archived (https://web.archive.or
g/web/20191109111421/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1394r3.
pdf) (PDF) from the original on 2019-11-09. Retrieved 2019-11-09.
140. "P1870R1: forwarding-range<T> is too subtle" (http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2019/p1870r0.html). www.open-std.org. 6 October 2019. Archived (https://web.archiv
e.org/web/20191109111421/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p187
0r0.html) from the original on 2019-11-09. Retrieved 2019-11-09.
141. "P0883: Fixing Atomic Initialization" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
18/p0883r1.pdf) (PDF). www.open-std.org. 2018-06-05. Archived (https://web.archive.org/we
b/20191109111419/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0883r1.pdf)
(PDF) from the original on 2019-11-09. Retrieved 2019-11-09.
142. "Missing feature-test macros 2018-2019" (http://www.open-std.org/jtc1/sc22/wg21/docs/pape
rs/2019/p1902r0.html). www.open-std.org. 2019-10-06. Archived (https://web.archive.org/we
b/20191109111423/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1902r0.html)
from the original on 2019-11-09. Retrieved 2019-11-09.

External links
Link to purchase ISO/IEC 14882:2020 (https://www.iso.org/standard/79358.html) from the
ISO online store.
N4860 (https://isocpp.org/files/papers/N4860.pdf), the final draft version of the standard.
JTC1/SC22/WG21 (http://www.open-std.org/jtc1/sc22/wg21/) – the ISO/IEC C++ Standard
Working Group (a.k.a. the C++ Standards Committee)
Ranges (range-v3 (https://github.com/ericniebler/range-v3)) GitHub repository, by Eric
Niebler

Retrieved from "https://en.wikipedia.org/w/index.php?title=C%2B%2B20&oldid=1194515255"

C++23
C++23 is the informal name for the next version of the ISO/IEC 14882 standard for the C++ programming
language that will follow C++20. The final draft of this version is N4950.[1][2]

In February 2020, at the final meeting for C++20 in Prague, an overall plan for C++23 was adopted:[3][4]
planned features for C++23 were library support for coroutines, a modular standard library, executors, and
networking.

The first WG21 meeting focused on C++23 was intended to take place in Varna in early June 2020, but
was cancelled due to the COVID-19 pandemic,[5][6] as was the November 2020 meeting in New York[7][6]
and the February 2021 meeting in Kona, Hawaii.[7] All meetings until November 2022 were virtual while
the November 2022 meeting until the final meeting on February 2023 was hybrid.[7] The standard was
technically finalized by WG21 at the hybrid meeting in Issaquah in February 2023.[8]

Modern "Hello, world" Example

After many library changes applied to the working draft, the new "Hello, world" program will be:

import std;

int main()
{
std::println("Hello, world!");
}

Features
Changes that have been accepted into C++23 include:

Language
explicit this object parameter[9]
if consteval[10]
multidimensional subscript operator[11]
static call and subscript operators and static lambdas[12][13]
simplifying implicit move[14]
auto(x) and auto{x}[15]
new preprocessor directives:

#elifdef and #elifndef[16]

#warning[17]
extending the lifetime of some temporaries in range-based for loop[18]
new standard attribute [[assume(expression)]][19]
 class template argument deduction from inherited constructors[20]
labels at the end of the compound statement[21]
alias declarations in init-statements[22]
literal suffixes for std::size_t and the corresponding signed type[23]
extended floating-point types with literals (conditionally supported)[24]
optional () from nullary lambda expressions[25]
attributes on lambda expressions[26]
constexpr changes:

non-literal variables, labels, and gotos in constexpr functions[27]

allowing static and thread_local variables that are usable in constant
expressions in constexpr functions[28]
constexpr function does not need its return type and parameter types to be literal type
it is now possible to write a constexpr function for which no invocation satisfies the
requirements of a core constant expression[29]
narrowing contextual conversions to bool in static_assert and if constexpr[30]
trimming whitespaces before line splicing[31]
make declaration order layout mandated[32]
delimited escape sequences[33]
named universal character escapes[34]
text encoding changes:

support for UTF-8 as a portable source file encoding[35]

consistent character literal encoding[36]
character sets and encodings[37]

Library

Standard Library Module Support

standard library modules std and std.compat[38]

Coroutine Library Support

synchronous coroutine std::generator for ranges[39]

General Utilities Support

result type std::expected[40]

monadic operations for std::optional[41] and std::expected[42]
utility function std::to_underlying to get the underlying value of enum[43]
move-only callable wrapper std::move_only_function[44]
std::forward_like[45]
 std::invoke_r[46]
std::bind_back[47]
std::byteswap[48]
std::unreachable: a function to mark unreachable code[49]
made std::tuple compatible with other tuple-like objects[50]
std::basic_common_reference specialization for std::reference_wrapper
yielding reference types[51]
adding default arguments for std::pair's forwarding constructor[52]

Compile-time Support

constexpr support for:

std::type_info::operator==[53]
std::bitset[54]
std::unique_ptr[55]
for some <cmath> functions[56]
for integral overloads of std::to_chars and std::from_chars[57]
metaprogramming utilities:

type traits std::is_scoped_enum,[58] std::is_implicit_lifetime,[59]

std::reference_constructs_from_temporary, and
std::reference_converts_from_temporary.[60]
adding move-only types support for comparison concepts[61]

Iterators, Ranges, and Algorithm Support

new range conversion function std::ranges::to[62]

new constrained ranges algorithm:
std::ranges::starts_with
std::ranges::ends_with[63]
std::ranges::contains
std::ranges::contains_subrange[64]
std::ranges::find_last and other variants[65]
rangified versions of iota, shift_left, and shift_right[66]
range fold algorithms[67]
new std::ranges::range_adaptor_closure, a helper for defining user-defined
range adaptor closures[47]
new range adaptors:
std::views::zip and other variants
std::views::adjacent and other variants[68]
std::views::join_with[69]
std::views::slide
 std::views::chunk[70]
std::views::chunk_by[71]
std::views::as_rvalue[72]
std::views::as_const[73]
std::views::repeat[74]
std::views::stride[75]
std::views::cartesian_product[76]
std::views::enumerate[77]
rectifying constant iterators, sentinels, and ranges, that is, std::ranges::cbegin and
other similar utilities returning constant iterators should be fully guaranteed even for shallow-
const views (such as std::span)[73]
ranges iterators as inputs to non-ranges algorithms[78]
relaxing range adaptors to allow for move only types[79]
making multi-param constructors of some views explicit[80]

Memory Management Support

std::out_ptr and std::inout_ptr for C interoperability[81]

std::allocate_at_least and std::allocator::allocate_at_least[82]
explicit lifetime management function std::start_lifetime_as for implicit-lifetime
types[83]
disallowing user specialization of std::allocator_traits[84]

String and Text Processing Support

new member functions and changes in string types:
std::basic_string_view::contains and
std::basic_string::contains[85]
disabling construction from nullptr for std::basic_string and
std::basic_string_view[86]
explicit range constructor for std::basic_string_view[87]
std::basic_string::resize_and_overwrite[88]
rvalue reference overload of std::basic_string::substr for efficient slicing[89]
 formatting ranges, tuples, escaped presentation of characters and strings,
std::thread::id, and stacktraces.[90][91][92]

Diagnostic Support

stacktrace library[93]

I/O Support
formatted output functions std::print and std::println from new header
<print>[94]
spanstream library (std::span-based string stream) from new header <spanstream>[95]
a support for exclusive mode in std::fstreams[96]
std::basic_ostream::operator<<(const volatile void*)[97]

Containers Support

multidimensional-span std::mdspan[98][99][100][101]
constructability and assignability of containers from other compatible ranges[62]
flat set and flat map container adapters[102][103]
non-deduction context for allocators in container deduction guides[104]
heterogeneous erasure overloads for associative containers[105]
allowing iterator pair construction in stack and queue[106]
requiring std::span and std::basic_string_view to be trivially copyable[107]

C-Compatibility Support

new header <stdatomic.h>[108]

Language defect reports

C++ identifier syntax using Unicode Standard Annex 31[109]
allowing duplicate attributes[110]
changing scope of lambda trailing return type[111]
making overloaded comparison operators less breaking change[112]
undeprecating volatile compound assignments[113][114]
fixing the compatibility and portability of char8_t[115]
relaxing requirements on wchar_t to match existing practices[116]
allowing some pointers and references of this or unknown origin in constant
expressions[117]
introduction of immediate-escalating functions promoted to immediate functions[118]
 allowing static_assert(false) in uninstantiated template contexts

Library defect reports

changes in ranges library:

conditionally borrowed ranges[119]

repairing input range adaptors and std::counted_iterator[120]
relaxing the constraint on std::ranges::join_view[121]
renamed std::ranges::split_view to std::ranges::lazy_split_view
and new split_view[122]
removed std::default_initializable constraint from concept
std::ranges::view[123]
view with ownership and new std::ranges::owning_view[124]
fixed std::ranges::istream_view[125]
changes in text formatting library:

std::basic_format_string[126]
compile-time format string checks
reducing binary code size of std::format_to[127]
fixing locale handling in chrono formatters[128]
improving width estimation[129] and fill character allowances of std::format[130]
use of forwarding references in format arguments to allow non-const-formattable
types[131]
fully constexpr std::variant and std::optional[132]
supporting types derived from std::variant in std::visit[133]

Removed features and deprecation

Removed features:

Garbage Collection Support and Reachability-Based Leak Detection. It was added to the
standard since C++11 but no compilers support this feature until C++23.[134]
Mixed wide string literal concatenation.[135]
Non-encodable wide character literals and multicharacter wide character literals.[136]

Deprecated features:

std::aligned_storage and std::aligned_union[137]

std::numeric_limits::has_denorm[138]

Reverted deprecated features:

Use of comma operator in subscript expressions was no longer deprecated but the
semantics has been changed to support overloadable n-adic operator[].
 C headers (The corresponding <*.h> headers for compatibility with C)

Published as Technical Specifications

Concurrency TS v2[139]

Compiler support
GCC added partial, experimental C++23 support in 2021 in version 11 through the option -
std=c++2b or -std=c++23 It also has an option to enable GNU extensions in addition to
the experimental C++23 support, -std=gnu++2b. [140]

History
In the absence of face-to-face WG21 meetings, the following changes were applied after several virtual
WG21 meetings, where they were approved by straw polls.

The following were added after the virtual WG21 meeting of 9 November 2020, where they were approved
by straw polls:[141]

Literal suffixes for std::size_t and the corresponding signed type

A member function contains for std::basic_string and
std::basic_string_view, to check whether or not the string contains a given substring
or character
A stacktrace library (<stacktrace>), based on Boost.Stacktrace
A type trait std::is_scoped_enum
The header <stdatomic.h>, for interoperability with C atomics

After the virtual WG21 meeting of 22 February 2021, following features are added where they were
approved by straw polls:[142]

Removing unnecessary empty parameter list () from lambda expressions.

Repairing input range adaptors and counted_iterator.
Relax the requirements for time_point::clock.[143]
std::visit for classes that are derived from std::variant.
Locks lock lockables.[144]
Conditionally borrowed ranges.
std::to_underlying.

After the summer 2021 ISO C++ standards plenary virtual meeting of June 2021, new features and defect
reports were approved by straw polls:[145]

Consteval if (if consteval).

Narrowing contextual conversions to bool.
Allowing duplicate attributes.
std::span-based string-stream (<spanstream>).
std::out_ptr() and std::inout_ptr().
 constexpr for std::optional, std::variant, and
std::type_info::operator==.
Iterators pair constructors for std::stack (stack) and std::queue (queue).
Few changes of the ranges library:
Generalized starts_with and ends_with for arbitrary ranges.
Renamed split_view to lazy_split_view and new split_view.
Relaxing the constraint on join_view.
Removing default_initializable constraint from concept view.
Range constructor for std::basic_string_view.
Prohibiting std::basic_string and std::basic_string_view construction from
nullptr.
std::invoke_r.
Improvements on std::format.
Adding default arguments for std::pair's forwarding constructor.

After the autumn 2021 ISO C++ standards plenary virtual meeting of October 2021, new features and
defect reports were approved by straw polls:[146]

Non-literal variables, labels, and gotos in constexpr functions, but still ill-formed to
evaluate them at compile-time.
Explicit this object parameter.
Changes on character sets and encodings.
New preprocessors: #elifdef and #elifndef. Both directives were added to C23 (C
language update) and GCC 12.[147]
Allowing alias declarations in init-statement.
Overloading multidimensional subscript operator (e.g. arr[1, 2]).
Decay copy in language: auto(x) or auto{x}.
Changes in text formatting library:
Fixing locale handling in chrono formatters.
Use of forwarding references in format arguments to allow std::generator-like types.
Addition of type alias std::pmr::stacktrace which is equivalent to
std::basic_stacktrace<std::pmr::polymorphic_allocator>.[148]
Changes in ranges library:
Refined definition of a view.
Replacing function template std::ranges::istream_view with alias templates
std::ranges::istream_view, std::ranges::wistream_view, and
customization point object std::views::istream.
zip range adaptor family:
zip_view
zip_transform_view
adjacent_view (and std::views::pairwise being equivalent to
std::views::adjacent<2>)
adjacent_transform_view (and std::views::pairwise_transform
being equivalent to std::views::adjacent_transform<2>)
 std::move_only_function.
Monadic operations for std::optional.
Member function template std::basic_string::resize_and_overwrite.
Printing volatile pointers (volatile T*).
std::byteswap.
Heterogeneous erasure overloads for associative containers.
Every specialization of std::span and std::basic_string_view is trivially copyable.
Adding conditional noexcept specifications to std::exchange.[149]
Revamped specification and use of integer-class types.[150]
Clarify C headers. "The headers are not useful in code that is only required to be valid C++.
Therefore, the C headers should be provided by the C++ standard library as a fully-
supported, not deprecated part, but they should also be discouraged for use in code that is
not polyglot interoperability code. [..] This proposal makes the C headers no longer
deprecated, so there is no formal threat of future removal. The effective discouragement to
use the C headers in pure C++ code is now spelled out explicitly as normative
discouragement."[151]

After the virtual WG21 meeting of 7 February 2022, the following features are added where they were
approved by straw polls:[152]

Allowed attributes on the function call operator of a lambda

std::expected
constexpr for cmath and cstdlib
Function to mark unreachable code
ranges::to
A type trait to detect reference binding to temporary
Making std::unique_ptr constexpr
Pipe support for user-defined range adaptors
ranges::iota, ranges::shift_left and ranges::shift_right
views::join_with
Windowing range adaptors: views::chunk and views::slide
views::chunk_by

After the virtual WG21 meeting of 25 July 2022, the following features and defect reports are added where
they were approved by straw polls:[153]

Made rewriting equality in expressions less of a breaking change.

Reverted the deprecation of bitwise assignment to volatile variables.
Added the #warning preprocessor directive.
Removed non-encodable wide character literals and multicharacter wide character literals.
Allowed labels to appear at the end of compound statements.
Added escape sequences delimited with curly braces for octal and hexadecimal numbers
and universal character names.
Allowed constexpr functions to never be constant expressions.
Simplified some implicit move rules from C++20 and allowed implicit move when returning
an rvalue reference.
 Add a way to specify unicode characters by name. For example, U'\N{LATIN CAPITAL
LETTER A WITH MACRON}' // Equivalent to U'\u0100'
Allowed operator() and lambdas to be static.
Allowed the this pointer and references of unknown origin to appear in constant
expressions.
Allowed implementations to define extended floating-point types in addition to the three
standard floating-point types. Added the type aliases std::float16_t,
std::float32_t, std::float64_t, std::float128_t, std::bfloat16_t for
these extended types accessible through the header <stdfloat>, their corresponding
literal suffixes f16 f32 f64 f128 bf16or F16 F32 F64 F128 BF16 and added overloads
to various standard library functions that take floats as arguments.
Added the [[assume(expression)]] attribute which allows the compiler to assume the
provided expression is true to allow optimizations.
Made support for UTF-8 source files mandatory, providing a portable encoding for source
files.
Allowed arrays of char and unsigned char to be initialized with UTF-8 string literals.
Removed the requirement that wchar_t can encode all characters of the extended
character set, in effect allowing UTF-16 to be used for wide string literals.
Added std::mdspan, a multidimensional array view analogous to std::span.
flat_map and flat_set were added to the standard library.
Added the std::print and std::println functions for printing formatted text to stdout.
Provide the named modules std and std.compat for importing the standard library.
Added support for exclusive mode fstreams, analogous to the "x" flag in fopen.
Allowed std::format to handle ranges, tuples, and other containers.
Added std::forward_like.
Made std::string::substr use move semantics.
Added std::generator which implements a coroutine generator that models
std::ranges::input_range
views::cartesian_product, views::repeat, views::stride,
views::as_const, views::as_rvalue.
Added new algorithms: ranges::find_last, ranges::contains, and ranges fold
algorithms.
Made std::tuple compatible with other tuple-like objects.
Explicit lifetime management for implicit-lifetime types.
Made std::bitset and integral overloads of std::to_chars and std::from_chars
constexpr-compatible.
Adding move-only types support for comparison concepts.
Ranges iterators as inputs to non-ranges algorithms.
Relaxing range adaptors to allow for move-only types.

After the hybrid WG21 meeting of 7 November 2022, the following features and defect reports are added
where they were approved by straw polls:[154]

Allowed operator[] to be static.

Allowed static and thread_local variables to appear in constexpr functions if they
are usable in constant expressions.
 consteval propagates upwards, that is, certain existing constexpr functions become
consteval functions when those functions can already only be invoked during compile
time.
Extended the lifetime of temporaries that appear in the for-range-initializer of a range-based
for loop to cover the entire loop.
Reverted the deprecation of (all, not just bitwise) compound assignment to volatile
variables.
Monadic functions for std::expected.
Synchronize the output of std::print with the underlying stream if the native Unicode API
is used.[155]

After the final hybrid WG21 meeting of 6-11 February 2023, the following features and defect reports are
added where they were approved by straw polls:[156]

Referencing the Unicode Standard.[157]

Stashing stashing iterators for proper flattening.[158]
views::enumerate
making multi-param constructors of views explicit
relaxing ranges just a smidge
escaping improvements in std::format
improving std::format's width estimation
std::format fill character allowances
formatting thread::id and stacktrace
A type trait std::is_implicit_lifetime
std::common_reference_t of std::reference_wrapper should be a reference
type
disallowing user specialization of std::allocator_traits
std::pmr::generator
deprecating std::numeric_limits::has_denorm
std::barrier's phase completion guarantees

References
1. "Working Draft, Standard for Programming Language C++" (https://open-std.org/JTC1/SC22/
WG21/docs/papers/2023/n4950.pdf) (PDF). 2023-05-10.
2. "N4951 Editors' Report: Programming Languages - C++" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2023/n4951.html). 2023-05-10. Archived (https://web.archive.org/web/2
0230605040956/https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4951.html)
from the original on 2023-06-05.
3. Dusíková, Hana (2019-11-06). "N4817: 2020 Prague Meeting Invitation and Information" (htt
p://open-std.org/JTC1/SC22/WG21/docs/papers/2019/n4817.pdf) (PDF). Archived (https://we
b.archive.org/web/20191229102449/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
19/n4817.pdf) (PDF) from the original on 2019-12-29. Retrieved 2020-02-13.
4. Voutilainen, Ville (2019-11-25). "To boldly suggest an overall plan for C++23" (http://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2019/p0592r4.html). www.open-std.org. Archived (htt
ps://web.archive.org/web/20191224230450/http://www.open-std.org/jtc1/sc22/wg21/docs/pa
pers/2019/p0592r4.html) from the original on 2019-12-24. Retrieved 2020-02-13.
 5. "P2145R0: Evolving C++ Remotely" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
020/p2145r0.html). www.open-std.org.
6. Sutter, Herb (29 July 2020). "Business Plan and Convener's Report: ISO/IEC
JTC1/SC22/WG21 (C++)" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4862.
pdf) (PDF).
7. "Upcoming Meetings, Past Meetings : Standard C++" (https://isocpp.org/std/meetings-and-pa
rticipation/upcoming-meetings). isocpp.org.
8. "C++23 "Pandemic Edition" is complete (Trip report: Winter ISO C++ standards meeting,
Issaquah, WA, USA)" (https://herbsutter.com/2023/02/13/c23-pandemic-edition-is-complete-tr
ip-report-winter-iso-c-standards-meeting-issaquah-wa-usa/). herbsutter.com. 13 February
2023.
9. Gašper Ažman; Sy Brand; Ben Deane; Barry Revzin (2021-07-12). "Deducing this" (http://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0847r7.html).
10. Barry Revzin; Richard Smith; Andrew Sutton; Daveed Vandevoorde (2021-03-22). "if
consteval" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1938r3.html).
11. Mark Hoemmen; Daisy Hollman; Corentin Jabot; Isabella Muerte; Christian Trott (2021-09-
14). "Multidimensional subscript operator" (http://www.open-std.org/jtc1/sc22/wg21/docs/pap
ers/2021/p2128r6.pdf) (PDF).
12. "static operator()" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1169r4.html).
2022-04-08.
13. "static operator[]" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2589r1.pdf)
(PDF). 2022-11-11.
14. "Simpler implicit move" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r
3.html). 2022-03-23.
15. Zhihao Yuan (2021-07-12). "auto(x): decay-copy in the language" (http://www.open-std.org/jt
c1/sc22/wg21/docs/papers/2021/p0849r8.html).
16. Melanie Blower (2021-04-30). "Add support for preprocessing directives elifdef and elifndef"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2334r1.pdf) (PDF).
17. Aaron Ballman (2022-01-13). "Support for #warning" (https://www.open-std.org/jtc1/sc22/wg
21/docs/papers/2022/p2437r1.pdf) (PDF).
18. "Wording for P2644R1 Fix for Range-based for Loop" (https://www.open-std.org/jtc1/sc22/wg
21/docs/papers/2022/p2718r0.html). 2022-11-11.
19. "Portable assumptions" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1774r
8.pdf) (PDF). 2022-04-22.
20. Timur Doumler (2022-05-20). "Wording for class template argument deduction from inherited
constructors" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2582r1.pdf)
(PDF).
21. "Labels at the end of compound statements (C compatibility)" (https://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2022/p2324r2.pdf) (PDF). 2022-01-13.
22. Jens Maurer (2021-04-13). "Extend init-statement to allow alias-declaration" (http://www.ope
n-std.org/jtc1/sc22/wg21/docs/papers/2021/p2360r0.html).
23. JeanHeyd Meneide; Rein Halbersma (2019-11-24). "Literal Suffix for (signed) size_t" (http://
www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0330r8.html).
24. "Extended floating-point types and standard names" (https://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2022/p1467r9.html). 2022-04-22.
25. Alex Christensen; JF Bastien (2020-12-11). "P1102R2: Down with ()!" (http://www.open-std.o
rg/jtc1/sc22/wg21/docs/papers/2020/p1102r2.html).
26. "Attributes on Lambda-Expressions" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
021/p2173r1.pdf) (PDF).
27. Ville Voutilainen (2021-07-12). "Non-literal variables (and labels and gotos) in constexpr
functions" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2242r3.html).
28. "Permitting static constexpr variables in constexpr functions" (https://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2022/p2647r1.html). 2022-11-07.
29. "Relaxing some constexpr restrictions" (https://www.open-std.org/jtc1/sc22/wg21/docs/paper
s/2022/p2448r2.html). 2022-01-27.
30. Andrzej Krzemieński (2021-04-12). "Narrowing contextual conversions to bool" (http://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2021/p1401r5.html).
31. Corentin Jabot (2021-04-13). "Trimming whitespaces before line splicing" (https://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2021/p2223r2.pdf) (PDF).
32. Pal Balog (2021-04-02). "Make declaration order layout mandated" (https://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2021/p1847r4.pdf) (PDF).
33. "Delimited escape sequences" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/
p2290r3.pdf) (PDF). 2022-02-25.
34. "Named universal character escapes" (https://www.open-std.org/jtc1/sc22/wg21/docs/paper
s/2022/p2071r2.html). 2022-03-25.
35. "Support for UTF-8 as a portable source file encoding" (https://www.open-std.org/jtc1/sc22/w
g21/docs/papers/2022/p2295r6.pdf) (PDF). 2022-07-01.
36. Corentin Jabot (2021-09-14). "Consistent character literal encoding" (http://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2021/p2316r2.pdf) (PDF).
37. Jens Maurer (2021-09-21). "Character sets and encodings" (https://isocpp.org/files/papers/P
2314R4.html).
38. "Standard Library Modules std and std.compat" (https://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2022/p2465r3.pdf) (PDF).
39. "(std::generator: Synchronous Coroutine Generator for Ranges)" (https://www.open-std.org/jt
c1/sc22/wg21/docs/papers/2022/p2502r2.pdf) (PDF).
40. Vicente Botet; JF Bastien; Jonathan Wakely (2022-01-07). "std::expected" (http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2022/p0323r12.html).
41. Sy Brand (2021-04-27). "Monadic operations for std::optional" (http://www.open-std.org/jtc1/s
c22/wg21/docs/papers/2021/p0798r6.html).
42. Jeff Garland (2022-09-28). "P2505R5 Monadic Functions for std::expected" (https://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2505r5.html).
43. JeanHeyd Meneide (2021-01-22). "std::to_underlying for enumerations" (http://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2021/p1682r3.html).
44. Matt Calabrese; Ryan McDougall (2021-07-09). "move_only_function" (http://www.open-std.
org/jtc1/sc22/wg21/docs/papers/2021/p0288r9.html).
45. Gašper Ažman (2022-05-13). "std::forward_like" (https://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2022/p2445r1.pdf) (PDF).
46. Zhihao Yuan (2020-04-29). "invoke_r" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2021/p2136r3.html).
47. Barry Revzin (2021-12-17). "Pipe support for user-defined range adaptors" (http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2021/p2387r3.html).
48. Isabella Muerte; Corentin Jabot (2021-09-17). "Byteswapping for fun&&nuf" (https://isocpp.or
g/files/papers/P1272R4.html).
49. Melissa Mears; Jens Maurer (2021-10-15). "Function to mark unreachable code" (http://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0627r6.pdf) (PDF).
50. Corentin Jabot (2022-07-15). "Compatibility between tuple, pair and tuple-like objects" (http
s://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2165r4.pdf) (PDF).
51. Hui Xie; S. Levent Yilmaz; Tim Song (2023-02-07). "common_reference_t of
reference_wrapper Should Be a Reference Type" (https://www.open-std.org/jtc1/sc22/wg21/
docs/papers/2023/p2655r3.html).
52. "Wording for P2644R1 Fix for Range-based for Loop" (https://www.open-std.org/jtc1/sc22/wg
21/docs/papers/2022/p2718r0.html). 2022-11-11.
53. Peter Dimov (2021-05-01). "Making std::type_info::operator== constexpr" (http://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2021/p1328r1.html).
54. Daniil Goncharov (2022-06-25). "A more constexpr bitset" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2022/p2417r2.pdf) (PDF).
55. Andreas Fertig (2021-11-06). "Making std::unique_ptr constexpr" (http://www.open-std.org/jtc
1/sc22/wg21/docs/papers/2021/p2273r3.pdf) (PDF).
56. Edward J. Rosten; Oliver J. Rosten (2021-11-12). "constexpr for <cmath> and <cstdlib>" (htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0533r9.pdf) (PDF).
57. Daniil Goncharov; Alexander Karaev (2021-09-18). "Add Constexpr Modifiers to Functions
to_chars and from_chars for Integral Types in <charconv> Header" (https://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2021/p2291r3.pdf) (PDF).
58. Juan Alday (2020-10-12). "A proposal for a type trait to detect scoped enumerations" (http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1048r1.pdf) (PDF).
59. Timur Doumler; Vittorio Romeo (2022-11-11). "A trait for implicit lifetime types" (https://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2022/p2674r1.pdf) (PDF).
60. Tim Song (2021-10-13). "A type trait to detect reference binding to temporary" (http://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2021/p2255r2.html).
61. Justin Bassett (2022-07-02). "Move-only types for equality_comparable_with,
totally_ordered_with, and three_way_comparable_with" (https://www.open-std.org/jtc1/sc22/
wg21/docs/papers/2022/p2404r3.pdf) (PDF).
62. Corentin Jabot; Eric Niebler; Casey Carter (2022-01-21). "Conversions from ranges to
containers" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1206r7.pdf) (PDF).
63. Christopher Di Bella (2021-02-19). "starts_with and ends_with" (http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2021/p1659r3.html).
64. Christopher Di Bella (2021-04-16). "std::ranges::contains" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2022/p2302r4.html).
65. Zach Laine (2022-06-17). "find_last" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
022/p1223r5.pdf) (PDF).
66. Tim Song (2021-12-05). "ranges::iota, ranges::shift_left, and ranges::shift_right" (http://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html).
67. Barry Revzin (2022-04-22). "ranges::fold" (https://www.open-std.org/jtc1/sc22/wg21/docs/pap
ers/2022/p2322r6.html).
68. Tim Song (2021-06-11). "zip" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23
21r2.html).
69. Barry Revzin (2022-01-28). "views::join_with" (http://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2022/p2441r2.html).
70. Tim Song (2021-12-05). "Windowing range adaptors: views::chunk and views::slide" (http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2442r1.html).
71. Tim Song (2021-11-19). "views::chunk_by" (http://www.open-std.org/jtc1/sc22/wg21/docs/pa
pers/2021/p2443r1.html).
72. Barry Revzin (2022-02-14). "views::as_rvalue" (https://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2022/p2446r2.html).
73. Barry Revzin (2022-06-17). "cbegin should always return a constant iterator" (https://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2022/p2278r4.html).
74. Michał Dominiak (2022-07-13). "views::repeat" (https://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2022/p2474r2.html).
75. Christopher Di Bella; Tim Song (2022-07-08). "stride_view" (https://www.open-std.org/jtc1/sc
22/wg21/docs/papers/2022/p1899r3.html).
76. Sy Brand; Michał Dominiak (2022-07-13). "views::cartesian_product" (https://www.open-std.
org/jtc1/sc22/wg21/docs/papers/2022/p2374r4.html).
77. Corentin Jabot (2022-12-07). "views::enumerate" (https://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2023/p2164r9.pdf) (PDF).
78. David Olsen (2022-04-22). "Ranges iterators as inputs to non-Ranges algorithms" (https://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2408r5.html).
79. Michał Dominiak (2022-07-13). "Relaxing range adaptors to allow for move only types" (http
s://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2494r2.html).
80. Ville Voutilainen (2022-11-12). "Making multi-param constructors of views explicit" (https://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2711r1.html).
81. JeanHeyd Meneide; Todor Buyukliev; Isabella Muerte (2021-04-15). "out_ptr - a scalable
output pointer abstraction" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1132
r7.html).
82. Jonathan Wakely; Chris Kennelly (2021-01-22). "Providing size feedback in the Allocator
interface" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0401r6.html).
83. Timur Doumler; Richard Smith (2022-07-15). "Explicit lifetime management" (https://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2022/p2590r2.pdf) (PDF).
84. Pablo Halpern (2023-02-08). "Disallow User Specialization of allocator_traits" (https://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2023/p2652r2.html).
85. Wim Leflere; Paul Fee (2020-06-13). "string contains function" (http://www.open-std.org/jtc1/s
c22/wg21/docs/papers/2020/p1679r3.html).
86. Yuriy Chernyshov (2020-09-06). "A Proposal to Prohibit std::basic_string and
std::basic_string_view construction from nullptr" (http://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2020/p2166r1.html).
87. Corentin Jabot (2021-03-17). "Range constructor forstd::string_view 2: Constrain Harder" (htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1989r2.pdf) (PDF).
88. Chris Kennelly; Mark Zeren (2021-09-14). "basic_string::resize_and_overwrite" (http://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r10.html).
89. "std::string::substr() &&" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2438r
2.html).
90. "Formatting Ranges" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2286r8.ht
ml). 16 May 2022.
91. Barry Revzin (2022-07-15). "Improve default container formatting" (https://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2022/p2585r1.html).
92. Corentin Jabot; Victor Zverovich (2023-02-09). "Formatting thread::id and stacktrace" (https://
www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2693r1.pdf) (PDF).
93. Alexey Gorgurov; Antony Polukhin (2020-09-16). "A Proposal to add stacktrace library" (htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0881r7.html).
94. "Formatted output" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2093r14.ht
ml).
95. Peter Sommerlad (2021-02-26). "A strstream replacement using span<charT> as buffer" (htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0448r4.pdf) (PDF).
 96. "Support exclusive mode for fstreams" (https://www.open-std.org/jtc1/sc22/wg21/docs/paper
s/2022/p2467r1.html).
97. Bryce Adelstein Lelbach (2021-09-25). "Printing volatile Pointers" (https://isocpp.org/files/pa
pers/P1147R1.html).
98. "MDSPAN" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0009r18.html). 13
July 2022.
99. "index_type & size_type in mdspan" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2
022/p2599r2.pdf) (PDF).
100. "mdspan: rename pointer and contiguous" (https://www.open-std.org/jtc1/sc22/wg21/d
ocs/papers/2022/p2604r0.html). 15 June 2022.
101. "Add the missing empty to mdspan" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2022/p2613r1.html).
102. "A Standard flat_map" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0429r9.
pdf) (PDF).
103. "A Standard flat_set" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1222r4.p
df) (PDF).
104. Arthur O'Dwyer; Mike Spertus (2021-03-14). "Stop overconstraining allocators in container
deduction guides" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1518r2.htm
l).
105. Konstantin Boyarinov; Sergey Vinogradov; Ruslan Arutyunyan (2020-12-15).
"Heterogeneous erasure overloads for associative containers" (http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2020/p2077r2.html).
106. Corentin Jabot (2021-03-05). "Iterators pair constructors for stack and queue" (http://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2021/p1425r4.pdf) (PDF).
107. Nevin Liber (2021-03-19). "Require span & basic_string_view to be TriviallyCopyable" (htt
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2251r1.pdf) (PDF).
108. Hans-J. Boehm (2020-10-23). "P0943R6: Support C atomics in C++" (http://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2020/p0943r6.html).
109. Steve Downey; Zach Laine; Tom Honermann; Peter Bindels; Jens Maurer (2021-04-12).
"C++ Identifier Syntax using Unicode Standard Annex 31" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2021/p1949r7.html).
110. Erich Keane (2020-07-02). "Allow Duplicate Attributes" (http://www.open-std.org/jtc1/sc22/wg
21/docs/papers/2020/p2156r1.pdf) (PDF).
111. Barry Revzin (2021-09-14). "Change scope of lambda trailing-return-type" (https://www.open
-std.org/jtc1/sc22/wg21/docs/papers/2021/p2036r3.html).
112. "The Equality Operator You Are Looking For" (https://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2022/p2468r2.html). 2022-01-13.
113. "De-deprecating volatile compound operations" (https://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2021/p2327r1.pdf) (PDF).
114. "Core Language Working Group NB comment resolutions for the November, 2022 meeting :
2654. Un-deprecation of compound volatile assignments" (https://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2022/p2710r0.html#2654).
115. "char8_t Compatibility and Portability Fix" (https://www.open-std.org/jtc1/sc22/wg21/docs/
papers/2022/p2513r3.html). 2022-06-17.
116. "Relax requirements on wchar_t to match existing practices" (https://www.open-std.org/jtc
1/sc22/wg21/docs/papers/2022/p2460r2.pdf) (PDF). 2022-07-15.
117. "Using unknown pointers and references in constant expressions" (https://www.open-std.org/
jtc1/sc22/wg21/docs/papers/2022/p2280r4.html). 8 April 2022.
118. "consteval needs to propagate up" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/
2022/p2564r3.html). 2022-11-11.
119. Barry Revzin (2020-02-19). "Conditionally borrowed ranges" (http://www.open-std.org/jtc1/sc
22/wg21/docs/papers/2020/p2017r1.html).
120. Tim Song (2021-01-12). "Repairing input range adaptors and counted_iterator" (http://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2021/p2259r1.html).
121. Tim Song (2021-05-06). "join_view should join all views of ranges" (http://www.open-std.org/j
tc1/sc22/wg21/docs/papers/2021/p2328r1.html).
122. Barry Revzin (2021-03-05). "Superior String Splitting" (http://www.open-std.org/jtc1/sc22/wg2
1/docs/papers/2021/p2210r2.html).
123. Barry Revzin (2021-05-14). "Views should not be required to be default constructible" (http://
www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2325r3.html).
124. Barry Revzin; Tim Song (2021-08-15). "What is a view?" (http://www.open-std.org/jtc1/sc22/
wg21/docs/papers/2021/p2415r1.html).
125. Nicolai Josuttis (2021-09-24). "Fix istream_view" (https://isocpp.org/files/papers/P2432R1.pd
f) (PDF).
126. Barry Revzin (2022-01-18). "Expose std::basic-format-string<charT, Args...>" (https://www.op
en-std.org/jtc1/sc22/wg21/docs/papers/2022/p2508r1.html).
127. Victor Zverovich (2021-02-05). "std::format improvements" (http://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2021/p2216r3.html).
128. Victor Zverovich; Corentin Jabot (2021-09-11). "Fixing locale handling in chrono formatters"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2372r3.html).
129. Corentin Jabot (2022-12-02). "format's width estimation is too approximate and not forward
compatible" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2675r1.pdf) (PDF).
130. Tom Honermann (2023-02-08). "std::format() fill character allowances" (https://www.open-std.
org/jtc1/sc22/wg21/docs/papers/2023/p2572r1.html).
131. Victor Zverovich (2021-09-24). "Add support for std::generator-like types to std::format" (http
s://isocpp.org/files/papers/P2418R2.html).
132. Barry Revzin (2021-02-11). "Missing constexpr in std::optional and std::variant" (http://www.o
pen-std.org/jtc1/sc22/wg21/docs/papers/2021/p2231r1.html).
133. Barry Revzin (2020-10-30). "Inheriting from std::variant" (http://www.open-std.org/jtc1/sc22/w
g21/docs/papers/2021/p2162r2.html).
134. JF Bastien; Alisdair Meredith (2021-04-16). "Removing Garbage Collection Support" (http://w
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2186r2.html).
135. Jens Maurer (2021-04-12). "Mixed string literal concatenation" (https://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2021/p2201r1.html).
136. "Remove non-encodable wide character literals and multicharacter wide character literals"
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2362r3.pdf) (PDF).
137. CJ Johnson (2021-11-22). "Deprecate std::aligned_storage and std::aligned_union" (https://
www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1413r3.pdf) (PDF).
138. Matthias Kretz (2022-11-08). "Deprecate numeric_limits::has_denorm" (https://www.open-st
d.org/jtc1/sc22/wg21/docs/papers/2022/p2614r2.pdf) (PDF).
139. "Programming Languages — Technical specification for C++ extensions for concurrency 2"
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4956.pdf) (PDF).
140. "C++ Standards Support in GCC - GNU Project" (https://gcc.gnu.org/projects/cxx-status.htm
l).
141. Ranns, Nina (2020-11-19). "WG21 2020-11 Virtual Meeting: Minutes of Meeting" (http://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4877.pdf) (PDF).
142. Ranns, Nina (2021-02-22). "WG21 2021-02 Virtual Meeting: Minutes of Meeting" (http://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4877.pdf) (PDF).
143. Alexey Dmitriev; Howard Hinnant (2020-10-22). "Relax Requirements for time_point::clock"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2212r2.html).
144. Tim Song (2020-11-13). "Locks lock lockables" (http://www.open-std.org/jtc1/sc22/wg21/doc
s/papers/2020/p2160r1.html).
145. Ranns, Nina (2021-06-07). "WG21 2021-06 Virtual Meeting Minutes of Meeting" (http://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2021/n4891.pdf) (PDF).
146. Ranns, Nina (2021-10-04). "WG21 2021-10 Virtual Meeting Minutes of Meeting" (https://isoc
pp.org/files/papers/N4898.pdf) (PDF).
147. "GCC 12 Adds Support For New #elifdef #elifndef Directives" (https://www.phoronix.com/ne
ws/GCC-12-elifdef-elifndef). phoronix. May 12, 2021. Archived (https://web.archive.org/web/2
0221227050002/https://www.phoronix.com/news/GCC-12-elifdef-elifndef) from the original
on December 27, 2022.
148. Steve Downey (2021-06-14). "Add a pmr alias for std::stacktrace" (http://www.open-std.org/jtc
1/sc22/wg21/docs/papers/2021/p2301r1.html).
149. Giuseppe D'Angelo (2021-06-28). "Add a conditional noexcept specification to
std::exchange" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2401r0.html).
150. Tim Song (2021-08-06). "Cleaning up integer-class types" (http://www.open-std.org/jtc1/sc2
2/wg21/docs/papers/2021/p2393r1.html).
151. Thomas Köppe (2021-06-11). "Clarifying the status of the "C headers" " (http://www.open-std.
org/jtc1/sc22/wg21/docs/papers/2021/p2340r1.html).
152. Ranns, Nina (2022-02-07). "WG21 2022-02 Virtual Meeting: Minutes of Meeting" (http://www.
open-std.org/jtc1/sc22/wg21/docs/papers/2022/n4907.pdf) (PDF).
153. Ranns, Nina (2022-08-09). "WG21 2022-07 Virtual Meeting: Minutes of Meeting" (https://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2022/n4916.pdf) (PDF).
154. Ranns, Nina (2022-12-05). "WG21 2022-11 Hybrid Meeting: Minutes of Meeting" (https://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4933.pdf) (PDF).
155. Victor Zverovich (2022-11-08). "Should the output of std::print to a terminal be synchronized
with the underlying stream?" (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2
539r4.html).
156. Ranns, Nina (2023-03-06). "WG21 2023-02 Hybrid Meeting: Minutes of Meeting" (https://ww
w.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4943.pdf) (PDF).
157. Corentin Jabot (2023-02-09). "Referencing The Unicode Standard" (https://www.open-std.or
g/jtc1/sc22/wg21/docs/papers/2023/p2736r2.pdf) (PDF).
158. Tim Song (2023-01-31). "Stashing stashing iterators for proper flattening" (https://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2023/p2770r0.html).

Retrieved from "https://en.wikipedia.org/w/index.php?title=C%2B%2B23&oldid=1199888622"