C++11

2011 edition of the C++ programming language standard

C++11 is a version of the ISO/IEC 14882 standard for the C++ programming language. C++11 replaced the prior version of the C++ standard, called C++03, and was later replaced by C++14. The name follows the tradition of naming language versions by the publication year of the specification, though it was formerly named C++0x because it was expected to be published before 2010. Although one of the design goals was to prefer changes to the libraries over changes to the core language, C++11 does make several additions to the core language. Areas of the core language that were significantly improved include multithreading support, generic programming support, uniform initialization, and performance. Significant changes were also made to the C++ Standard Library, incorporating most of the C++ Technical Report 1 (TR1) libraries, except the library of mathematical special functions. C++11 was published as ISO/IEC 14882:2011 in September 2011 and is available for a fee. The working draft most similar to the published C++11 standard is N3337, dated 16 January 2012; it has only editorial corrections from the C++11 standard. C++11 is fully supported by Clang 3.3 and later. C++11 is fully supported by GCC 4.8.1 and later.

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

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

In C++03 (and before), temporaries (termed "rvalues", as they often lie on the right side of an assignment) were intended to never be modifiable — just as in C — and were considered to be indistinguishable from const T& types; nevertheless, in some cases, temporaries could have been modified, a behavior that was even considered to be a useful loophole. C++11 adds a new non const reference type called an rvalue reference, identified by T&&. This refers to temporaries that are permitted to be modified after they are initialized, for the purpose of allowing "move semantics". A chronic performance problem with C++03 is the costly and unneeded deep copies that can happen implicitly when objects are passed by value. To illustrate the issue, consider that an std::vector<T> is, internally, a wrapper around a C style array with a defined size. If an std::vector<T> temporary is created or returned from a function, it can be stored only by creating a new std::vector<T> and copying all the rvalue's data into it. Then the temporary and all its memory is destroyed. (For simplicity, this discussion neglects the return value optimization.) In C++11, a move constructor of std::vector<T> that takes an rvalue reference to an std::vector<T> can copy the pointer to the internal C style array out of the rvalue into the new std::vector<T>, then set the pointer inside the rvalue to null. Since the temporary will never again be used, no code will try to access the null pointer, and because the pointer is null, its memory is not deleted when it goes out of scope. Hence, the operation not only forgoes the expense of a deep copy, but is safe and invisible. Rvalue references can provide performance benefits to existing code without needing to make any changes outside the standard library. The type of the returned value of a function returning an std::vector<T> temporary does not need to be changed explicitly to std::vector<T> && to invoke the move constructor, as temporaries are considered rvalues automatically. (However, if std::vector<T> is a C++03 version without a move constructor, then the copy constructor will be invoked with an const std::vector<T>&, incurring a significant memory allocation.) For safety reasons, some restrictions are imposed. A named variable will never be considered to be an rvalue even if it is declared as such. To get an rvalue, the function template std::move should be used. Rvalue references can also be modified only under certain circumstances, being intended to be used primarily with move constructors. Due to the nature of the wording of rvalue references, and to some modification to the wording for lvalue references (regular references), rvalue references allow developers to provide perfect function forwarding. When combined with variadic templates, this ability allows for function templates that can perfectly forward arguments to another function that takes those particular arguments. This is most useful for forwarding constructor parameters, to create factory functions that will automatically call the correct constructor for those particular arguments. This is seen in the emplace back set of the C++ standard library methods.

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.

C++98 added the explicit keyword as a modifier on constructors to prevent single argument constructors from being used as implicit type conversion operators. However, this does nothing for actual conversion operators. For example, a smart pointer class may have an operator bool to allow it to act more like a primitive pointer: if it includes this conversion, it can be tested with if (smart ptr variable) (which would be true if the pointer was non null and false otherwise). However, this allows other, unintended conversions as well. Because C++ bool is defined as an arithmetic type, it can be implicitly converted to integral or even floating point types, which allows for mathematical operations that are not intended by the user. In C++11, the explicit keyword can now be applied to conversion operators. As with constructors, it prevents using those conversion functions in implicit conversions. However, language contexts that specifically need a boolean value (the conditions of if statements and loops, and operands to the logical operators) count as explicit conversions and can thus use a bool conversion operator. For example, this feature solves cleanly the safe bool issue.

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

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

C++11 standardizes support for multithreaded programming. There are two parts involved: a memory model which allows multiple threads to co exist in a program and library support for interaction between threads. (See this article's section on threading facilities.) The memory model defines when multiple threads may access the same memory location, and specifies when updates by one thread become visible to other threads.

In a multi threaded environment, it is common for every thread to have some unique variables. This already happens for the local variables of a function, but it does not happen for global and static variables. A new thread local storage duration (in addition to the existing static, dynamic and automatic) is indicated by the storage specifier thread local. Any object which could have static storage duration (i. e., lifetime spanning the entire execution of the program) may be given thread local duration instead. The intent is that like any other static duration variable, a thread local object can be initialized using a constructor and destroyed using a destructor.

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

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

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

While the C++03 language provides a memory model that supports threading, the primary support for actually using threading comes with the C++11 standard library. A thread class (std::thread) is provided, which takes a function object (and an optional series of arguments to pass to it) to run in the new thread. It is possible to cause a thread to halt until another executing thread completes, providing thread joining support via the std::thread::join member function. Access is provided, where feasible, to the underlying native thread object(s) for platform specific operations by the std::thread::native handle member function. For synchronization between threads, appropriate mutexes (std::mutex, std::recursive mutex, etc.) and condition variables (std::condition variable and std::condition variable any) are added to the library. These are accessible via Resource Acquisition Is Initialization (RAII) locks (std::lock guard and std::unique lock) and locking algorithms for easy use. For high performance, low level work, communicating between threads is sometimes needed without the overhead of mutexes. This is done using atomic operations on memory locations. These can optionally specify the minimum memory visibility constraints needed for an operation. Explicit memory barriers may also be used for this purpose. The C++11 thread library also includes futures and promises for passing asynchronous results between threads, and std::packaged task for wrapping up a function call that can generate such an asynchronous result. The futures proposal was criticized because it lacks a way to combine futures and check for the completion of one promise inside a set of promises. Further high level threading facilities such as thread pools have been remanded to a future C++ technical report. They are not part of C++11, but their eventual implementation is expected to be built entirely on top of the thread library features. The new std::async facility provides a convenient method of running tasks and tying them to a std::future. The user can choose whether the task is to be run asynchronously on a separate thread or synchronously on a thread that waits for the value. By default, the implementation can choose, which provides an easy way to take advantage of hardware concurrency without oversubscription, and provides some of the advantages of a thread pool for simple usages.

C++11 provides , and improvements to and from TR1. is deprecated.

The term sequence point was removed, being replaced by specifying that either one operation is sequenced before another, or that two operations are unsequenced. The former use of the keyword export was removed. The keyword itself remains, being reserved for potential future use. Dynamic exception specifications are deprecated. Compile time specification of non exception throwing functions is available with the noexcept keyword, which is useful for optimization. std::auto ptr is deprecated, having been superseded by std::unique ptr. Function object base classes (std::unary function, std::binary function), adapters to pointers to functions and adapters to pointers to members, and binder classes are all deprecated.