C++11
ユーザー定義リテラルは全て接尾辞である。接頭辞リテラルを定義することはできない。
raw形式のリテラルを処理するユーザー定義リテラルは、以下のように定義できる:
1つ目の文で、接尾辞「_Suffix」を定義している。ユーザーが定義する接尾辞はアンダースコアで始める(アンダースコアで始まらないものは将来の標準のために予約されている)。
2つ目の文では、ユーザー定義リテラル関数によって定義されたコードを実行している。この関数には、Cスタイルの文字列としてヌル終端された"1234"が渡される。
rawリテラルを処理するもう1つの方法は、可変長引数テンプレートを使うことである:
これにより、operator""_Suffix<'1', '2', '3', '4'>としてリテラル処理関数が実体化される。この形式では、文字列のヌル終端文字は無い。これを行う主目的は、C++11のconstexprを使い、OutputTypeをconstexprで構築可能かつコピー可能とし、リテラル処理関数をconstexpr関数とすることで、コンパイラにリテラルの変換を完全にコンパイル時に行わせることである。
cookedリテラルの場合は、cookedリテラルの型が使われ、代替となるテンプレート形式は無い:
文字列リテラルの場合、以下のものが使用でき、前述の新たな文字列接頭辞と組み合わせられる:
文字リテラルも同様に定義できる。
スレッドクラスにより、関数オブジェクトを元に新たなスレッドの起動が可能になる。各時点において、あるスレッドが実行中のスレッドへのjoin(スレッドの終了を待つこと)も可能である。(可能であれば)ネイティブスレッドオブジェクトにアクセスし、プラットフォーム固有の操作を行うことも可能となるだろう。
スレッド間の同期のためにミューテックスや条件変数がライブラリに追加され、RAII方式のロックやロックアルゴリズムの使用も容易になる。
低レベル処理の高効率性のためには、スレッド間通信をミューテックスのオーバーヘッドなしで行う機能も必要となる。これは、適切なメモリバリアと不可分操作を用いることで達成できる。不可分操作ライブラリにより、各操作を行うのに必要な最小限の同期だけを指定できる。
スレッドプールのような高レベルスレッディング用のライブラリも作業中であるが、C++11標準にすべて搭載されてはいない。C++11では主に基礎となるライブラリが定義され、将来のTechnical Reportに含まれることが望まれる。
C++標準には、表明を確認する2つの方法として、assertマクロと#errorプリプロセッサディレクティブがある。しかし、このどちらもテンプレート使用時には不適切である。assertマクロでの確認は実行時であり、#errorプリプロセッサディレクティブでの確認はプリプロセス時である。どちらもテンプレート実体化時の確認には使えないため、テンプレート引数に依存する特性の検証には適していない。
そこで、コンパイル時点での表明確認の新たな手法として新たなキーワードであるstatic_assertが導入される。宣言は以下のような形になるであろう:
以下に、static_assertの使用法の例を挙げる:
constant-expressionがfalseとなる場合、コンパイラはエラーメッセージを生成する。1つ目の例は#errorプリプロセッサディレクティブの代替の例である。2つ目の例の方は、Checkクラステンプレートの各実体化において表明の確認をしている。
静的な表明はテンプレート以外での使用も有益である。例えば、charのビット数 (CHAR_BIT) が8ビット(オクテット)であることや、long longがintより大きいサイズであることに依存するアルゴリズムの実装のように、標準では保証されていない箇所の確認などの用途がある(このような仮定はほとんどのシステム、コンパイラで正しいだろうが、全ての環境で正しいとは言えない)。
C++11では言語に多数の新機能が提供され、既存の標準ライブラリもその恩恵を受けられる。例えば、大半の標準ライブラリのコンテナは右辺値参照に基づいたムーブコンストラクタを利用して、重いコンテナを高速に移動したり、新たなメモリ位置に中身を移動できる。標準ライブラリは必要に応じてC++11の新機能を使って改良される。それには下記のようなものが含まれるが、必ずしもこれだけに限定されるわけではない。
右辺値参照とそれに付随するムーブのサポート
UTF-16とUTF-32の文字型のサポート
可変個引数テンプレート (完全な転送を可能にするための右辺値参照と共に)
コンパイル時の定数式
decltype
明示的な変換関数
関数へのdefault/delete指定
加えて、C++が標準化されてから長い時間が経過し、標準ライブラリを使った大量のコードが書かれてきた。その結果、改良を施すことができる標準ライブラリの部分が明らかになった。その場所の多くは標準ライブラリのアロケータである。C++11には現在のアロケータのモデルを補うためにスコープに基づく新しいモデルが含まれる。
参照ラッパはテンプレートクラスstd::reference_wrapperのインスタンスとして得られる。参照ラッパは、C++言語の通常のリファレンス ('&') にも似ている。オブジェクトから参照ラッパを得るには、テンプレート関数std::refを使う(constな参照の場合はstd::crefが使用される)。
参照ラッパはテンプレート関数と使用する場合に有用であり、特に引数としてコピーではなく参照を取る必要がある場合に便利である:
この新ユーティリティは現在の<utility>に追加される。C++言語の拡張は必要としない。
なお、上記の高階関数テンプレートは、のちにC++17にて可変長引数テンプレートstd::invokeとして標準化されている。
それでも、32ビットシステムや、64ビット版Microsoft Windowsに代表されるLLP64モデル(long intが32ビットである)環境では、64ビット整数としてlong long intを使うのが根強い。
C++委員会は、C委員会(お互いに連絡を取っており、グループに大きな重なりがあるが、C++委員会とは独立である)の決定と合わない新たな組み込み型の標準化を避けてきた。しかし今や、long long int(略してlong long)は事実上の標準であり、さらにはC99で本当の標準化もされているので、この難局も解消されるだろう。C++委員会はlong long intおよびunsigned long long intを組み込み型として認可した。
将来的に、十分な要求があったり、128ビットのレジスタを持つようなプロセッサが現れたりすれば、long long intは128ビット型として使われるようになる可能性もある。