Wikipedia - User contributions [en]

C++11

2012-10-18T01:37:30Z

Code-structure: Natural order of definitions with constructors first.

{{ multiple issues
| refimprove = July 2012
| lead too short = July 2012
}}
{{manual|date=July 2012}}

'''C++11''' (formerly known as '''C++0x'''<ref>http://video.google.com/videoplay?docid=5262479012306588324#</ref>) is the most recent version of the standard of the [[C++ programming language]]. It was approved by [[International Organization for Standardization|ISO]] on 12 August 2011, replacing [[C++03]].<ref>{{cite web|title=We have an international standard: C++0x is unanimously approved|url=http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/| accessdate=12 August 2011}}</ref> The name is derived from the tradition of naming language versions by the year of the specification's publication.

C++11 includes several additions to the [[core language]] and extends the [[C++ standard library]], incorporating most of the [[C++ Technical Report 1]] (TR1) [[Library (computer science)|libraries]] — with the exception of the library of mathematical special functions.<ref>{{cite web|title=Bjarne Stroustrup: A C++0x overview|url=http://www.research.ibm.com/arl/seminar/media/stroustrup.pdf| accessdate=30 June 2011}}</ref> C++11 was published as ''ISO/IEC 14882:2011''<ref>{{ cite web | authorlink = ISO | title = ISO/IEC 14882:2011 | publisher = ISO | date = 2 September 2011 | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372 | accessdate =3 September 2011 }}</ref> in September 2011 and is available for a fee. The working draft most similar to the published C++11 standard is N3337, dated 12 January 2012;<ref>[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf]</ref> it has only editorial corrections from the C++11 standard.<ref>http://stackoverflow.com/a/4653479/734069</ref>

==Changes from the previous version of the standard==
The modifications for C++ involve both the core language and the standard library.

In the development of every utility of the 2011 standard, the committee has applied some directives:
* Maintain stability and compatibility with [[ISO/IEC 14882|C++98]] and possibly with [[C (programming language)|C]];
* Prefer introduction of new features through 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 to 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 (additional support required 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 they will always compose the majority of computer programmers, and because many beginners would not intend to extend their knowledge of {{nowrap|C++}}, limiting themselves to operate in the aspects of the language in which they are specialized.{{Ref|web-strou-brief}}

==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 [[Thread (computer science)|multithreading]] support, [[generic programming]] support, uniform initialization, and performance enhancements.

For the purposes of this article, core language features and changes are grouped into four general sections: run-time performance enhancements, build-time performance enhancements, usability enhancements, and new functionality. Some features could fall into multiple groups, but they are mentioned only in the group that primarily represents that feature.

==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 "[[value (computer science)|rvalue]]s", 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 <code>const T&</code> types; nevertheless, in some cases, temporaries could have been modified, a behavior that was even considered to be a useful loophole (for the former, see <ref name="Sutter_Alexandrescu">Sutter, Alexandrescu "C++ coding standards" #15</ref>). C++11 adds a new non-const reference type called an {{visible anchor|rvalue reference}}, identified by <code>T&&</code>. 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 unnecessary deep copies that can happen implicitly when objects are passed by value. To illustrate the issue, consider that a <code>std::vector<T></code> is, internally, a wrapper around a C-style array with a size. If a <code>std::vector<T></code> temporary is created or returned from a function, it can be stored only by creating a new <code>std::vector<T></code> and copying all of 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 [[b:More C++ Idioms/Move Constructor|{{visible anchor|move constructor}}]] of <code>std::vector<T></code> that takes an rvalue reference to a <code>std::vector<T></code> can copy the pointer to the internal C-style array out of the rvalue into the new <code>std::vector<T></code>, 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 a <code>std::vector<T></code> temporary does not need to be changed explicitly to <code>std::vector<T> &&</code> to invoke the move constructor, as temporaries are considered rvalues automatically. (However, if <code>std::vector<T></code> is a C++03 version without a move constructor, then the copy constructor will be invoked with a <code>const std::vector<T>&</code>, 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; in order to get an rvalue, the function template <code>std::move<T>()</code> 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|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 [http://en.cppreference.com/w/cpp/container/vector/emplace_back 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 <code>3+4</code> 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, there are a number of places where the C++ specification requires the use of 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 illegal:

<source lang="cpp">
int get_five() {return 5;}

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

This was not legal in C++03, because <code>get_five() + 7</code> is not a constant expression. A C++03 compiler has no way of knowing if <code>get_five()</code> 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 <code>constexpr</code>, which allows the user to guarantee that a function or object constructor is a compile-time constant.<ref>{{cite web|url=http://www.stroustrup.com/sac10-constexpr.pdf|title=General Constant Expressions for System Programming Languages, Proceedings SAC ’10 | author=Gabriel Dos Reis and Bjarne Stroustrup |date=22 March 2010}}</ref> The above example can be rewritten as follows:

<source lang="cpp">
constexpr int get_five() {return 5;}

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

This allows the compiler to understand, and verify, that <code>get_five</code> is a compile-time constant.

The use of <code>constexpr</code> on a function imposes some limitations 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.

Prior to 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 <code>constexpr</code> keyword:

<source lang="cpp">
constexpr double earth_gravitational_acceleration = 9.8;
constexpr double moon_gravitational_acceleration = earth_gravitational_acceleration / 6.0;
</source>

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

In order to construct constant expression data values from user-defined types, constructors can also be declared with <code>constexpr</code>. A <code>constexpr</code> constructor's function body can contain only declarations and null statements, and cannot declare variables or define types, as with a <code>constexpr</code> 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 <code>constexpr</code> constructors should usually also be defined as a <code>constexpr</code> constructor, in order 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 <code>constexpr</code>, so long as they meet the requirements for constexpr functions. This allows the compiler to copy classes 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 particular invocation, the result is not a constant expression.

===Modification to the definition of plain old data===
In C++03, a class or struct must follow a number of rules in order for it to be considered a [[Plain Old Data Structures|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. However, the definition in C++03 is unnecessarily strict{{citation needed|date=April 2012}} and there are good reasons{{clarify|date=April 2012}} for allowing more types to fit the POD definition{{citation needed|date=April 2012}}.

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 legal to copy data around via <code>memcpy</code>, 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:

# Has a trivial default constructor. This may use the [[#Explicitly defaulted and deleted special member functions|default constructor syntax]] (<code>SomeConstructor() = default;</code>).
# Has trivial copy and move constructors, which may use the default syntax.
# Has trivial copy and move assignment operators, which may use the default syntax.
# 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 that all of the non-static data members 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:

# It has no virtual functions
# It has no virtual base classes
# All its non-static data members have the same access control (public, private, protected)
# All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
# The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
# 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 interop with C. Similarly, a class with public and private non-static data members would not be standard-layout, but it would be trivial and thus <code>memcpy</code>-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:

<source lang="cpp">
template class std::vector<MyClass>;
</source>

C++11 now provides this syntax:

<source lang="cpp">
extern template class std::vector<MyClass>;
</source>

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 curly brackets, 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.

<source lang="cpp">
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
</source>

This is very useful for static lists or just for initializing a struct to a particular 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 <code>std::vector</code>.

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

<source lang="cpp">
class SequenceClass {
public:
SequenceClass(std::initializer_list<int> list);
};
</source>

This allows <code>SequenceClass</code> to be constructed from a sequence of integers, as such:

<source lang="cpp">
SequenceClass some_var = {1, 4, 5, 6};
</source>

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 [[#Uniform_initialization|below]])

The class <code>std::initializer_list<></code> is a first-class C++11 standard library type. However, they can be initially constructed statically by the C++11 compiler only through the use of the {} syntax. The list can be copied once constructed, though this is only a copy-by-reference. An initializer list is constant; its members cannot be changed once the initializer list is created, nor can the data in those members be changed.

Because initializer_list is a real type, it can be used in other places besides class constructors. Regular functions can take typed initializer lists as arguments. For example:

<source lang="cpp">
void function_name(std::initializer_list<float> list);

function_name({1.0f, -3.45f, -0.4f});
</source>

Standard containers can also be initialized in the following ways:
<source lang="cpp">
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
</source>

===Uniform initialization===
C++03 has a number of problems with initializing types. There are several ways to initialize types, and they do not all produce the same 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 <code>SomeType var = {/*stuff*/};</code>).

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

<source lang="cpp">
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};
</source>

The initialization of <code>var1</code> 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 necessary. If no conversion exists, or only a narrowing conversion exists, the program is ill-formed. The initialization of <code>var2</code> invokes the constructor.

One is also able to do the following:

<source lang="cpp">

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

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

Uniform initialization does not replace constructor syntax. There are still times when constructor syntax is required. If a class has an initializer list constructor (<code>TypeName(initializer_list<SomeType>);</code>), 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 <code>std::vector</code> has an initializer list constructor for its template type. This means that the following code:

<source lang="cpp">
std::vector<int> the_vec{4};
</source>

will call the initializer list constructor, not the constructor of <code>std::vector</code> 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), the type of a variable must be explicitly specified in order to use it. 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. Therefore, storing intermediates in variables is difficult, possibly requiring knowledge of the internals of a particular 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 <code>auto</code> keyword. This creates a variable of the specific type of the initializer:

<source lang="cpp">
auto some_strange_callable_type = boost::bind(&some_function, _2, _1, some_object);
auto other_variable = 5;
</source>

The type of <code>some_strange_callable_type</code> is simply whatever the particular template function override of <code>boost::bind</code> 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 <code>other_variable</code> is also well-defined, but it is easier for the user to determine. It is an <code>int</code>, which is the same type as the integer literal.

Additionally, the keyword <code>[[decltype]]</code> can be used to determine the type of an expression at compile-time. For example:

<source lang="cpp">
int some_int;
decltype(some_int) other_integer_variable = 5;
</source>

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

<code>auto</code> is also useful for reducing the verbosity of the code. For instance, instead of writing
<source lang="cpp">
for (std::vector<int>::const_iterator itr = myvec.cbegin(); itr != myvec.cend(); ++itr)
</source>
the programmer can use the shorter
<source lang="cpp">
for (auto itr = myvec.cbegin(); itr != myvec.cend(); ++itr)
</source>

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

The type denoted by <code>decltype</code> can be different from the type deduced by <code>auto</code>.
<source lang="cpp">
#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
}
</source>

===Range-based for-loop===
In C++03, iterating over the elements of a list requires a lot of code. Other languages have implemented support for [[syntactic sugar]] that allow the programmer to write a simple “foreach” statement that automatically traverses items in a list.
One of those languages is the [[Java (programming language)|Java]] programming language, which received support for what has been defined as enhanced for loops in [[Java version history#J2SE 5.0 .28September_30.2C_2004.29|Java 5.0]].<ref>{{cite web|url=http://docs.oracle.com/javase/1.5.0/docs/guide/language/index.html |title=Java Programming Language: Enhancements in JDK 5 |publisher=Oracle.com}}</ref>

C++11 added a similar feature. The statement <code>for</code> allows for easy iteration over a list of elements:

<source lang="cpp">
int my_array[5] = {1, 2, 3, 4, 5};
for (int &x : my_array) {
x *= 2;
}
</source>

This form of <code>for</code>, 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 <code>begin()</code> and <code>end()</code> functions defined for it that return iterators. All of the standard library containers that have begin/end pairs will work with the range-based for statement.

===Lambda functions and expressions===
{{main|Anonymous function#C++}}

C++11 provides the ability to create [[anonymous function]]s, called lambda functions.<ref>
{{cite web
|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf
|title=Document no: N1968=06-0038- Lambda expressions and closures for C++
|publisher=Open Standards
}}</ref>
These are defined as follows:

<source lang="cpp">
[](int x, int y) { return x + y; }
</source>

The return type is implicit; it returns the type of the return expression (<code>decltype(x+y)</code>). The return type of a lambda can be omitted as long as all <code>return</code> expressions return the same type.
A lambda can optionally be a [[Closure (computer science)|closure]].

===Alternative function syntax===
[[C (programming language)|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 necessary. However, as C++ became more complicated, it exposed a number of limitations, particularly with regard to template function declarations. The following, for example, is not allowed in C++03:

<source lang="cpp">
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
</source>

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

<source lang="cpp">
template<class Lhs, class Rhs>
decltype(lhs+rhs) adding_func(const Lhs &lhs, const Rhs &rhs) {return lhs + rhs;} //Not legal C++11
</source>

This is not legal C++ because <code>lhs</code> and <code>rhs</code> 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'':

<source lang="cpp">
template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}
</source>

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

<source lang="cpp">
struct SomeStruct {
auto func_name(int x, int y) -> int;
};

auto SomeStruct::func_name(int x, int y) -> int {
return x + y;
}
</source>

The use of the keyword “auto” in this case means something different from its use in automatic type deduction.

===Object construction improvement===
In C++03, constructors of a class are not allowed to call other constructors of that class; each constructor must construct all of its class members itself or call a common member function, like these,

<source lang="cpp">
class SomeType {
int number;

public:
SomeType(int new_number) : number(new_number) {}
SomeType() : number(42) {}
};
</source>

<source lang="cpp">
class SomeType {
int number;

private:
void Construct(int new_number) { number = new_number; }
public:
SomeType(int new_number) { Construct(new_number); }
SomeType() { Construct(42); }
};
</source>

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 (known as [[Delegation (programming)|delegation]]). This allows constructors to utilize another constructor's behavior with a minimum of added code. Examples of other languages similar to C++ that provide delegation are [[Java (programming language)|Java]], [[C Sharp (programming language)|C#]], and [[D (programming language)|D]].

This syntax is as follows:

<source lang="cpp">
class SomeType {
int number;

public:
SomeType(int new_number) : number(new_number) {}
SomeType() : SomeType(42) {}
};
</source>

Notice that, in this case, the same effect could have been achieved by making new_number a defaulting 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 delegate 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. This means that the C++11 compiler will generate code to perform the inheritance, the forwarding of the derived class to the base class. Note that this is an all-or-nothing feature; either all of that base class's constructors are forwarded or none of them are. Also, note that there are restrictions for multiple inheritance, such that class constructors cannot be inherited from two classes that use constructors with the same signature. Nor can a constructor in the derived class exist that matches a signature in the inherited base class.

The syntax is as follows:

<source lang="cpp">
class BaseClass {
public:
BaseClass(int value);
};

class DerivedClass : public BaseClass {
public:
using BaseClass::BaseClass;
};
</source>

For member initialization, C++11 allows the following syntax:

<source lang="cpp">
class SomeClass {
public:
SomeClass() {}
explicit SomeClass(int new_value) : value(new_value) {}

private:
int value = 5;
};
</source>

Any constructor of the class will initialize <code>value</code> with 5, if the constructor does not override the initialization with its own. So the above empty constructor will initialize <code>value</code> 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 equality 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:

<source lang="cpp">
struct Base {
virtual void some_func(float);
};

struct Derived : Base {
virtual void some_func(int);
};
</source>

The <code>Derived::some_func</code> is intended to replace the base class version. But because it has a different interface, 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.

<source lang="cpp">
struct Base {
virtual void some_func(float);
};

struct Derived : Base {
virtual void some_func(int) override; // ill-formed because it doesn't override a base class method
};
</source>

The <code>override</code> 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 error out.

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 <code>final</code>. For example:

<source lang="cpp">
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
};
</source>

In this example, the <code>virtual void f() final;</code> 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.

Note that neither <code>override</code> nor <code>final</code> are language keywords. They are technically identifiers; they gain special meaning only when used in those specific contexts. In any other location, they can be valid identifiers.

===Null pointer constant===
For the purposes of this section and this section alone, every occurrence of “<code>0</code>” is meant as “a constant expression which evaluates to <code>0</code>, 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 <code>[[0 (number)|0]]</code> has had the double role of constant integer and null pointer constant. The ambiguity inherent in the double meaning of <code>0</code> was dealt with in C by the use of the preprocessor macro <code>NULL</code>, which commonly expands to either <code>((void*)0)</code> or <code>0</code>. C++ didn't adopt the same behavior, allowing only <code>0</code> as a null pointer constant. This interacts poorly with function overloading:

<source lang="cpp">
void foo(char *);
void foo(int);
</source>

If <code>NULL</code> is defined as <code>0</code> (which is usually the case in C++), the statement <code>foo(NULL);</code> will call <code>foo(int)</code>, 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: <code>nullptr</code>. It is of type <code>nullptr_t</code>, 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 <code>bool</code>. While the original proposal specified that an rvalue of type <code>nullptr</code> should not be convertible to <code>bool</code>, 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.{{Ref|n2697}}

For backwards compatibility reasons, <code>0</code> remains a valid null pointer constant.

<source lang="cpp">
char *pc = nullptr; // OK
int *pi = nullptr; // OK
bool b = nullptr; // OK. b is false.
int i = nullptr; // error

foo(nullptr); // calls foo(char *), not foo(int);
</source>

===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. Additionally, the underlying integral type is implementation-defined; code that depends on the size of the enumeration is therefore non-portable. Lastly, enumeration values are scoped to the enclosing scope. Thus, it is not possible for two separate enumerations to have matching member names.

C++11 allows a special classification of enumeration that has none of these issues. This is expressed using the <code>enum class</code> (<code>enum struct</code> is also accepted as a synonym) declaration:

<source lang="cpp">
enum class Enumeration {
Val1,
Val2,
Val3 = 100,
Val4 // = 101
};
</source>

This enumeration is type-safe. Enum class values are not implicitly converted to integers; therefore, they cannot be compared to integers either (the expression <code>Enumeration::Val4 == 101</code> gives a compiler error).

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

<source lang="cpp">
enum class Enum2 : unsigned int {Val1, Val2};
</source>

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, <code>Val1</code> is undefined, but <code>Enum2::Val1</code> is defined.

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

<source lang="cpp">
enum Enum3 : unsigned long {Val1 = 1, Val2};
</source>

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

Forward-declaring enums is also possible in C++11. Previously, 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:

<source lang="cpp">
enum Enum1; // Illegal in C++03 and C++11; the underlying type cannot be determined.
enum Enum2 : unsigned int; // Legal in C++11, the underlying type is explicitly specified.
enum class Enum3; // Legal in C++11, the underlying type is int.
enum class Enum4 : unsigned int; // Legal in C++11.
enum Enum2 : unsigned short; // Illegal in C++11, because Enum2 was previously declared with a different underlying type.
</source>

===Right angle bracket===
C++03's parser defines “<code>>></code>” as the right shift 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:

<source lang="cpp">
template<bool Test> class SomeType;
std::vector<SomeType<1>2>> x1; // Interpreted as a std::vector of SomeType<true> 2>,
// which is not legal syntax. 1 is true.
std::vector<SomeType<(1>2)>> x1; // Interpreted as std::vector of SomeType<false>,
// which is legal C++11 syntax. (1>2) is false.
</source>

===Explicit conversion operators===
C++98 added the <code>explicit</code> 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 <code>operator bool()</code> to allow it to act more like a primitive pointer: if it includes this conversion, it can be tested with <code>if (smart_ptr_variable)</code> (which would be true if the pointer was non-null and false otherwise). However, this allows other, unintended conversions as well. Because C++ <code>bool</code> 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 <code>explicit</code> keyword can now be applied to conversion operators. As with constructors, it prevents the use of those conversion functions in implicit conversions. However, language contexts that specifically require a boolean value (the conditions of if-statements and loops, as well as operands to the logical operators) count as explicit conversions and can thus use a bool conversion operator.

===Alias templates===

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:

<source lang="cpp">
template <typename First, typename Second, int Third>
class SomeType;

template <typename Second>
typedef SomeType<OtherType, Second, 5> TypedefName; //Illegal in C++03
</source>

This will not compile.

C++11 adds this ability with the following syntax:

<source lang="cpp">
template <typename First, typename Second, int Third>
class SomeType;

template <typename Second>
using TypedefName = SomeType<OtherType, Second, 5>;
</source>

The <code>using</code> syntax can be also used as type aliasing in C++11:
<source lang="cpp">
typedef void (*Type)(double); // Old style
using OtherType = void (*)(double); // New introduced syntax
</source>

===Unrestricted unions===
In C++03, there are restrictions on what types of objects can be members of a <code>union</code>. For example, unions cannot contain any objects that define a non-trivial constructor. C++11 lifts some of these restrictions.{{Ref|n2544}}

* Unions can now contain objects that have a non-trivial constructor.
* If so, the implicit default constructor of the union is deleted, forcing a manual definition.

This is a simple example of a union permitted in C++11:
<source lang="cpp">
#include <new> // Required 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; // Illegal in C++03; legal in C++11.
//
// Due to the Point member, a constructor definition is now required.
//
U() {new(&p) Point();}
};
</source>

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 previously impossible, exceedingly verbose, or required non-portable libraries.

===Variadic templates===
{{main|variadic templates}}

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

===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 <code>const char</code>. The second kind, defined as <code>L""</code>, produces a null-terminated array of type <code>const wchar_t</code>, where <code>wchar_t</code> 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]] [[Comparison of Unicode encodings|encodings]].

For the purpose of enhancing support for Unicode in C++ compilers, the definition of the type <code>char</code> has been modified to be both at least the size necessary 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 previously defined as only the latter.

There are three Unicode encodings that C++11 will support: [[UTF-8]], [[UTF-16]], and [[UTF-32]]. In addition to the previously noted changes to the definition of <code>char</code>, C++11 adds two new character types: <code>char16_t</code> and <code>char32_t</code>. These are designed to store UTF-16 and UTF-32 respectively.

The following shows how to create string literals for each of these encodings:

<source lang="cpp">
u8"I'm a UTF-8 string."
u"This is a UTF-16 string."
U"This is a UTF-32 string."
</source>

The type of the first string is the usual <code>const char[]</code>. The type of the second string is <code>const char16_t[]</code>. The type of the third string is <code>const char32_t[]</code>.

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

<source lang="cpp">
u8"This is a Unicode Character: \u2018."
u"This is a bigger Unicode Character: \u2018."
U"This is a Unicode Character: \u2018."
</source>

The number after the <code>\u</code> is a hexadecimal number; it does not need the usual <code>0x</code> prefix. The identifier <code>\u</code> represents a 16-bit Unicode codepoint; to enter a 32-bit codepoint, use <code>\U</code> and a 32-bit hexadecimal number. Only valid Unicode codepoints can be entered. For example, codepoints 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:

<pre>
R"(The String Data \ Stuff " )"
R"delimiter(The String Data \ Stuff " )delimiter"
</pre>

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

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

<pre>
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.)"
</pre>

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

C++11 also includes the ability for the user to define new kinds of literal modifiers that will construct objects based on the string of characters that the literal modifies.

Literals transformation 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 <code>1234</code>, as a raw literal, is this sequence of characters <code>'1'</code>, <code>'2'</code>, <code>'3'</code>, <code>'4'</code>. As a cooked literal, it is the integer 1234. The C++ literal <code>0xA</code> in raw form is <code>'0'</code>, <code>'x'</code>, <code>'A'</code>, 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.

User-defined literals processing the raw form of the literal are defined as follows:

<source lang="cpp">
OutputType operator "" _suffix(const char * literal_string);

OutputType some_variable = 1234_suffix;
</source>

The second statement executes the code defined by the user-defined literal function. This function is passed <code>"1234"</code> as a C-style string, so it has a null terminator.

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

<source lang="cpp">
template<char...> OutputType operator "" _suffix();

OutputType some_variable = 1234_suffix;
OutputType another_variable = 2.17_suffix;
</source>

This instantiates the literal processing function as <code>operator "" _suffix<'1', '2', '3', '4'>()</code>. In this form, there is no terminating null character to the string. The main purpose to doing this is to use C++11's <code>constexpr</code> keyword and the compiler to allow the literal to be transformed entirely at compile time, assuming <code>OutputType</code> is a constexpr-constructable and copyable type, and the literal processing function is a <code>constexpr</code> function.

For numeric literals, the type of the cooked literal is either <code>unsigned long long</code> for integral literals or <code>long double</code> 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:

<source lang="cpp">
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.
</source>

For string literals, the following are used, in accordance with the previously mentioned new string prefixes:

<source lang="cpp">
OutputType operator "" _suffix(const char * string_values, size_t num_chars);
OutputType operator "" _suffix(const wchar_t * string_values, size_t num_chars);
OutputType operator "" _suffix(const char16_t * string_values, size_t num_chars);
OutputType operator "" _suffix(const char32_t * string_values, size_t num_chars);

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

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

===Multithreading memory model===
{{See also|Memory model (computing)}}
The C++11 standardizes support for [[Thread (computer science)|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|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 [[Variable (programming)|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|''thread-local'']] storage duration (in addition to the existing ''static'', ''dynamic'' and ''automatic'') is indicated by the storage specifier <code>thread_local</code>.

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 and deleted 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 (<code>operator=</code>), and a destructor. The programmer can override these defaults by defining custom versions. C++ also defines several global operators (such as <code>operator=</code> and <code>operator new</code>) that work on all classes, which the programmer can override.

However, there is very little control over the creation of these defaults. Making a class inherently non-copyable, for example, requires 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,<ref name="C++03 3.2/3">[[ISO]]/[[International Electrotechnical Commission|IEC]] (2003). ''[[ISO/IEC 14882|ISO/IEC 14882:2003(E): Programming Languages - C++]] §3.2 One definition rule [basic.def.odr]'' para. 3</ref> this typically results in a linker error.{{Citation needed|date=June 2009}}

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. For example, the following type explicitly declares that it is using the default constructor:

<source lang="cpp">
struct SomeType {
SomeType() = default; //The default constructor is explicitly stated.
SomeType(OtherType value);
};
</source>

Alternatively, certain features can be explicitly disabled. For example, the following type is non-copyable:

<source lang="cpp">
struct NonCopyable {
NonCopyable() = default;
NonCopyable(const NonCopyable&) = delete;
NonCopyable & operator=(const NonCopyable&) = delete;
};
</source>

The <code>= delete</code> specifier can be used to prohibit calling any function, which can be used to disallow calling a member function with particular parameters. For example:
<source lang="cpp">
struct NoInt {
void f(double i);
void f(int) = delete;
};
</source>

An attempt to call <code>f()</code> with an <code>int</code> will be rejected by the compiler, instead of performing a silent conversion to <code>double</code>. This can be generalized to disallow calling the function with any type other than <code>double</code> as follows:
<source lang="cpp">
struct OnlyDouble {
void f(double d);
template<class T> void f(T) = delete;
};
</source>

===Type <code>long long int</code>===
In C++03, the largest integer type is <code>long int</code>. It is guaranteed to have at least as many usable bits as <code>int</code>. This resulted in <code>long int</code> having size of 64 bits on some popular implementations and 32 bits on others. C++11 adds a new integer type <code>long long int</code> to address this issue. It is guaranteed to be at least as large as a <code>long int</code>, and have no fewer than 64 bits. The type was originally introduced by [[C99]] to the standard C, and most C++ compilers support it as an extension already.<ref>http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html</ref><ref>http://msdn.microsoft.com/en-us/library/s3f49ktz(VS.80).aspx</ref>

===Static assertions===
C++03 provides two methods to test [[Assertion (computing)|assertions]]: the macro <code>assert</code> and the preprocessor directive <code>#error</code>. 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 <code>static_assert</code>.
The declaration assumes the following form:
static_assert (''constant-expression'', ''error-message'');

Here are some examples of how <code>static_assert</code> can be used:
<source lang="cpp">
static_assert((GREEKPI > 3.14) && (GREEKPI < 3.15), "GREEKPI is inaccurate!");
</source>
<source lang="cpp">
template<class T>
struct Check {
static_assert(sizeof(int) <= sizeof(T), "T is not big enough!");
};
</source>
<source lang="cpp">
template<class Integral>
Integral foo(Integral x, Integral y) {
static_assert(std::is_integral<Integral>::value, "foo() parameter must be an integral type.");
}
</source>

When the constant expression is <code>false</code> the compiler produces an error message. The first example represents an alternative to the preprocessor directive <code>#error</code>, in contrast in the second example the assertion is checked at every instantiation of the template class <code>Check</code>.

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

===Allow <code>sizeof</code> to work on members of classes without an explicit object===
In C++03, the <code>sizeof</code> operator can be used on types and objects. But it cannot be used to do the following:

<source lang="cpp">
struct SomeType { OtherType member; };

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

This should return the size of <code>OtherType</code>. C++03 does not allow this, so it is a compile error. C++11 does allow it.

===Control and query object alignment===
C++11 allows variable alignment to be queried and controlled with <code>alignof</code> and <code>alignas</code>.

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

The <code>alignas</code> specifier controls the memory alignment for a variable. The specifier takes a constant or a type; when supplied a type <code>alignas(T)</code> is short hand for <code>alignas(alignof(T))</code>. For example, to specify that a char array should be properly aligned to hold a float:
<source lang="cpp">
alignas(float) unsigned char c[sizeof(float)]
</source>

===Allow garbage collected implementations===
In previous C++ standards, a conforming implementation could not collect objects even if no pointer to the object remained because pointers might still exist in some encoded form (e.g., as strings). C++11 changes language semantics to make garbage collection possible. {{citation needed|date=August 2012}} It is still implementation-defined whether unreachable dynamically allocated objects actually are automatically reclaimed.

==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 [[Library (computer science)|libraries]] was defined in the document ''[[Technical Report 1|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 <code>std::tr1</code>. For C++11 they were moved to namespace <code>std</code>. 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.

The committee intends to create a second technical report (called TR2) now that standardization of C++11 is complete. Library proposals which were not ready in time for C++11 will be put into TR2 or further technical reports.

===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
* <code>[[decltype]]</code>
* <code>explicit</code> conversion operators
* <code>default</code>/<code>delete</code>d functions

Additionally, much time has passed since the previous C++ standard. A great deal of code using the standard library has been written; this has revealed portions of the standard libraries that could use some improvement. Among the many areas of improvement considered were standard library [[Allocator (C++)|allocator]]s. A new scope-based model of allocators was included in C++11 to supplement the previous model.

===Threading facilities===
While the C++11 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 (<code>std::thread</code>) 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 through the <code>std::thread::join()</code> member function. Access is provided, where feasible, to the underlying native thread object(s) for [[Platform (computing)|platform]] specific operations by the <code>std::thread::native_handle()</code> member function.

For synchronization between threads, appropriate [[Mutual exclusion|mutexes]] (<code>std::mutex</code>, <code>std::recursive_mutex</code>, etc.) and [[Monitor (synchronization)|condition variables]] (<code>std::condition_variable</code> and <code>std::condition_variable_any</code>) are added to the library. These are accessible through [[Resource Acquisition Is Initialization|RAII]] locks (<code>std::lock_guard</code> and <code>std::unique_lock</code>) and locking algorithms for easy use.

For high-performance, low-level work, it is sometimes necessary to communicate between threads without the overhead of mutexes. This is achieved using [[atomic operation]]s on memory locations. These can optionally specify the minimum memory visibility constraints required for an operation. Explicit [[memory barrier]]s may also be used for this purpose.

The C++11 thread library also includes [[futures and promises]] for passing asynchronous results between threads, and <code>std::packaged_task</code> 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.<ref>{{Cite web
| last = Milewski
| first = Bartosz
| title = Broken promises–C++0x futures
| date = 3 March 2009
| url = http://bartoszmilewski.wordpress.com/2009/03/03/broken-promises-c0x-futures/
| accessdate =24 January 2010}}</ref>

Further high-level threading facilities such as [[thread pool]]s have been remanded to a future C++ [[Technical Report 1|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 <code>std::async</code> facility provides a convenient method of running tasks and tying them to a <code>std::future</code>. 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|variadic templates]]. The TR1 version required an implementation-defined maximum number of contained types, and required substantial macro trickery to implement reasonably. 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:
<source lang="cpp">
template <class ...Types> class tuple;
</source>

An example of definition and use of the tuple type:
<source lang="cpp">
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.
</source>

It’s possible to create the tuple <code>proof</code> 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, it is necessary that each element type possesses a copy constructor; otherwise, it is necessary that each element type of the right-side tuple is 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.
<source lang="cpp">
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 *'.
</source>

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):
*<code>std::tuple_size<nowiki><T></nowiki>::value</code> returns the number of elements in the tuple <code>T</code>,
*<code>std::tuple_element<nowiki><I, T></nowiki>::type</code> returns the type of the object number <code>I</code> of the tuple <code>T</code>.

===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 through ''[[Hash tables#Separate chaining|linear chaining]]'' because the committee didn't consider 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 <tt>unordered_</tt> prefix.

{| class="wikitable" style="text-align: center"
! Type of hash table !! Associated values !! Equivalent keys
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_set]]</code> || {{no}} || {{no}}
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_multiset]]</code> || {{no}} || {{yes}}
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_map]]</code> || {{yes}} || {{no}}
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_multimap]]</code> || {{yes}} || {{yes}}
|}

New classes fulfill all the requirements of a [[Standard Template Library#Containers|container class]], and have all the methods necessary to access elements: <code>insert</code>, <code>erase</code>, <code>begin</code>, <code>end</code>.

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 <code><nowiki><functional></nowiki></code> and the introduction of headers <code><nowiki><unordered_set></nowiki></code> and <code><nowiki><unordered_map></nowiki></code>. 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 <code><nowiki><regex></nowiki></code>, is made of a couple of new classes:
*[[regular expressions]] are represented by instance of the template class <code>std::regex</code>;
*occurrences are represented by instance of the template class <code>std::match_results</code>.
The function <code>std::regex_search</code> is used for searching, while for ‘search and replace’ the function <code>std::regex_replace</code> is used which returns a new string.
The algorithms <code>std::regex_search</code> and <code>std::regex_replace</code> take a regular expression and a string and write the occurrences found in the struct <code>std::match_results</code>.

Here is an example of the use of <code>std::match_results</code>:
<source lang="cpp">
const char *reg_esp = "[ ,.\\t\\n;:]"; // List of separator characters.

// this can be done using raw string literals:
// const char *reg_esp = R"([ ,.\t\n;:])";

std::regex rgx(reg_esp); // 'regex' is an instance of the template class
// 'basic_regex' with argument of type 'char'.
std::cmatch match; // 'cmatch' is an instance of the template class
// 'match_results' with argument of type 'const char *'.
const char *target = "Unseen University - Ankh-Morpork";

// Identifies all words of 'target' separated by characters of 'reg_esp'.
if( std::regex_search( target, match, rgx ) ) {
// If words separated by specified characters are present.

const size_t n = match.size();
for( size_t a = 0; a < n; a++ ) {
std::string str( match[a].first, match[a].second );
std::cout << str << "\n";
}
}
</source>

Note the use of double [[backslash]]es, because C++ uses backslash as an escape character. The C++11 [[#New_string_literals|raw string]] feature could be used to avoid the problem.

The library <code><nowiki><regex></nowiki></code> requires neither alteration of any existing header (though it will use them where appropriate) nor an extension of the core language.

===General-purpose smart pointers===
{{main|Smart_pointer|l1=C++ Smart Pointers}}
C++11 provides {{code|std::unique_ptr}}, as well as improvements to {{code|std::shared_ptr}} and {{code|std::weak_ptr}} from TR1. {{code|std::auto_ptr}} is deprecated.

===Extensible random number facility===
The C standard library provides the ability to generate [[pseudorandom numbers]] through the function <code>rand</code>. However, the algorithm is delegated entirely to the library vendor. C++ inherited this functionality with no changes, but C++11 will provide 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 [[Distribution (mathematics)|mathematical distribution]] of the outcome. These two are combined to form a random number generator object.

Unlike the C standard <code>rand</code>, the C++11 mechanism will come with three base generator engine algorithms:
* <code>[[Linear congruential generator|linear_congruential_engine]]</code>,
* <code>[[Subtract with carry|subtract_with_carry_engine]]</code>, and
* <code>[[Mersenne twister|mersenne_twister_engine]]</code>.

C++11 will also provide a number of standard distributions:
* <code>[[Uniform distribution (discrete)|uniform_int_distribution]]</code>,
* <code>[[Uniform distribution (continuous)|uniform_real_distribution]]</code>,
* <code>[[Bernoulli distribution|bernoulli_distribution]]</code>,
* <code>[[Binomial distribution|binomial_distribution]]</code>,
* <code>[[Geometric distribution|geometric_distribution]]</code>,
* <code>[[Negative binomial distribution|negative_binomial_distribution]]</code>,
* <code>[[Poisson distribution|poisson_distribution]]</code>,
* <code>[[Exponential distribution|exponential_distribution]]</code>,
* <code>[[Gamma distribution|gamma_distribution]]</code>,
* <code>[[Weibull distribution|weibull_distribution]]</code>,
* <code>[[Generalized extreme value distribution|extreme_value_distribution]]</code>,
* <code>[[Normal distribution|normal_distribution]]</code>,
* <code>[[Lognormal distribution|lognormal_distribution]]</code>,
* <code>[[Chi squared distribution|chi_squared_distribution]]</code>,
* <code>[[Cauchy distribution|cauchy_distribution]]</code>,
* <code>[[F-distribution|fisher_f_distribution]]</code>,
* <code>[[Student's t-distribution|student_t_distribution]]</code>,
* <code>[[Discrete_distribution#Discrete_probability_distribution|discrete_distribution]]</code>,
* <code>[[Step function|piecewise_constant_distribution]]</code> and
* <code>[[Piecewise linear function|piecewise_linear_distribution]]</code>.

The generator and distributions are combined as in the following example:

<source lang="cpp">
#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.
</source>

===Wrapper reference===
A [[Adapter pattern|wrapper]] reference is obtained from an instance of the template class <code>reference_wrapper</code>. Wrapper references are similar to normal references (‘<code>&</code>’) of the C++ language. To obtain a wrapper reference from any object the function template <code>ref</code> is used (for a constant reference <code>cref</code> is used).

Wrapper references are useful above all for function templates, where references to parameters rather than copies are needed:
<source lang="cpp">
// This function will obtain 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 < 0

g (func, std::ref(i)); // 'g<void(int &r),reference_wrapper<int>>' is instantiated
// then 'i' will be modified.
std::cout < 1
}
</source>

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

===Polymorphic wrappers for function objects===
[[Type polymorphism|Polymorphic]] [[Adapter pattern|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.

Through the example it is possible to understand its characteristics:
<source lang="cpp">
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.
</source>

The template class <code>function</code> was defined inside the header <code><nowiki><functional></nowiki></code>, and didn't require any changes 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 that allows metaprogramming during compilation through templates.

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

<source lang="cpp">
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;
</source>

Many algorithms can operate on different types of data; C++'s [[Template (programming)|template]]s 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 <code><nowiki><type_traits></nowiki></code>.

In the next example there is the template function ‘elaborate’ that, depending on the given data types, will instantiate one of the two proposed algorithms (<code>algorithm.do_it</code>).

<source lang="cpp">
// 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 ) ;
}
</source>

Through '''type traits''', defined in header <code><nowiki><type_transform></nowiki></code>, it’s also possible to create type transformation operations (<code>static_cast</code> and <code>const_cast</code> are insufficient inside a template).

This type of programming produces elegant and concise code; however the weak point of these techniques is the debugging: 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:

<source lang="cpp">
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;
};
</source>

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

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

TR1 introduces, and C++11 adopts, the template class <code>std::result_of</code> that allows one to determine and use the return type of a function object for every declaration. The object <code>CalculusVer2</code> uses the <code>std::result_of</code> object to derive the return type of the function object:
<source lang="cpp">
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;
};
</source>
In this way in instances of function object of <code>CalculusVer2<nowiki><Confused></nowiki></code> there are no conversions, warnings, or errors.

The only change from the TR1 version of <code>std::result_of</code> 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 <code>[[#Type inference|decltype]]</code>, the C++11 version of <code>std::result_of</code> no longer needs these special cases; implementations are required to compute a type in all cases.

==Features originally planned but removed or not included==
Heading for a separate TR:
* [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf Modules]
* Decimal Types
* Math Special Functions
Postponed:
* [[Concepts (C++)|Concepts]]
* More complete or required garbage collection support
* Reflection
* Macro Scopes

==Features removed or deprecated==
* The term [[sequence point]], which is being replaced by specifying that either one operation is sequenced before another, or that two operations are unsequenced.<ref>{{cite web|url=http://blogs.msdn.com/b/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx|title=Update on the C++-0x Language Standard|last=Caves|first=Jonathan|date=4 June 2007|accessdate=25 May 2010}}</ref>
* <code>[[export (C++)|export]]</code><ref name="sutter0310">{{cite web|url=http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/|title=Trip Report: March 2010 ISO C++ Standards Meeting|last=Sutter|first=Herb|authorlink=Herb Sutter|date=3 March 2010|accessdate=24 March 2010}}</ref>: Its current use is ''removed'', but the keyword itself is still reserved, for potential future use.
* dynamic [[exception specification]]s<ref name="sutter0310"/> are deprecated. Compile time specification of non-exception throwing functions is available with the <code>noexcept</code> keyword (useful for optimization)
* <code>[[auto ptr|std::auto_ptr]]</code> is deprecated. Superseded by <code>std::unique_ptr</code>
* Function object base classes (<code>std::unary_function</code>, <code>std::binary_function</code>), adapters to pointers to functions and adapters to pointers to members, binder classes; these are all deprecated.

==See also==

*[[C++ Technical Report 1]]
*[[C99]]
*[[C11_(C_standard_revision)|C11]]

==References==

{{reflist}}

== External links ==
* [http://www.open-std.org/jtc1/sc22/wg21/ The C++ Standards Committee]
* [http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=216 C++0X: The New Face of Standard C++]
* [http://herbsutter.wordpress.com/ Herb Sutter's blog coverage of C++11]
* [http://www.justsoftwaresolutions.co.uk/cplusplus/ Anthony Williams' blog coverage of C++11]
* [http://www.csclub.uwaterloo.ca/media/C++0x%20-%20An%20Overview.html A talk on C++0x given by Bjarne Stroustrup at the University of Waterloo]
* [http://www.devx.com/SpecialReports/Article/38813/0/page/1 The State of the Language: An Interview with Bjarne Stroustrup (15 August 2008)]
* [http://wiki.apache.org/stdcxx/C++0xCompilerSupport Wiki page to help keep track of C++ 0x core language features and their availability in compilers]
* [http://en.cppreference.com Online C++11 standard library reference]

{{CProLang}}

[[Category:C++]]
[[Category:Computer standards]]
[[Category:Articles with example C++ code]]

[[es:C++11]]
[[fr:C++11]]
[[ko:C++11]]
[[it:C++11]]
[[ja:C++11]]
[[pl:C++11]]
[[pt:C++11]]
[[ru:C++11]]
[[sr:Нацрт C++0x од марта 2010.]]
[[fi:C++11]]
[[sv:C++#Historia]]
[[th:ภาษาซีพลัสพลัสโอเอกซ์]]
[[uk:C++11]]
[[vi:C++11]]
[[zh:C++11]]

AST

2012-10-16T00:41:34Z

Code-structure: Changing the layout of the page to make it similar to CST page.

{{Wiktionary|AST|Ast|ast}}
'''AST''' is a [[three letter acronym|three-letter abbreviation]] that stands for different things.

==Science and technology==
* [[Abstract syntax tree]], a finite, labeled, directed tree used in computer science
* [[Andrew S. Tanenbaum]], a computer scientist (often uses this acronym as his identifier)
* [[Asynchronous System Trap]]s, a mechanism used in several computer operating systems

==Medicine==
* [[Aspartate transaminase]] ([[wikt:AKA|aka]] SGOT), an enzyme associated with liver parenchymal cells. AST values are checked in [[blood test]]s
* Agitated saline test ([[agitated saline contrast test]]), a diagnostic heart procedure

==Mathematics==
* [[Alternating series test]], a method used to prove that infinite series of terms converge
* [[Alternative set theory]], an alternative mathematical approach to the concept of set

==Organisations and companies==
* [[Allied Security Trust]], a [[patent holding company]]
* [[AST Research]], a defunct personal computer manufacturer
* [[Association for Software Testing]], a nonprofit organization dedicated to advancing software testing
* [[AST (publisher)]]
* AST, American Sensor Technologies, Inc., A sensor manufacturing company
* AST, Airborne Surveillance Technician aboard the USAF E-3, Cooks food and delivers water to USAF crewmembers.

==Education==
* [http://www.astkorea.org Association of School Teachers], a national English teachers' service provider. Non for Profit Organization. TESOL program.
* [[Ameson Scholastic Test]], originally designed for Chinese students applying to the University of Cambridge in the UK, and now used by a handful of UK and Australian universities
* [[ACT Scaling Test]], a series of aptitude tests taken by Year 12 students in ACT, Australia
* [[Alpha Sigma Tau]], a national collegiate sorority of the United States
* [[Atlantic School of Theology]], an ecumenical university in Atlantic Canada
* [[Conroe ISD Academy of Science and Technology]], a specialized magnet school of science and technology in Conroe, Texas
* [[Avalanche Skills Training]], a standardized form of avalanche training in Canada
* [[American School of Tegucigalpa]]
* [[Advanced Skills Teacher]] - a specific type of teaching role in England and Wales
* Associate in Specialized Technology, a type of [[Associate's degree]]

==Politics and government==
* [[Office of Commercial Space Transportation]], a branch of the US Federal Aviation Administration
* [[Aviation Survival Technician]], a United States Coast Guard rating
* [[Alaska State Troopers]], the state police force for the State of Alaska
* [[Chadian Social Action]] (Action Sociale Tchadienne), a defunct Chadian political party

==Transport==
* [[Astoria Regional Airport]], a public airport of Clatsop County, Oregon, USA (FAA Identifier: AST)
* [[Aston railway station]], a railway station in Aston in Birmingham, England (National Rail code: AST)

==Time zones==
* [[Atlantic Standard Time]] — [[UTC-4]]
* [[Alaska Standard Time]] — [[UTC-9]]
* [[Arabia Standard Time]] — [[UTC+3]]

==Other==
* [[Assured shorthold tenancy]], a form of Assured tenancy with limited security of tenure
* [[Asturian language]], a Romance language spoken in Asturias, Spain (ISO 639 alpha-3, ast)
* [[Arsenal Supporters' Trust]], London, UK. Arsenal FC's critical friend of supporters and shareholders
* [[Athlitikos Syllogos Trikala 2000 BC]], a top tier Greek basketball team
* [[Astana Team]], the UCI code for the professional road bicycle racing team
* Anti Structure Tandem, a type of [[tandem-charge]] where the second charge can be delayed so that it explodes deep inside the structure

{{disambiguation}}
[[Category:Initialisms]]

[[de:Ast (Begriffsklärung)]]
[[es:AST]]
[[eo:AST]]
[[fa:AST]]
[[fr:AST]]
[[ko:AST]]
[[it:AST]]
[[nl:AST]]
[[ja:AST]]
[[pl:AST]]
[[pt:AST]]
[[ru:АСТ]]
[[sv:AST]]

Memory ordering

2012-10-15T04:31:35Z

Code-structure: Explanation of abbreviation.

{{Merge|Memory barrier|date=April 2010|discuss=Talk:Memory ordering}}
{{Cleanup|date=November 2009}}

'''Memory ordering''' is a group of properties of the modern [[microprocessor]]s, characterising their possibilities in memory operations reordering. It is a type of [[out-of-order execution]]. Memory reordering can be used to fully utilize different [[CPU cache#Cache Entries|cache]] and [[memory bank]]s.

On most modern uniprocessors memory operations are not executed in the order specified by the program code. But in singlethreaded programs from the programmer's point of view, all operations appear to have been executed in the order specified, with all inconsistencies hidden by hardware.



== In Symmetric multiprocessing (SMP) microprocessor systems ==

There are several memory-consistency models for [[Symmetric multiprocessing|SMP]] systems:
*sequential consistency (All reads and all writes are in-order)
*relaxed consistency (Some types of reordering are allowed)
** Loads can be reordered after Loads (for better working of cache coherency, better scaling)
** Loads can be reordered after Stores
** Stores can be reordered after Stores
** Stores can be reordered after Loads
*weak consistency (Reads and Writes are arbitrarily reordered, limited only by explicit [[memory barrier]]s)

On some CPUs
* [[atomic operation]]s can be reordered with Loads and Stores.
* there can be incoherent instruction cache pipeline, which prevent [[self-modifying code]] to be executed without special ICache flush/reload instructions.
* dependent loads can be reordered (this is unique for Alpha). If the processor fetches a pointer to some data after this reordering, it might not fetch the data itself but use stale data which it has already cached and not yet invalidated. Allowing this relaxation makes cache hardware simpler and faster but leads to the requirement of memory barriers for readers and writers.<ref>[http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html Reordering on an Alpha processor by Kourosh Gharachorloo]</ref>

{|class=wikitable
|+ Memory ordering in some architectures <ref name="mem_ord_pdf">[http://www.rdrop.com/users/paulmck/scalability/paper/ordering.2007.09.19a.pdf Memory Ordering in Modern Microprocessors by Paul McKenney]</ref><ref name="mem_bar">[http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf Memory Barriers: a Hardware View for Software Hackers], Figure 5 on Page 16</ref>
! Type
! Alpha !! ARMv7 !! PA-RISC !! POWER !! SPARC RMO !! SPARC PSO !! SPARC TSO !! x86 !! x86 oostore !! AMD64 !! IA64 !! zSeries
|-
| Loads reordered after Loads
| Y || Y || Y || Y || Y || || || || Y || || Y ||
|-
| Loads reordered after Stores
| Y || Y || Y || Y || Y || || || || Y || || Y ||
|-
| Stores reordered after Stores
| Y || Y || Y || Y || Y || Y || || || Y || || Y ||
|-
| Stores reordered after Loads
| Y || Y || Y || Y || Y || Y || Y || Y || Y || Y || Y || Y
|-
| Atomic reordered with Loads
| Y || Y || || Y || Y || || || || || || Y ||
|-
| Atomic reordered with Stores
| Y || Y || || Y || Y || Y || || || || || Y ||
|-
| Dependent Loads reordered
| Y || || || || || || || || || || ||
|-
| Incoherent Instruction cache pipeline
| Y || Y || || Y || Y || Y || Y || Y || Y || || Y || Y
|}

Some older x86 and AMD systems have weaker memory ordering<ref name="table">[http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/082/8211/8211t1.inline.png Table 1. Summary of Memory Ordering], from "Memory Ordering in Modern Microprocessors, Part I"</ref>

SPARC memory ordering modes:
* SPARC TSO = total-store order (default)
* SPARC RMO = relaxed-memory order (not supported on recent CPUs)
* SPARC PSO = partial store order (not supported on recent CPUs)

== Memory barrier types ==
{{See also|Memory barrier}}

=== Compiler memory barrier ===

These barriers prevent a compiler from reordering instructions, they do not prevent reordering by CPU.

* The GNU inline assembler statement
asm volatile("" ::: "memory");
or even
__asm__ __volatile__ ("" ::: "memory");
forbids [[GNU Compiler Collection|GCC]] compiler to reorder read and write commands around it.<ref>[http://lxr.linux.no/linux+v2.6.31/include/linux/compiler-gcc.h#L12 GCC compiler-gcc.h]</ref>

*[[Intel C++ Compiler|Intel ECC compiler]] uses "full compiler fence"
__memory_barrier()
intrinsics.<ref>[http://lxr.linux.no/linux+v2.6.31/include/linux/compiler-intel.h#L16 ECC compiler-intel.h]</ref><ref>[http://software.intel.com/file/6373 Intel(R) C++ Compiler Intrinsics Reference]
<blockquote>Creates a barrier across which the compiler will not schedule any data access instruction. The compiler may allocate local data in registers across a memory barrier, but not global data.</blockquote></ref>

* [[Microsoft Visual C++]] Compiler:<ref>Visual C++ Language Reference [http://msdn.microsoft.com/en-us/library/f20w0x5e(VS.80).aspx _ReadWriteBarrier]</ref>
_ReadWriteBarrier()

=== Hardware memory barrier ===
Many architectures with SMP support have special hardware instruction for flushing reads and writes.

*[[x86]], [[x86-64]]
lfence (asm), void_mm_lfence(void)
sfence (asm), void_mm_sfence(void) <ref name="vtune-sfence">[http://www.softeng.rl.ac.uk/st/archive/SoftEng/SESP/html/SoftwareTools/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc287.htm SFENCE — Store Fence]</ref>
mfence (asm), void_mm_mfence(void) <ref name="vtune-mfence">[http://www.softeng.rl.ac.uk/st/archive/SoftEng/SESP/html/SoftwareTools/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc172.htm MFENCE — Memory Fence]</ref>

*[[PowerPC]]
sync (asm)

*[[IBM POWER|POWER]]
dcs (asm)

*[[ARMv7]]
dmb (asm)

=== Compiler support for hardware memory barriers ===
Some compilers support [[intrinsic function|builtins]] that emit hardware memory barrier instructions:

*[[GNU Compiler Collection|GCC]]<ref>[http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html Atomic Builtins]</ref>, version 4.4.0 and later<ref>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793</ref>, has <code>__sync_synchronize</code>.
*The [[Microsoft Visual C++]] compiler<ref>[http://msdn.microsoft.com/en-us/library/windows/desktop/ms684208(v=vs.85).aspx MemoryBarrier macro]</ref> has <code>MemoryBarrier()</code>.
*[[Sun Studio Compiler Suite]]<ref>Handling Memory Ordering in Multithreaded Applications with Oracle Solaris Studio 12 Update 2: Part 2, Memory Barriers and Memory Fence [http://www.oracle.com/technetwork/server-storage/solarisstudio/documentation/oss-memory-barriers-fences-176056.pdf]</ref> has <code>__machine_r_barrier</code>, <code>__machine_w_barrier</code> and <code>__machine_rw_barrier</code>.

==See also ==
* [[Memory model (programming)]]
* [[Memory barrier]]

== References ==
<references/>

== Further reading ==
* ''Computer Architecture — A quantitative approach''. 4th edition. J Hennessy, D Patterson, 2007. Chapter 4.6
* Sarita V. Adve, Kourosh Gharachorloo, [http://www.cs.uiuc.edu/class/sp08/cs533/reading_list/adve95shared.pdf Shared Memory Consistency Models: A Tutorial]
* [http://www.intel.com/products/processor/manuals/318147.pdf Intel 64 Architecture Memory Ordering White Paper]
* [http://www.linuxjournal.com/article/8211 Memory ordering in Modern Microprocessors part 1]
* [http://www.linuxjournal.com/article/8212 Memory ordering in Modern Microprocessors part 2]
* {{YouTube|id=WUfvvFD5tAA|title=IA (Intel Architecture) Memory Ordering}} - [[AtGoogleTalks|Google Tech Talk]]

[[Category:Computer architecture]]
[[Category:Computer memory]]
[[Category:Consistency models]]
[[Category:Compiler construction]]
[[Category:Programming language design]]
[[Category:Run-time systems]]
[[Category:Concurrency (computer science)]]

User:Code-structure/sandbox

2012-10-15T03:20:45Z

Code-structure:

Grammar of the '''C++''' language is available as part of the standard.

abra-cadabra before [[Image:Wikipedia-Redirect-HelpScreenShot-01.jpg|alt=Redirect help|Dummy caption]] abra-cadabra after

Some text line1.
Some text line2.
Some text line3.

[[File:Wikipedia-Redirect-HelpScreenShot-01.jpg|thumb|Little caption.]]

[[User:Code-structure/sandbox/conflicts resolution]]

'''Fragment''' **Frag**

''gggg'' //Frag//

|=|=table|=header|
|a|123|qqq|

User:Code-structure/sandbox

2012-10-15T03:18:29Z

Code-structure:

2012-10-15T02:00:38Z

Code-structure: Duplicate the unabbreviation because when somebody comes to this section by direct link the explanation above is scrolled out.

{{subcat guideline|content guideline|Forking|WP:CFORK|WP:CONTENTFORK|WP:CONTENTFORKING}}
{{Guideline in a nutshell|Articles should not be split into multiple articles just so each can advocate a different stance on the subject.}}

A '''content fork''' is the creation of multiple separate articles all treating the same subject. Content forks that are created unintentionally result in redundant or conflicting articles and are to be avoided. On the other hand, as an article grows, editors often create [[WP:Summary style|Summary style]] spin-offs or new, linked article for related material. This is acceptable, and often encouraged, as a way of making articles clearer and easier to manage.

A '''point of view (POV) fork''' is a content fork deliberately created to avoid [[WP:NPOV|neutral point of view]] guidelines, often to avoid or highlight negative or positive viewpoints or facts. All POV forks are undesirable on Wikipedia, as they avoid consensus building and therefore violate one of our most important policies.

==Unacceptable types of forking==

====Redundant content forks====
{{shortcut|WP:REDUNDANTFORK}}
Content forking can be unintentional or intentional. While Wikipedia contributors are reminded to check to make sure there is not an existing article on the subject before they start a new article, there is always the chance they will forget, or that they will search in good faith but fail to find an existing article, or simply flesh out a derivative article rather than the main article on a topic. Wikipedia's principle of [[Wikipedia:assume good faith|assume good faith]] should be kept in mind here. If you suspect a content fork, give the creator of a duplicate article the benefit of the doubt. Check with people who watch the respective articles and participate in talk page discussions to see if the fork was deliberate. If the content fork was unjustified, the more recent article should be [[WP:MERGE|merge]]d back into the main article.

====Point of view (POOV) forks====
{{shortcut|WP:POVFORK|WP:POVSPLIT}}
In contrast, POV forks generally arise when contributors disagree about the content of an article or other page. Instead of resolving that disagreement by consensus, another version of the article (or another article on the same subject) is created to be developed according to a particular [[WP:POV|point of view]]. This second article is known as a "POV fork" of the first, and is inconsistent with Wikipedia policies. The generally accepted policy is that all facts and major points of view on a certain subject should be treated in one article. As Wikipedia does ''not'' view article forking as an acceptable solution to disagreements between contributors, such forks may be [[Help:Merging and moving pages|merged]], or nominated for [[Wikipedia:Articles for deletion|deletion]].

Since what qualifies as a "POV fork" is itself based on a POV judgement, do not refer to forks as "POV" except in extreme cases of persistent disruptive editing. Instead, apply Wikipedia's policy that requires a [[WP:NPOV|neutral point of view]]: regardless of the reasons for making the fork, it still must be titled and written in a neutral point of view. It could be that the fork was a good idea, but was approached without balance, or that its creators mistakenly claimed [[WP:OWN|ownership]] over it.

The most blatant POV forks are those which insert consensus-dodging content under a title that should clearly be made a redirect to an existing article; in some cases, editors have even converted existing redirects into content forks. However, a new article can be a POV fork even if its title is not a synonym of an existing article's title. If one has tried to include one's personal theory that [[heavier-than-air flight]] is impossible in an existing article about [[aviation]], but the consensus of editors has rejected it as [[WP:patent nonsense|patent nonsense]], that does not justify creating an article named "Unanswered questions about heavier-than-air flight" to expound the rejected personal theory.

The creator of the new article may be sincerely convinced that there is so much information about a certain aspect of a subject that it justifies a separate article. Any daughter article that deals with opinions about the subject of parent article '''must''' include suitably-[[WP:WEIGHT|weight]]ed positive and negative opinions, and/or rebuttals, if available, and the original article should contain a neutral summary of the split article. There is currently no consensus whether a "Criticism of..." article is always a POV fork, but many criticism articles nevertheless suffer from POV problems. If possible, refrain from using "criticism" and instead use neutral terms such as "perception" or "reception"; if the word "criticism" must be used, make sure that such criticism considers both the merits '''and''' faults, and is not entirely negative (consider what would happen if a "Praise of..." article was created instead).

==Acceptable types of forking==

There are things that occur from time to time that may be mistaken for content forking.

Note that meeting one of the descriptions listed here does not mean that something is '''not''' a content fork – only that it is not ''necessarily'' a content fork.

===Project-level forking===
{{main|Wikipedia:Mirrors and forks}}

There is a difference between article forking within Wikipedia and the legitimate practice of project-level forking. The latter occurs when someone wishes to create their own wiki, according to their own standards and practices, but they want to use Wikipedia's content as a starting place. As long as the new project adheres to their legal obligations under the [[CC-BY-SA]] or [[GFDL]] in exchange for use of this content, as set out at [[WP:C|Wikipedia's copyright policy]], this is perfectly acceptable. Project-level forks are not bound in any way by Wikipedia's community policies or customs, like the [[WP:5P|five pillars]]. Project-level forking is discussed in more detail at [[Wikipedia:Forking FAQ]].

===Article spinouts: "Summary style" articles===
{{details|Wikipedia:Summary style}}
{{shortcut|WP:SPINOFF}}
Sometimes, when an article gets long (see [[Wikipedia:Article size]]), a section of the article is made into its own article, and the handling of the subject in the main article is condensed to a brief summary. This is completely normal Wikipedia procedure. The new article is sometimes called a "spinout" or "spinoff" of the main article; [[Wikipedia:Summary style]] explains the technique.

Even if the subject of the new article is controversial, this does '''not''' automatically make the new article a POV fork. However, the moved material ''must be'' replaced with an NPOV summary of that material. If it is not, then the "spinning out" is really a clear act of POV forking: a new article has been created so that the main article can favor some viewpoints over others.

Summary style articles, with sub-articles giving greater detail, are not POV forking, provided that all the sub-articles, and the summary, conform to [[WP:NPOV|Neutral Point of View]]. Essentially, it is generally acceptable to have different levels of detail of a subject on different pages, provided that each provides a balanced view of the subject matter. This can happen when a particular controversial incident gets a lot of attention from editors representing different points of view, expanding until every item of evidence is included and referenced. This kind of detailed examination of a single incident in a general article will usually be considered to give Undue Weight to the incident so it is more appropriate to break that section out as a separate section and just have a summary in the main article.

However, it is possible for article spinouts to become POV forks. If a statement is inadmissible for content policy reasons at an article <nowiki>[[XYZ]]</nowiki>, then it is also inadmissible at a spinout <nowiki>[[Criticism of XYZ]]</nowiki>. Spinouts are intended to improve readability and navigation, not to evade Wikipedia's content policies.

===Articles whose subject is a POV===
{{Shortcut|WP:SUBPOV}}
Different articles can be legitimately created on subjects which themselves represent points of view, as long as the title clearly indicates what its subject is, the point-of-view subject is presented [[WP:NPOV|neutrally]], and each article cross-references articles on other appropriate points of view. Thus [[Evolution]] and [[Creationism]], [[Capitalism]] and [[Communism]], [[Biblical literalism]] and [[Biblical criticism]], etc., all represent legitimate article subjects. As noted above, "Criticism of" type articles should generally start as sections of the main article and be spun off by agreement among the editors.

===Related articles===
{{shortcut|WP:RELART}}
Articles on distinct but related topics may well contain a significant amount of information in common with one another. This does not make either of the two articles a content fork. As an example, clearly [[Joséphine de Beauharnais]] will contain a significant amount of information also in [[Napoleon I of France]]; this does not make it a fork. Another example is where two articles cover the same topic, but are clearly ''directed at different audiences''. In such cases, one of the articles will be prefixed by the text [[Wikipedia:Make technical articles understandable#"Introduction to..." articles|"Introduction to ..."]], for example [[General relativity]] and [[Introduction to general relativity]].

Further, in encyclopedias it is perfectly proper to have separate articles for each '''different''' definition of a ''term''; unlike dictionaries, a single [[encyclopedia article]] covers a ''topic'', not a ''term''.

===Temporary subpages===
{{main|Wikipedia:Subpages}}

One technique sometimes used to reach consensus on difficult articles is to create a temporary copy which people can then edit to show others proposed rephrasing or other changes. This can be helpful for controversial subjects or controversial changes; editors can show others exactly what their vision for a proposed change is – without the controversy of having that new proposed version automatically replace the existing version.

However, just as "spinout" articles have sometimes been mistaken for POV forks, temporary subpages have been mistaken for POV forks. Care should be taken on both sides to minimize such mistakes. New drafts should be written in the "user:" or "talk:" [[wikipedia:namespace|namespace]] and '''not in the [[main namespace]]'''; however, accidents happen and those who think they have found a POV fork, in turn, should check to see whether the article title indicates a temporary subpage and whether the talk page of the main article indicates that this is a place to work on consensus rather than to dodge it.

==See also==
* [[Wikipedia:Be neutral in form]]
* [[Wikipedia:Criticism]] (essay on the way criticism can be included in Wikipedia articles)
* [[Wikipedia:Splitting]]
* [[Wikipedia:Tendentious editing]]
* [[Wikipedia:Forking isn't as harmful as we think]]

[[Category:Wikipedia neutral point of view]]

[[af:Wikipedia:Duplikate]]
[[ar:ويكيبيديا:تشعب وجهات النظر]]
[[fa:ویکی‌پدیا:انشعاب محتوا]]
[[kk:Уикипедия:Мақаланы жеке мақалаларға бөлу]]
[[no:Wikipedia:Artikkelforgrening]]
[[ru:Википедия:Ответвление мнений]]
[[zh:Wikipedia:內容分歧]]

2012-10-14T22:33:50Z

Code-structure: ←Created page with '{{User sandbox}}  Grammar of the '''C++''' language is available as part of the standard.'

{{User sandbox}}

Grammar of the '''C++''' language is available as part of the standard.

C++11

2012-10-14T22:31:29Z

Code-structure: Better language.

{{ multiple issues
| refimprove = July 2012
| lead too short = July 2012
}}
{{manual|date=July 2012}}

'''C++11''' (formerly known as '''C++0x'''<ref>http://video.google.com/videoplay?docid=5262479012306588324#</ref>) is the most recent version of the standard of the [[C++ programming language]]. It was approved by [[International Organization for Standardization|ISO]] on 12 August 2011, replacing [[C++03]].<ref>{{cite web|title=We have an international standard: C++0x is unanimously approved|url=http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/| accessdate=12 August 2011}}</ref> The name is derived from the tradition of naming language versions by the year of the specification's publication.

C++11 includes several additions to the [[core language]] and extends the [[C++ standard library]], incorporating most of the [[C++ Technical Report 1]] (TR1) [[Library (computer science)|libraries]] — with the exception of the library of mathematical special functions.<ref>{{cite web|title=Bjarne Stroustrup: A C++0x overview|url=http://www.research.ibm.com/arl/seminar/media/stroustrup.pdf| accessdate=30 June 2011}}</ref> C++11 was published as ''ISO/IEC 14882:2011''<ref>{{ cite web | authorlink = ISO | title = ISO/IEC 14882:2011 | publisher = ISO | date = 2 September 2011 | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372 | accessdate =3 September 2011 }}</ref> in September 2011 and is available for a fee. The working draft most similar to the published C++11 standard is N3337, dated 12 January 2012;<ref>[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf]</ref> it has only editorial corrections from the C++11 standard.<ref>http://stackoverflow.com/a/4653479/734069</ref>

==Changes from the previous version of the standard==
The modifications for C++ involve both the core language and the standard library.

In the development of every utility of the 2011 standard, the committee has applied some directives:
* Maintain stability and compatibility with [[ISO/IEC 14882|C++98]] and possibly with [[C (programming language)|C]];
* Prefer introduction of new features through 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 to 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 (additional support required 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 they will always compose the majority of computer programmers, and because many beginners would not intend to extend their knowledge of {{nowrap|C++}}, limiting themselves to operate in the aspects of the language in which they are specialized.{{Ref|web-strou-brief}}

==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 [[Thread (computer science)|multithreading]] support, [[generic programming]] support, uniform initialization, and performance enhancements.

For the purposes of this article, core language features and changes are grouped into four general sections: run-time performance enhancements, build-time performance enhancements, usability enhancements, and new functionality. Some features could fall into multiple groups, but they are mentioned only in the group that primarily represents that feature.

==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 "[[value (computer science)|rvalue]]s", 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 <code>const T&</code> types; nevertheless, in some cases, temporaries could have been modified, a behavior that was even considered to be a useful loophole (for the former, see <ref name="Sutter_Alexandrescu">Sutter, Alexandrescu "C++ coding standards" #15</ref>). C++11 adds a new non-const reference type called an {{visible anchor|rvalue reference}}, identified by <code>T&&</code>. 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 unnecessary deep copies that can happen implicitly when objects are passed by value. To illustrate the issue, consider that a <code>std::vector<T></code> is, internally, a wrapper around a C-style array with a size. If a <code>std::vector<T></code> temporary is created or returned from a function, it can be stored only by creating a new <code>std::vector<T></code> and copying all of 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 [[b:More C++ Idioms/Move Constructor|{{visible anchor|move constructor}}]] of <code>std::vector<T></code> that takes an rvalue reference to a <code>std::vector<T></code> can copy the pointer to the internal C-style array out of the rvalue into the new <code>std::vector<T></code>, 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 a <code>std::vector<T></code> temporary does not need to be changed explicitly to <code>std::vector<T> &&</code> to invoke the move constructor, as temporaries are considered rvalues automatically. (However, if <code>std::vector<T></code> is a C++03 version without a move constructor, then the copy constructor will be invoked with a <code>const std::vector<T>&</code>, 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; in order to get an rvalue, the function template <code>std::move<T>()</code> 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|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 [http://en.cppreference.com/w/cpp/container/vector/emplace_back 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 <code>3+4</code> 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, there are a number of places where the C++ specification requires the use of 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 illegal:

<source lang="cpp">
int get_five() {return 5;}

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

This was not legal in C++03, because <code>get_five() + 7</code> is not a constant expression. A C++03 compiler has no way of knowing if <code>get_five()</code> 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 <code>constexpr</code>, which allows the user to guarantee that a function or object constructor is a compile-time constant.<ref>{{cite web|url=http://www.stroustrup.com/sac10-constexpr.pdf|title=General Constant Expressions for System Programming Languages, Proceedings SAC ’10 | author=Gabriel Dos Reis and Bjarne Stroustrup |date=22 March 2010}}</ref> The above example can be rewritten as follows:

<source lang="cpp">
constexpr int get_five() {return 5;}

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

This allows the compiler to understand, and verify, that <code>get_five</code> is a compile-time constant.

The use of <code>constexpr</code> on a function imposes some limitations 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.

Prior to 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 <code>constexpr</code> keyword:

<source lang="cpp">
constexpr double earth_gravitational_acceleration = 9.8;
constexpr double moon_gravitational_acceleration = earth_gravitational_acceleration / 6.0;
</source>

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

In order to construct constant expression data values from user-defined types, constructors can also be declared with <code>constexpr</code>. A <code>constexpr</code> constructor's function body can contain only declarations and null statements, and cannot declare variables or define types, as with a <code>constexpr</code> 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 <code>constexpr</code> constructors should usually also be defined as a <code>constexpr</code> constructor, in order 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 <code>constexpr</code>, so long as they meet the requirements for constexpr functions. This allows the compiler to copy classes 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 particular invocation, the result is not a constant expression.

===Modification to the definition of plain old data===
In C++03, a class or struct must follow a number of rules in order for it to be considered a [[Plain Old Data Structures|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. However, the definition in C++03 is unnecessarily strict{{citation needed|date=April 2012}} and there are good reasons{{clarify|date=April 2012}} for allowing more types to fit the POD definition{{citation needed|date=April 2012}}.

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 legal to copy data around via <code>memcpy</code>, 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:

# Has a trivial default constructor. This may use the [[#Explicitly defaulted and deleted special member functions|default constructor syntax]] (<code>SomeConstructor() = default;</code>).
# Has trivial copy and move constructors, which may use the default syntax.
# Has trivial copy and move assignment operators, which may use the default syntax.
# 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 that all of the non-static data members 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:

# It has no virtual functions
# It has no virtual base classes
# All its non-static data members have the same access control (public, private, protected)
# All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
# The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
# 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 interop with C. Similarly, a class with public and private non-static data members would not be standard-layout, but it would be trivial and thus <code>memcpy</code>-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:

<source lang="cpp">
template class std::vector<MyClass>;
</source>

C++11 now provides this syntax:

<source lang="cpp">
extern template class std::vector<MyClass>;
</source>

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 curly brackets, 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.

<source lang="cpp">
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
</source>

This is very useful for static lists or just for initializing a struct to a particular 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 <code>std::vector</code>.

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

<source lang="cpp">
class SequenceClass {
public:
SequenceClass(std::initializer_list<int> list);
};
</source>

This allows <code>SequenceClass</code> to be constructed from a sequence of integers, as such:

<source lang="cpp">
SequenceClass some_var = {1, 4, 5, 6};
</source>

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 [[#Uniform_initialization|below]])

The class <code>std::initializer_list<></code> is a first-class C++11 standard library type. However, they can be initially constructed statically by the C++11 compiler only through the use of the {} syntax. The list can be copied once constructed, though this is only a copy-by-reference. An initializer list is constant; its members cannot be changed once the initializer list is created, nor can the data in those members be changed.

Because initializer_list is a real type, it can be used in other places besides class constructors. Regular functions can take typed initializer lists as arguments. For example:

<source lang="cpp">
void function_name(std::initializer_list<float> list);

function_name({1.0f, -3.45f, -0.4f});
</source>

Standard containers can also be initialized in the following ways:
<source lang="cpp">
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
</source>

===Uniform initialization===
C++03 has a number of problems with initializing types. There are several ways to initialize types, and they do not all produce the same 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 <code>SomeType var = {/*stuff*/};</code>).

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

<source lang="cpp">
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};
</source>

The initialization of <code>var1</code> 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 necessary. If no conversion exists, or only a narrowing conversion exists, the program is ill-formed. The initialization of <code>var2</code> invokes the constructor.

One is also able to do the following:

<source lang="cpp">

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

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

Uniform initialization does not replace constructor syntax. There are still times when constructor syntax is required. If a class has an initializer list constructor (<code>TypeName(initializer_list<SomeType>);</code>), 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 <code>std::vector</code> has an initializer list constructor for its template type. This means that the following code:

<source lang="cpp">
std::vector<int> the_vec{4};
</source>

will call the initializer list constructor, not the constructor of <code>std::vector</code> 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), the type of a variable must be explicitly specified in order to use it. 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. Therefore, storing intermediates in variables is difficult, possibly requiring knowledge of the internals of a particular 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 <code>auto</code> keyword. This creates a variable of the specific type of the initializer:

<source lang="cpp">
auto some_strange_callable_type = boost::bind(&some_function, _2, _1, some_object);
auto other_variable = 5;
</source>

The type of <code>some_strange_callable_type</code> is simply whatever the particular template function override of <code>boost::bind</code> 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 <code>other_variable</code> is also well-defined, but it is easier for the user to determine. It is an <code>int</code>, which is the same type as the integer literal.

Additionally, the keyword <code>[[decltype]]</code> can be used to determine the type of an expression at compile-time. For example:

<source lang="cpp">
int some_int;
decltype(some_int) other_integer_variable = 5;
</source>

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

<code>auto</code> is also useful for reducing the verbosity of the code. For instance, instead of writing
<source lang="cpp">
for (std::vector<int>::const_iterator itr = myvec.cbegin(); itr != myvec.cend(); ++itr)
</source>
the programmer can use the shorter
<source lang="cpp">
for (auto itr = myvec.cbegin(); itr != myvec.cend(); ++itr)
</source>

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

The type denoted by <code>decltype</code> can be different from the type deduced by <code>auto</code>.
<source lang="cpp">
#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
}
</source>

===Range-based for-loop===
In C++03, iterating over the elements of a list requires a lot of code. Other languages have implemented support for [[syntactic sugar]] that allow the programmer to write a simple “foreach” statement that automatically traverses items in a list.
One of those languages is the [[Java (programming language)|Java]] programming language, which received support for what has been defined as enhanced for loops in [[Java version history#J2SE 5.0 .28September_30.2C_2004.29|Java 5.0]].<ref>{{cite web|url=http://docs.oracle.com/javase/1.5.0/docs/guide/language/index.html |title=Java Programming Language: Enhancements in JDK 5 |publisher=Oracle.com}}</ref>

C++11 added a similar feature. The statement <code>for</code> allows for easy iteration over a list of elements:

<source lang="cpp">
int my_array[5] = {1, 2, 3, 4, 5};
for (int &x : my_array) {
x *= 2;
}
</source>

This form of <code>for</code>, 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 <code>begin()</code> and <code>end()</code> functions defined for it that return iterators. All of the standard library containers that have begin/end pairs will work with the range-based for statement.

===Lambda functions and expressions===
{{main|Anonymous function#C++}}

C++11 provides the ability to create [[anonymous function]]s, called lambda functions.<ref>
{{cite web
|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf
|title=Document no: N1968=06-0038- Lambda expressions and closures for C++
|publisher=Open Standards
}}</ref>
These are defined as follows:

<source lang="cpp">
[](int x, int y) { return x + y; }
</source>

The return type is implicit; it returns the type of the return expression (<code>decltype(x+y)</code>). The return type of a lambda can be omitted as long as all <code>return</code> expressions return the same type.
A lambda can optionally be a [[Closure (computer science)|closure]].

===Alternative function syntax===
[[C (programming language)|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 necessary. However, as C++ became more complicated, it exposed a number of limitations, particularly with regard to template function declarations. The following, for example, is not allowed in C++03:

<source lang="cpp">
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
</source>

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

<source lang="cpp">
template<class Lhs, class Rhs>
decltype(lhs+rhs) adding_func(const Lhs &lhs, const Rhs &rhs) {return lhs + rhs;} //Not legal C++11
</source>

This is not legal C++ because <code>lhs</code> and <code>rhs</code> 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'':

<source lang="cpp">
template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}
</source>

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

<source lang="cpp">
struct SomeStruct {
auto func_name(int x, int y) -> int;
};

auto SomeStruct::func_name(int x, int y) -> int {
return x + y;
}
</source>

The use of the keyword “auto” in this case means something different from its use in automatic type deduction.

===Object construction improvement===
In C++03, constructors of a class are not allowed to call other constructors of that class; each constructor must construct all of its class members itself or call a common member function, like these,

<source lang="cpp">
class SomeType {
int number;

public:
SomeType(int new_number) : number(new_number) {}
SomeType() : number(42) {}
};
</source>

<source lang="cpp">
class SomeType {
int number;

private:
void Construct(int new_number) { number = new_number; }
public:
SomeType(int new_number) { Construct(new_number); }
SomeType() { Construct(42); }
};
</source>

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 (known as [[Delegation (programming)|delegation]]). This allows constructors to utilize another constructor's behavior with a minimum of added code. Examples of other languages similar to C++ that provide delegation are [[Java (programming language)|Java]], [[C Sharp (programming language)|C#]], and [[D (programming language)|D]].

This syntax is as follows:

<source lang="cpp">
class SomeType {
int number;

public:
SomeType(int new_number) : number(new_number) {}
SomeType() : SomeType(42) {}
};
</source>

Notice that, in this case, the same effect could have been achieved by making new_number a defaulting 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 delegate 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. This means that the C++11 compiler will generate code to perform the inheritance, the forwarding of the derived class to the base class. Note that this is an all-or-nothing feature; either all of that base class's constructors are forwarded or none of them are. Also, note that there are restrictions for multiple inheritance, such that class constructors cannot be inherited from two classes that use constructors with the same signature. Nor can a constructor in the derived class exist that matches a signature in the inherited base class.

The syntax is as follows:

<source lang="cpp">
class BaseClass {
public:
BaseClass(int value);
};

class DerivedClass : public BaseClass {
public:
using BaseClass::BaseClass;
};
</source>

For member initialization, C++11 allows the following syntax:

<source lang="cpp">
class SomeClass {
public:
SomeClass() {}
explicit SomeClass(int new_value) : value(new_value) {}

private:
int value = 5;
};
</source>

Any constructor of the class will initialize <code>value</code> with 5, if the constructor does not override the initialization with its own. So the above empty constructor will initialize <code>value</code> 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 equality 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:

<source lang="cpp">
struct Base {
virtual void some_func(float);
};

struct Derived : Base {
virtual void some_func(int);
};
</source>

The <code>Derived::some_func</code> is intended to replace the base class version. But because it has a different interface, 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.

<source lang="cpp">
struct Base {
virtual void some_func(float);
};

struct Derived : Base {
virtual void some_func(int) override; // ill-formed because it doesn't override a base class method
};
</source>

The <code>override</code> 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 error out.

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 <code>final</code>. For example:

<source lang="cpp">
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
};
</source>

In this example, the <code>virtual void f() final;</code> 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.

Note that neither <code>override</code> nor <code>final</code> are language keywords. They are technically identifiers; they gain special meaning only when used in those specific contexts. In any other location, they can be valid identifiers.

===Null pointer constant===
For the purposes of this section and this section alone, every occurrence of “<code>0</code>” is meant as “a constant expression which evaluates to <code>0</code>, 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 <code>[[0 (number)|0]]</code> has had the double role of constant integer and null pointer constant. The ambiguity inherent in the double meaning of <code>0</code> was dealt with in C by the use of the preprocessor macro <code>NULL</code>, which commonly expands to either <code>((void*)0)</code> or <code>0</code>. C++ didn't adopt the same behavior, allowing only <code>0</code> as a null pointer constant. This interacts poorly with function overloading:

<source lang="cpp">
void foo(char *);
void foo(int);
</source>

If <code>NULL</code> is defined as <code>0</code> (which is usually the case in C++), the statement <code>foo(NULL);</code> will call <code>foo(int)</code>, 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: <code>nullptr</code>. It is of type <code>nullptr_t</code>, 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 <code>bool</code>. While the original proposal specified that an rvalue of type <code>nullptr</code> should not be convertible to <code>bool</code>, 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.{{Ref|n2697}}

For backwards compatibility reasons, <code>0</code> remains a valid null pointer constant.

<source lang="cpp">
char *pc = nullptr; // OK
int *pi = nullptr; // OK
bool b = nullptr; // OK. b is false.
int i = nullptr; // error

foo(nullptr); // calls foo(char *), not foo(int);
</source>

===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. Additionally, the underlying integral type is implementation-defined; code that depends on the size of the enumeration is therefore non-portable. Lastly, enumeration values are scoped to the enclosing scope. Thus, it is not possible for two separate enumerations to have matching member names.

C++11 allows a special classification of enumeration that has none of these issues. This is expressed using the <code>enum class</code> (<code>enum struct</code> is also accepted as a synonym) declaration:

<source lang="cpp">
enum class Enumeration {
Val1,
Val2,
Val3 = 100,
Val4 // = 101
};
</source>

This enumeration is type-safe. Enum class values are not implicitly converted to integers; therefore, they cannot be compared to integers either (the expression <code>Enumeration::Val4 == 101</code> gives a compiler error).

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

<source lang="cpp">
enum class Enum2 : unsigned int {Val1, Val2};
</source>

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, <code>Val1</code> is undefined, but <code>Enum2::Val1</code> is defined.

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

<source lang="cpp">
enum Enum3 : unsigned long {Val1 = 1, Val2};
</source>

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

Forward-declaring enums is also possible in C++11. Previously, 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:

<source lang="cpp">
enum Enum1; // Illegal in C++03 and C++11; the underlying type cannot be determined.
enum Enum2 : unsigned int; // Legal in C++11, the underlying type is explicitly specified.
enum class Enum3; // Legal in C++11, the underlying type is int.
enum class Enum4 : unsigned int; // Legal in C++11.
enum Enum2 : unsigned short; // Illegal in C++11, because Enum2 was previously declared with a different underlying type.
</source>

===Right angle bracket===
C++03's parser defines “<code>>></code>” as the right shift 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:

<source lang="cpp">
template<bool Test> class SomeType;
std::vector<SomeType<1>2>> x1; // Interpreted as a std::vector of SomeType<true> 2>,
// which is not legal syntax. 1 is true.
std::vector<SomeType<(1>2)>> x1; // Interpreted as std::vector of SomeType<false>,
// which is legal C++11 syntax. (1>2) is false.
</source>

===Explicit conversion operators===
C++98 added the <code>explicit</code> 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 <code>operator bool()</code> to allow it to act more like a primitive pointer: if it includes this conversion, it can be tested with <code>if (smart_ptr_variable)</code> (which would be true if the pointer was non-null and false otherwise). However, this allows other, unintended conversions as well. Because C++ <code>bool</code> 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 <code>explicit</code> keyword can now be applied to conversion operators. As with constructors, it prevents the use of those conversion functions in implicit conversions. However, language contexts that specifically require a boolean value (the conditions of if-statements and loops, as well as operands to the logical operators) count as explicit conversions and can thus use a bool conversion operator.

===Alias templates===

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:

<source lang="cpp">
template <typename First, typename Second, int Third>
class SomeType;

template <typename Second>
typedef SomeType<OtherType, Second, 5> TypedefName; //Illegal in C++03
</source>

This will not compile.

C++11 adds this ability with the following syntax:

<source lang="cpp">
template <typename First, typename Second, int Third>
class SomeType;

template <typename Second>
using TypedefName = SomeType<OtherType, Second, 5>;
</source>

The <code>using</code> syntax can be also used as type aliasing in C++11:
<source lang="cpp">
typedef void (*Type)(double); // Old style
using OtherType = void (*)(double); // New introduced syntax
</source>

===Unrestricted unions===
In C++03, there are restrictions on what types of objects can be members of a <code>union</code>. For example, unions cannot contain any objects that define a non-trivial constructor. C++11 lifts some of these restrictions.{{Ref|n2544}}

* Unions can now contain objects that have a non-trivial constructor.
* If so, the implicit default constructor of the union is deleted, forcing a manual definition.

This is a simple example of a union permitted in C++11:
<source lang="cpp">
#include <new> // Required 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; // Illegal in C++03; legal in C++11.
//
// Due to the Point member, a constructor definition is now required.
//
U() {new(&p) Point();}
};
</source>

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 previously impossible, exceedingly verbose, or required non-portable libraries.

===Variadic templates===
{{main|variadic templates}}

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

===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 <code>const char</code>. The second kind, defined as <code>L""</code>, produces a null-terminated array of type <code>const wchar_t</code>, where <code>wchar_t</code> 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]] [[Comparison of Unicode encodings|encodings]].

For the purpose of enhancing support for Unicode in C++ compilers, the definition of the type <code>char</code> has been modified to be both at least the size necessary 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 previously defined as only the latter.

There are three Unicode encodings that C++11 will support: [[UTF-8]], [[UTF-16]], and [[UTF-32]]. In addition to the previously noted changes to the definition of <code>char</code>, C++11 adds two new character types: <code>char16_t</code> and <code>char32_t</code>. These are designed to store UTF-16 and UTF-32 respectively.

The following shows how to create string literals for each of these encodings:

<source lang="cpp">
u8"I'm a UTF-8 string."
u"This is a UTF-16 string."
U"This is a UTF-32 string."
</source>

The type of the first string is the usual <code>const char[]</code>. The type of the second string is <code>const char16_t[]</code>. The type of the third string is <code>const char32_t[]</code>.

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

<source lang="cpp">
u8"This is a Unicode Character: \u2018."
u"This is a bigger Unicode Character: \u2018."
U"This is a Unicode Character: \u2018."
</source>

The number after the <code>\u</code> is a hexadecimal number; it does not need the usual <code>0x</code> prefix. The identifier <code>\u</code> represents a 16-bit Unicode codepoint; to enter a 32-bit codepoint, use <code>\U</code> and a 32-bit hexadecimal number. Only valid Unicode codepoints can be entered. For example, codepoints 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:

<pre>
R"(The String Data \ Stuff " )"
R"delimiter(The String Data \ Stuff " )delimiter"
</pre>

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

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

<pre>
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.)"
</pre>

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

C++11 also includes the ability for the user to define new kinds of literal modifiers that will construct objects based on the string of characters that the literal modifies.

Literals transformation 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 <code>1234</code>, as a raw literal, is this sequence of characters <code>'1'</code>, <code>'2'</code>, <code>'3'</code>, <code>'4'</code>. As a cooked literal, it is the integer 1234. The C++ literal <code>0xA</code> in raw form is <code>'0'</code>, <code>'x'</code>, <code>'A'</code>, 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.

User-defined literals processing the raw form of the literal are defined as follows:

<source lang="cpp">
OutputType operator "" _suffix(const char * literal_string);

OutputType some_variable = 1234_suffix;
</source>

The second statement executes the code defined by the user-defined literal function. This function is passed <code>"1234"</code> as a C-style string, so it has a null terminator.

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

<source lang="cpp">
template<char...> OutputType operator "" _suffix();

OutputType some_variable = 1234_suffix;
OutputType another_variable = 2.17_suffix;
</source>

This instantiates the literal processing function as <code>operator "" _suffix<'1', '2', '3', '4'>()</code>. In this form, there is no terminating null character to the string. The main purpose to doing this is to use C++11's <code>constexpr</code> keyword and the compiler to allow the literal to be transformed entirely at compile time, assuming <code>OutputType</code> is a constexpr-constructable and copyable type, and the literal processing function is a <code>constexpr</code> function.

For numeric literals, the type of the cooked literal is either <code>unsigned long long</code> for integral literals or <code>long double</code> for floating point literals. (Note: There is no need for signed integral types because a sign-prefixed literal is parsed as expression containing the sign as unary prefix operator and the unsigned number.) There is no alternative template form:

<source lang="cpp">
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.
</source>

For string literals, the following are used, in accordance with the previously mentioned new string prefixes:

<source lang="cpp">
OutputType operator "" _suffix(const char * string_values, size_t num_chars);
OutputType operator "" _suffix(const wchar_t * string_values, size_t num_chars);
OutputType operator "" _suffix(const char16_t * string_values, size_t num_chars);
OutputType operator "" _suffix(const char32_t * string_values, size_t num_chars);

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

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

===Multithreading memory model===
{{See also|Memory model (computing)}}
The C++11 standardizes support for [[Thread (computer science)|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|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 [[Variable (programming)|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|''thread-local'']] storage duration (in addition to the existing ''static'', ''dynamic'' and ''automatic'') is indicated by the storage specifier <code>thread_local</code>.

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 and deleted 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 (<code>operator=</code>), and a destructor. The programmer can override these defaults by defining custom versions. C++ also defines several global operators (such as <code>operator=</code> and <code>operator new</code>) that work on all classes, which the programmer can override.

However, there is very little control over the creation of these defaults. Making a class inherently non-copyable, for example, requires 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,<ref name="C++03 3.2/3">[[ISO]]/[[International Electrotechnical Commission|IEC]] (2003). ''[[ISO/IEC 14882|ISO/IEC 14882:2003(E): Programming Languages - C++]] §3.2 One definition rule [basic.def.odr]'' para. 3</ref> this typically results in a linker error.{{Citation needed|date=June 2009}}

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. For example, the following type explicitly declares that it is using the default constructor:

<source lang="cpp">
struct SomeType {
SomeType() = default; //The default constructor is explicitly stated.
SomeType(OtherType value);
};
</source>

Alternatively, certain features can be explicitly disabled. For example, the following type is non-copyable:

<source lang="cpp">
struct NonCopyable {
NonCopyable & operator=(const NonCopyable&) = delete;
NonCopyable(const NonCopyable&) = delete;
NonCopyable() = default;
};
</source>

The <code>= delete</code> specifier can be used to prohibit calling any function, which can be used to disallow calling a member function with particular parameters. For example:
<source lang="cpp">
struct NoInt {
void f(double i);
void f(int) = delete;
};
</source>

An attempt to call <code>f()</code> with an <code>int</code> will be rejected by the compiler, instead of performing a silent conversion to <code>double</code>. This can be generalized to disallow calling the function with any type other than <code>double</code> as follows:
<source lang="cpp">
struct OnlyDouble {
void f(double d);
template<class T> void f(T) = delete;
};
</source>

===Type <code>long long int</code>===
In C++03, the largest integer type is <code>long int</code>. It is guaranteed to have at least as many usable bits as <code>int</code>. This resulted in <code>long int</code> having size of 64 bits on some popular implementations and 32 bits on others. C++11 adds a new integer type <code>long long int</code> to address this issue. It is guaranteed to be at least as large as a <code>long int</code>, and have no fewer than 64 bits. The type was originally introduced by [[C99]] to the standard C, and most C++ compilers support it as an extension already.<ref>http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html</ref><ref>http://msdn.microsoft.com/en-us/library/s3f49ktz(VS.80).aspx</ref>

===Static assertions===
C++03 provides two methods to test [[Assertion (computing)|assertions]]: the macro <code>assert</code> and the preprocessor directive <code>#error</code>. 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 <code>static_assert</code>.
The declaration assumes the following form:
static_assert (''constant-expression'', ''error-message'');

Here are some examples of how <code>static_assert</code> can be used:
<source lang="cpp">
static_assert((GREEKPI > 3.14) && (GREEKPI < 3.15), "GREEKPI is inaccurate!");
</source>
<source lang="cpp">
template<class T>
struct Check {
static_assert(sizeof(int) <= sizeof(T), "T is not big enough!");
};
</source>
<source lang="cpp">
template<class Integral>
Integral foo(Integral x, Integral y) {
static_assert(std::is_integral<Integral>::value, "foo() parameter must be an integral type.");
}
</source>

When the constant expression is <code>false</code> the compiler produces an error message. The first example represents an alternative to the preprocessor directive <code>#error</code>, in contrast in the second example the assertion is checked at every instantiation of the template class <code>Check</code>.

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

===Allow <code>sizeof</code> to work on members of classes without an explicit object===
In C++03, the <code>sizeof</code> operator can be used on types and objects. But it cannot be used to do the following:

<source lang="cpp">
struct SomeType { OtherType member; };

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

This should return the size of <code>OtherType</code>. C++03 does not allow this, so it is a compile error. C++11 does allow it.

===Control and query object alignment===
C++11 allows variable alignment to be queried and controlled with <code>alignof</code> and <code>alignas</code>.

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

The <code>alignas</code> specifier controls the memory alignment for a variable. The specifier takes a constant or a type; when supplied a type <code>alignas(T)</code> is short hand for <code>alignas(alignof(T))</code>. For example, to specify that a char array should be properly aligned to hold a float:
<source lang="cpp">
alignas(float) unsigned char c[sizeof(float)]
</source>

===Allow garbage collected implementations===
In previous C++ standards, a conforming implementation could not collect objects even if no pointer to the object remained because pointers might still exist in some encoded form (e.g., as strings). C++11 changes language semantics to make garbage collection possible. {{citation needed|date=August 2012}} It is still implementation-defined whether unreachable dynamically allocated objects actually are automatically reclaimed.

==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 [[Library (computer science)|libraries]] was defined in the document ''[[Technical Report 1|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 <code>std::tr1</code>. For C++11 they were moved to namespace <code>std</code>. 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.

The committee intends to create a second technical report (called TR2) now that standardization of C++11 is complete. Library proposals which were not ready in time for C++11 will be put into TR2 or further technical reports.

===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
* <code>[[decltype]]</code>
* <code>explicit</code> conversion operators
* <code>default</code>/<code>delete</code>d functions

Additionally, much time has passed since the previous C++ standard. A great deal of code using the standard library has been written; this has revealed portions of the standard libraries that could use some improvement. Among the many areas of improvement considered were standard library [[Allocator (C++)|allocator]]s. A new scope-based model of allocators was included in C++11 to supplement the previous model.

===Threading facilities===
While the C++11 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 (<code>std::thread</code>) 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 through the <code>std::thread::join()</code> member function. Access is provided, where feasible, to the underlying native thread object(s) for [[Platform (computing)|platform]] specific operations by the <code>std::thread::native_handle()</code> member function.

For synchronization between threads, appropriate [[Mutual exclusion|mutexes]] (<code>std::mutex</code>, <code>std::recursive_mutex</code>, etc.) and [[Monitor (synchronization)|condition variables]] (<code>std::condition_variable</code> and <code>std::condition_variable_any</code>) are added to the library. These are accessible through [[Resource Acquisition Is Initialization|RAII]] locks (<code>std::lock_guard</code> and <code>std::unique_lock</code>) and locking algorithms for easy use.

For high-performance, low-level work, it is sometimes necessary to communicate between threads without the overhead of mutexes. This is achieved using [[atomic operation]]s on memory locations. These can optionally specify the minimum memory visibility constraints required for an operation. Explicit [[memory barrier]]s may also be used for this purpose.

The C++11 thread library also includes [[futures and promises]] for passing asynchronous results between threads, and <code>std::packaged_task</code> 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.<ref>{{Cite web
| last = Milewski
| first = Bartosz
| title = Broken promises–C++0x futures
| date = 3 March 2009
| url = http://bartoszmilewski.wordpress.com/2009/03/03/broken-promises-c0x-futures/
| accessdate =24 January 2010}}</ref>

Further high-level threading facilities such as [[thread pool]]s have been remanded to a future C++ [[Technical Report 1|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 <code>std::async</code> facility provides a convenient method of running tasks and tying them to a <code>std::future</code>. 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|variadic templates]]. The TR1 version required an implementation-defined maximum number of contained types, and required substantial macro trickery to implement reasonably. 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:
<source lang="cpp">
template <class ...Types> class tuple;
</source>

An example of definition and use of the tuple type:
<source lang="cpp">
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.
</source>

It’s possible to create the tuple <code>proof</code> 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, it is necessary that each element type possesses a copy constructor; otherwise, it is necessary that each element type of the right-side tuple is 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.
<source lang="cpp">
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 *'.
</source>

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):
*<code>std::tuple_size<nowiki><T></nowiki>::value</code> returns the number of elements in the tuple <code>T</code>,
*<code>std::tuple_element<nowiki><I, T></nowiki>::type</code> returns the type of the object number <code>I</code> of the tuple <code>T</code>.

===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 through ''[[Hash tables#Separate chaining|linear chaining]]'' because the committee didn't consider 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 <tt>unordered_</tt> prefix.

{| class="wikitable" style="text-align: center"
! Type of hash table !! Associated values !! Equivalent keys
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_set]]</code> || {{no}} || {{no}}
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_multiset]]</code> || {{no}} || {{yes}}
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_map]]</code> || {{yes}} || {{no}}
|-
| style="text-align: left" | <code>[[Unordered associative containers (C++)|std::unordered_multimap]]</code> || {{yes}} || {{yes}}
|}

New classes fulfill all the requirements of a [[Standard Template Library#Containers|container class]], and have all the methods necessary to access elements: <code>insert</code>, <code>erase</code>, <code>begin</code>, <code>end</code>.

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 <code><nowiki><functional></nowiki></code> and the introduction of headers <code><nowiki><unordered_set></nowiki></code> and <code><nowiki><unordered_map></nowiki></code>. 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 <code><nowiki><regex></nowiki></code>, is made of a couple of new classes:
*[[regular expressions]] are represented by instance of the template class <code>std::regex</code>;
*occurrences are represented by instance of the template class <code>std::match_results</code>.
The function <code>std::regex_search</code> is used for searching, while for ‘search and replace’ the function <code>std::regex_replace</code> is used which returns a new string.
The algorithms <code>std::regex_search</code> and <code>std::regex_replace</code> take a regular expression and a string and write the occurrences found in the struct <code>std::match_results</code>.

Here is an example of the use of <code>std::match_results</code>:
<source lang="cpp">
const char *reg_esp = "[ ,.\\t\\n;:]"; // List of separator characters.

// this can be done using raw string literals:
// const char *reg_esp = R"([ ,.\t\n;:])";

std::regex rgx(reg_esp); // 'regex' is an instance of the template class
// 'basic_regex' with argument of type 'char'.
std::cmatch match; // 'cmatch' is an instance of the template class
// 'match_results' with argument of type 'const char *'.
const char *target = "Unseen University - Ankh-Morpork";

// Identifies all words of 'target' separated by characters of 'reg_esp'.
if( std::regex_search( target, match, rgx ) ) {
// If words separated by specified characters are present.

const size_t n = match.size();
for( size_t a = 0; a < n; a++ ) {
std::string str( match[a].first, match[a].second );
std::cout << str << "\n";
}
}
</source>

Note the use of double [[backslash]]es, because C++ uses backslash as an escape character. The C++11 [[#New_string_literals|raw string]] feature could be used to avoid the problem.

The library <code><nowiki><regex></nowiki></code> requires neither alteration of any existing header (though it will use them where appropriate) nor an extension of the core language.

===General-purpose smart pointers===
{{main|Smart_pointer|l1=C++ Smart Pointers}}
C++11 provides {{code|std::unique_ptr}}, as well as improvements to {{code|std::shared_ptr}} and {{code|std::weak_ptr}} from TR1. {{code|std::auto_ptr}} is deprecated.

===Extensible random number facility===
The C standard library provides the ability to generate [[pseudorandom numbers]] through the function <code>rand</code>. However, the algorithm is delegated entirely to the library vendor. C++ inherited this functionality with no changes, but C++11 will provide 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 [[Distribution (mathematics)|mathematical distribution]] of the outcome. These two are combined to form a random number generator object.

Unlike the C standard <code>rand</code>, the C++11 mechanism will come with three base generator engine algorithms:
* <code>[[Linear congruential generator|linear_congruential_engine]]</code>,
* <code>[[Subtract with carry|subtract_with_carry_engine]]</code>, and
* <code>[[Mersenne twister|mersenne_twister_engine]]</code>.

C++11 will also provide a number of standard distributions:
* <code>[[Uniform distribution (discrete)|uniform_int_distribution]]</code>,
* <code>[[Uniform distribution (continuous)|uniform_real_distribution]]</code>,
* <code>[[Bernoulli distribution|bernoulli_distribution]]</code>,
* <code>[[Binomial distribution|binomial_distribution]]</code>,
* <code>[[Geometric distribution|geometric_distribution]]</code>,
* <code>[[Negative binomial distribution|negative_binomial_distribution]]</code>,
* <code>[[Poisson distribution|poisson_distribution]]</code>,
* <code>[[Exponential distribution|exponential_distribution]]</code>,
* <code>[[Gamma distribution|gamma_distribution]]</code>,
* <code>[[Weibull distribution|weibull_distribution]]</code>,
* <code>[[Generalized extreme value distribution|extreme_value_distribution]]</code>,
* <code>[[Normal distribution|normal_distribution]]</code>,
* <code>[[Lognormal distribution|lognormal_distribution]]</code>,
* <code>[[Chi squared distribution|chi_squared_distribution]]</code>,
* <code>[[Cauchy distribution|cauchy_distribution]]</code>,
* <code>[[F-distribution|fisher_f_distribution]]</code>,
* <code>[[Student's t-distribution|student_t_distribution]]</code>,
* <code>[[Discrete_distribution#Discrete_probability_distribution|discrete_distribution]]</code>,
* <code>[[Step function|piecewise_constant_distribution]]</code> and
* <code>[[Piecewise linear function|piecewise_linear_distribution]]</code>.

The generator and distributions are combined as in the following example:

<source lang="cpp">
#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.
</source>

===Wrapper reference===
A [[Adapter pattern|wrapper]] reference is obtained from an instance of the template class <code>reference_wrapper</code>. Wrapper references are similar to normal references (‘<code>&</code>’) of the C++ language. To obtain a wrapper reference from any object the function template <code>ref</code> is used (for a constant reference <code>cref</code> is used).

Wrapper references are useful above all for function templates, where references to parameters rather than copies are needed:
<source lang="cpp">
// This function will obtain 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 < 0

g (func, std::ref(i)); // 'g<void(int &r),reference_wrapper<int>>' is instantiated
// then 'i' will be modified.
std::cout < 1
}
</source>

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

===Polymorphic wrappers for function objects===
[[Type polymorphism|Polymorphic]] [[Adapter pattern|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.

Through the example it is possible to understand its characteristics:
<source lang="cpp">
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.
</source>

The template class <code>function</code> was defined inside the header <code><nowiki><functional></nowiki></code>, and didn't require any changes 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 that allows metaprogramming during compilation through templates.

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

<source lang="cpp">
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;
</source>

Many algorithms can operate on different types of data; C++'s [[Template (programming)|template]]s 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 <code><nowiki><type_traits></nowiki></code>.

In the next example there is the template function ‘elaborate’ that, depending on the given data types, will instantiate one of the two proposed algorithms (<code>algorithm.do_it</code>).

<source lang="cpp">
// 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 ) ;
}
</source>

Through '''type traits''', defined in header <code><nowiki><type_transform></nowiki></code>, it’s also possible to create type transformation operations (<code>static_cast</code> and <code>const_cast</code> are insufficient inside a template).

This type of programming produces elegant and concise code; however the weak point of these techniques is the debugging: 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:

<source lang="cpp">
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;
};
</source>

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

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

TR1 introduces, and C++11 adopts, the template class <code>std::result_of</code> that allows one to determine and use the return type of a function object for every declaration. The object <code>CalculusVer2</code> uses the <code>std::result_of</code> object to derive the return type of the function object:
<source lang="cpp">
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;
};
</source>
In this way in instances of function object of <code>CalculusVer2<nowiki><Confused></nowiki></code> there are no conversions, warnings, or errors.

The only change from the TR1 version of <code>std::result_of</code> 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 <code>[[#Type inference|decltype]]</code>, the C++11 version of <code>std::result_of</code> no longer needs these special cases; implementations are required to compute a type in all cases.

==Features originally planned but removed or not included==
Heading for a separate TR:
* [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf Modules]
* Decimal Types
* Math Special Functions
Postponed:
* [[Concepts (C++)|Concepts]]
* More complete or required garbage collection support
* Reflection
* Macro Scopes

==Features removed or deprecated==
* The term [[sequence point]], which is being replaced by specifying that either one operation is sequenced before another, or that two operations are unsequenced.<ref>{{cite web|url=http://blogs.msdn.com/b/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx|title=Update on the C++-0x Language Standard|last=Caves|first=Jonathan|date=4 June 2007|accessdate=25 May 2010}}</ref>
* <code>[[export (C++)|export]]</code><ref name="sutter0310">{{cite web|url=http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/|title=Trip Report: March 2010 ISO C++ Standards Meeting|last=Sutter|first=Herb|authorlink=Herb Sutter|date=3 March 2010|accessdate=24 March 2010}}</ref>: Its current use is ''removed'', but the keyword itself is still reserved, for potential future use.
* dynamic [[exception specification]]s<ref name="sutter0310"/> are deprecated. Compile time specification of non-exception throwing functions is available with the <code>noexcept</code> keyword (useful for optimization)
* <code>[[auto ptr|std::auto_ptr]]</code> is deprecated. Superseded by <code>std::unique_ptr</code>
* Function object base classes (<code>std::unary_function</code>, <code>std::binary_function</code>), adapters to pointers to functions and adapters to pointers to members, binder classes; these are all deprecated.

==See also==

*[[C++ Technical Report 1]]
*[[C99]]
*[[C11_(C_standard_revision)|C11]]

==References==

{{reflist}}

== External links ==
* [http://www.open-std.org/jtc1/sc22/wg21/ The C++ Standards Committee]
* [http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=216 C++0X: The New Face of Standard C++]
* [http://herbsutter.wordpress.com/ Herb Sutter's blog coverage of C++11]
* [http://www.justsoftwaresolutions.co.uk/cplusplus/ Anthony Williams' blog coverage of C++11]
* [http://www.csclub.uwaterloo.ca/media/C++0x%20-%20An%20Overview.html A talk on C++0x given by Bjarne Stroustrup at the University of Waterloo]
* [http://www.devx.com/SpecialReports/Article/38813/0/page/1 The State of the Language: An Interview with Bjarne Stroustrup (15 August 2008)]
* [http://wiki.apache.org/stdcxx/C++0xCompilerSupport Wiki page to help keep track of C++ 0x core language features and their availability in compilers]
* [http://en.cppreference.com Online C++11 standard library reference]

{{CProLang}}

[[Category:C++]]
[[Category:Computer standards]]
[[Category:Articles with example C++ code]]

[[es:C++11]]
[[fr:C++11]]
[[ko:C++11]]
[[it:C++11]]
[[ja:C++11]]
[[pl:C++11]]
[[pt:C++11]]
[[ru:C++11]]
[[sr:Нацрт C++0x од марта 2010.]]
[[fi:C++11]]
[[sv:C++#Historia]]
[[th:ภาษาซีพลัสพลัสโอเอกซ์]]
[[uk:C++11]]
[[vi:C++11]]
[[zh:C++11]]