stanford-oval/wikipedia huggingface dataset:
C++11
コア言語機能の改良 > 可変長引数テンプレート

C++03のテンプレート（クラステンプレート・関数テンプレート）は、あらかじめ決められた個数の引数しか取れない。C++11では、テンプレート定義の際にあらゆる型の引数を任意個数取れる可変長引数テンプレート (variadic template) をサポートする:
template<typename... Types> class tuple;
このtupleクラステンプレートは、テンプレート引数としていくらでも型名を取れる:
tuple<std::vector<int>, std::map<std::string, std::vector<int>>> someTuple; // tuple インスタンス。
tuple<> emptyTuple; // 引数の数が0の場合。
上記のクラステンプレートはstd::tupleとして標準化されている。
可変長テンプレート引数の個数に0を認めない場合は、以下のように定義すればよい:
template<typename First, typename... Rest>
class tuple;
可変長テンプレート引数を取る関数も定義でき、Cの可変長引数機構に似ているが、型安全な仕組みがもたらされる。
template<typename... Params>
void printf(const std::string& strFormat, Params... parameters);
テンプレート定義時にはParamsの左側に...演算子を配置するが、関数シグネチャ中ではParamsの右側に使うことを注意する必要がある。テンプレート引数仕様のように、...演算子を型名の左側におく場合、これは"pack"演算子となる。この演算子は、型が0個以上となり得ることを示す。...演算子が型名の右側にある場合は、"unpack"演算子であり、pack演算子でまとめられた型のそれぞれに対して、複製の処理が行われるようになる。上の例では、printf関数の引数にはParamsにそれぞれの型がまとめられて渡される。
可変長テンプレート引数自体は関数・クラスの実装に使えるものではないため、可変長引数テンプレートの使用は再帰的に行われる。例えば、典型的な例として、C++11におけるprintfの代替の定義例を以下に挙げてみよう:
void printf(const char *s)
{
  while (*s) {
    if (*s == '%' && *(++s) != '%')
      throw std::runtime_error("invalid format string: missing arguments");
    std::cout << *s++;
  }
}

template<typename T, typename... Args>
void printf(const char *s, T value, Args... args)
{
  while (*s) {
    if (*s == '%' && *(++s) != '%') {
      std::cout << value;
      printf(*s ? ++s : s, args...); // さらなる引数を見つけるため、*s == '\0' でも呼び出す
      return;
    }
    std::cout << *s++;
  }
  throw std::runtime_error("extra arguments provided to printf");
}
これは再帰呼び出しを使っている。可変長テンプレート引数バージョンのprintfは自身を再帰的に呼び出し、argsが空の場合はシンプルな方のprintfが呼ばれることになる。
可変長テンプレート引数に順次アクセスする簡単な方法は無い。しかし、unpack演算子を用いることで、どこでも仮想的にテンプレート引数を解体できる。
例えば、クラスを以下のように使用できる:
template <typename... BaseClasses>
class ClassName : public BaseClasses... {
public:
   ClassName (BaseClasses&&... baseClasses) : BaseClasses(static_cast<BaseClasses&&>(baseClasses))... {}
}
unpack演算子により、ClassNameの各基底クラス型が複製され、このクラスは渡された各型の導出クラスとなる。また、ClassNameの基底型を初期化できるように、コンストラクタは各基底クラスへの参照を取る。
関数テンプレートでは、取った可変長引数を先へと転送できる。右辺値参照と組み合わせることで、完璧な転送が行える。
template<typename TypeToConstruct>
struct SharedPtrAllocator {
  template<typename ...Args> tr1::shared_ptr<TypeToConstruct> ConstructWithSharedPtr(Args&&... params)
  {
    return tr1::shared_ptr<TypeToConstruct>(new TypeToConstruct(static_cast<Args&&>(params)...));
  }
}
この特殊なファクトリ関数は、メモリリークに対する安全性のため、割り当てられたメモリをtr1::shared_ptrに自動的に包むものである。上記のように、引数リストを解体してTypeToConstructのコンストラクタへと渡している。static_cast<Args&&>(params)構文で、const性などを保ちつつ、引数の適切な型をコンストラクタへと転送できる。unpack演算子により、それぞれのパラメータに上記の伝播文法を適用できる。
また、テンプレートパラメータの数を以下のように決定できる:
template<typename ...Args> struct SomeStruct {
  static const int size = sizeof...(Args);
}
SomeStruct<Type1, Type2>::sizeは2となり、SomeStruct<>::sizeは0となるであろう。
コア言語機能の改良 > 新たな文字列リテラル

C++03には2種類の文字列リテラルがある。1つ目は、ヌル終端されたconst char型配列を生成する、ダブルクォーテーションで囲まれた形式のものである。2つ目は、ヌル終端されたconst wchar_t型配列（ワイド文字列）を生成する、Lプレフィックスを付けたダブルクォーテーションで囲まれた形式のものである。しかし、どちらもUnicodeで符号化された文字列リテラルを標準サポートするものではない。
C++コンパイラでのUnicodeサポートを強化するため、char型の定義が修正され、少なくとも8ビット符号単位のUTF-8符号化形式を格納できて、コンパイラの基本実行文字セットのあらゆる文字を格納するのに十分な大きさを持つ、とされた。以前は後者だけを満たしていれば良いとされていた。
C++11では、UTF-8, UTF-16, UTF-32の3つのUnicode符号化形式がサポートされる。先ほど述べたcharの定義の変更に加え、C++11には2つの新たな文字型、char16_tとchar32_tが加わる。それぞれ、UTF-16、UTF-32の符号単位を格納するよう設計されている。
以下に、それぞれの符号化形式で文字列リテラルを作る方法を示す:
u8"I'm a UTF-8 string.";
u"This is a UTF-16 string.";
U"This is a UTF-32 string.";
1つ目の文字列の型は、普通のconst char *である。2つ目は、const char16_t*であり、3つ目はconst char32_t*となる。
Unicode文字列リテラルを作るときには、Unicodeの符号位置を直接に文字列に埋め込めると便利である。C++11では、以下のような構文が使えるようになる:
u8"This is a Unicode Character: \u2018.";
u"This is a bigger Unicode Character: \u2018.";
U"This is a Unicode Character: \u2018.";
'\u'の後の数字は16進数であり、接頭辞'0x'をつける必要は無い。'\u'は16ビットのUnicode符号位置を示すものであり、32ビットのUnicode符号位置を示す場合は'\U'と16進数を用いる。正当なUnicode符号位置のみが入力できる。例えば、UTF-16のサロゲートペア（代用対）のために予約された、0xD800–0xDFFFの範囲の代用符号位置は使用できない。
XMLファイルのリテラルを用いる場合や、正規表現のパターン文字列あるいはスクリプト言語のリテラルを用いる場合など、手動でエスケープしなくてよい文字列も有用である。C++11では、raw文字列リテラルが導入される:
R"(The String Data \ Stuff " )";
R"delimiter(The String Data \ Stuff " )delimiter";
1つ目の場合、()括弧記号で挟まれた箇所全てが文字列となる。"や\の文字はエスケープする必要は無い。2つ目の場合、"delimiter(から)delimiter"までが文字列となる。delimiterという文字列は、実際には任意の文字列でよい。これにより、文字)をraw文字列リテラルで使用できるようになる。
raw文字列リテラルは、ワイドリテラルや各種Unicodeリテラルと組み合わせて利用できる。
コア言語機能の改良 > ユーザー定義リテラル

他の多くの言語と同様、C++03にも数種のリテラル値がある。例えば、"12.5"はコンパイラがdouble型の浮動小数点値へと変換するリテラル値である。しかし、リテラル値にはいくつもの修飾子がある。"12.5f"というリテラルは、浮動小数点値ではあるがfloat型の値を生成するように伝える。このような修飾子はC++仕様として規定されており、C++のコード中では新たな修飾子を生成することは不可能であった。
C++11では、ユーザーが新たな種類のリテラル修飾子を定義できるようにし、リテラル修飾子の文字列を基にオブジェクトを生成できるようになる。
リテラルの変換過程が再定義され、二つの段階、rawとcookedへと分けられた。rawリテラルは特定の型の文字の並びであり、cookedリテラルは単一の型である。例えば、C++リテラルの1234は、rawリテラルとしては'1', '2', '3', '4'という文字の並びであり、cookedリテラルとしては整数値1234である。0xAは、rawリテラルとしては'0', 'x', 'A'であり、cookedリテラルとしては整数値10である。
常にcooked形式として処理される文字列リテラルを除き、リテラルはraw形式にもcooked形式にも拡張される。文字列リテラルが例外なのは、文字列には、文字列の型と特別な意味の指定を行う接頭辞があるからである。
ユーザー定義リテラルは全て接尾辞である。接頭辞リテラルを定義することはできない。
raw形式のリテラルを処理するユーザー定義リテラルは、以下のように定義できる:
OutputType operator""_Suffix(const char *literal_string);

OutputType someVariable = 1234_Suffix; // operator""_Suffix("1234") と等価
1つ目の文で、接尾辞「_Suffix」を定義している。ユーザーが定義する接尾辞はアンダースコアで始める（アンダースコアで始まらないものは将来の標準のために予約されている）。
2つ目の文では、ユーザー定義リテラル関数によって定義されたコードを実行している。この関数には、Cスタイルの文字列としてヌル終端された"1234"が渡される。
rawリテラルを処理するもう1つの方法は、可変長引数テンプレートを使うことである:
template<char...> OutputType operator""_Suffix();

OutputType someVariable = 1234_Suffix;
これにより、operator""_Suffix<'1', '2', '3', '4'>としてリテラル処理関数が実体化される。この形式では、文字列のヌル終端文字は無い。これを行う主目的は、C++11のconstexprを使い、OutputTypeをconstexprで構築可能かつコピー可能とし、リテラル処理関数をconstexpr関数とすることで、コンパイラにリテラルの変換を完全にコンパイル時に行わせることである。
cookedリテラルの場合は、cookedリテラルの型が使われ、代替となるテンプレート形式は無い:
OutputType operator""_Suffix(int the_value);

OutputType someVariable = 1234_Suffix;
文字列リテラルの場合、以下のものが使用でき、前述の新たな文字列接頭辞と組み合わせられる:
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 someVariable = "1234"_Suffix;      //const char * バージョンを呼び出す
OutputType someVariable = u8"1234"_Suffix;    //const char * バージョンを呼び出す
OutputType someVariable = L"1234"_Suffix;     //const wchar_t * バージョンを呼び出す
OutputType someVariable = u"1234"_Suffix;     //const char16_t * バージョンを呼び出す
OutputType someVariable = U"1234"_Suffix;     //const char32_t * バージョンを呼び出す
文字リテラルも同様に定義できる。
コア言語機能の改良 > マルチタスク用のメモリモデル

C++標準化委員会はマルチスレッドの標準的サポートの導入を計画している。
これには2つの側面がある。つまり、複数スレッドが1つのプログラム中で共存できるメモリモデルを定義することと、スレッド間相互作用のサポートを定義することである。2つ目に関してはライブラリによって提供される。#スレッディングを参照のこと。
複数のスレッドが同じメモリ位置にアクセスする可能性がある環境下でのプログラム記述には、メモリモデルが必要となる。つまり、ルールを遵守するプログラムは正しく実行されるであろうと思われるが、ルールに従わないプログラムはコンパイラの最適化に依存する未定義の振る舞いや、memory coherenceの問題を抱えることになる。
コア言語機能の改良 > スレッドローカル記憶域

マルチスレッド環境においては、各スレッドごとに独立した変数（スレッドローカルストレージ、TLS）が必要となることがある。C++03では、関数内のローカル変数（自動変数）はこのような変数に該当するが、グローバル変数、また静的変数としては標準化されていない。各種コンパイラはそれぞれ独自拡張を用意してTLSに対応していた。
C++11では、新たなスレッドローカル記憶クラスが、（既存のstatic、動的、autoに加えて）新たに追加された。スレッドローカル記憶域は、記憶クラス指定子 thread_localによって指定する。
スレッドローカル記憶クラスは、static記憶クラスを持ち得るあらゆるオブジェクト（プログラムの実行期間全体にわたって存在しているようなもの）にも付けられるだろう。つまり、スレッドローカルなオブジェクトは、static記憶クラスの変数と同様のやり方で、コンストラクタで初期化されデストラクタで破壊されるということである。
コア言語機能の改良 > コンパイラが生成する関数へのdefault/delete指定

C++03では、オブジェクトにコンストラクタ、コピーコンストラクタ、代入演算子 (operator=)、そしてデストラクタが与えられていない場合、コンパイラが自動的にそれらを提供する。ユーザーは自身のバージョンを定義することで、デフォルトの動作を上書きできる。また、C++は全てのクラスに適用されるグローバルな演算子（operator=やoperator new）も提供しており、その動作もユーザーが上書きできる。
しかし、デフォルトで作られる関数の生成を制御する方法が非常に少ないという問題がある。例えば、クラスを実質的にコピー不能にするには、コピーコンストラクタと代入演算子をprivateとして宣言し、定義しないことによって実現できる。これらの関数を使用しようとすると、コンパイラやリンカがエラーを報告するようになるというわけである。しかし、これは理想的な解法とはいえないであろう。
さらに言えば、例えばデフォルトコンストラクタなど、コンパイラに対して明示的に生成するよう伝えておくことも有用である。オブジェクトに「どんなものであれ一つでも」コンストラクタが定義されているのであれば、コンパイラはデフォルトコンストラクタを生成しない。また、特別なコンストラクタとコンパイラが生成するデフォルトとを両方持っておくことも有用な場面がある。
C++11では、これらコンパイラが生成する関数の使用・不使用を明示できるようになる。例えば、以下のクラスはデフォルトコンストラクタの使用を明示している:
struct SomeType {
  SomeType() = default; // デフォルトコンストラクタが明示される
  SomeType(OtherType value);
};
また逆に、明示的に無効にすることも可能である。以下の例はコピー不能な型の例である:
struct NonCopyable {
  NonCopyable& operator=(const NonCopyable&) = delete;
  NonCopyable(const NonCopyable&) = delete;
  NonCopyable() = default;
};
new演算子で割り当てられないようにすることもできる:
struct NonNewable {
  void *operator new(std::size_t) = delete;
};
このオブジェクトは、スタック上か、他の型のメンバとしてしか割り付けられない。移植性の無いトリックを使いでもしない限り、直接ヒープには割り当てられないのである（ユーザー割り当てのメモリ上にコンストラクタを呼ぶ方法は配置newしかなく、その使用は上記のように禁じられているので、オブジェクトは適切に構築できない）。
= deleteという指定は、どんな関数の呼び出しも禁止できる。これは、メンバ関数を特定の型で呼び出すのを禁止するのに使える。例えば:
struct NoDouble {
  void f(int i);
  void f(double) = delete;
};
doubleでf()を呼ぼうとすると、暗黙のintへの変換を行うのではなく、コンパイラによってエラーになる。以下のようにすることで、int型以外の型では呼べないようにする総称化ができる:
struct NoDouble {
  void f(int i);
  template<class T> void f(T) = delete;
};
コア言語機能の改良 > Cとの互換性向上 > long long int型

32ビットおよび64ビット両方のシステムにおいて、サイズが最低でも64ビットあるような整数型が利用できると便利である。C99標準では既にlong long intおよびunsigned long long intとして標準Cに導入されている。また、C++用コンパイラのほとんどで以前から長期的にサポートされている拡張でもある（実際、コンパイラによってはC99で導入される前からサポートしているものもある）。C++11でも同様に、この型が標準C++に導入される。
これは、一部の64ビットシステム上ではあまり有用ではない。例えばLP64モデル上でのデータサイズは以下のようになり、64ビット整数はlong intによって実現できる。
16ビット: short int
32ビット: int
64ビット: long int
それでも、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ビット型として使われるようになる可能性もある。
コア言語機能の改良 > 静的な表明

C++標準には、表明を確認する2つの方法として、assertマクロと#errorプリプロセッサディレクティブがある。しかし、このどちらもテンプレート使用時には不適切である。assertマクロでの確認は実行時であり、#errorプリプロセッサディレクティブでの確認はプリプロセス時である。どちらもテンプレート実体化時の確認には使えないため、テンプレート引数に依存する特性の検証には適していない。
そこで、コンパイル時点での表明確認の新たな手法として新たなキーワードであるstatic_assertが導入される。宣言は以下のような形になるであろう:
static_assert( ''constant-expression'', ''error-message'' );
以下に、static_assertの使用法の例を挙げる:
static_assert(3.14 < GREEKPI && GREEKPI < 3.15, " GREEKPI is inaccurate!");

template<typename T>
struct Check {
  static_assert(sizeof(int) <= sizeof(T), "T is not big enough!");
};
constant-expressionがfalseとなる場合、コンパイラはエラーメッセージを生成する。1つ目の例は#errorプリプロセッサディレクティブの代替の例である。2つ目の例の方は、Checkクラステンプレートの各実体化において表明の確認をしている。
静的な表明はテンプレート以外での使用も有益である。例えば、charのビット数 (CHAR_BIT) が8ビット（オクテット）であることや、long longがintより大きいサイズであることに依存するアルゴリズムの実装のように、標準では保証されていない箇所の確認などの用途がある（このような仮定はほとんどのシステム、コンパイラで正しいだろうが、全ての環境で正しいとは言えない）。
コア言語機能の改良 > インスタンス化されていないクラスメンバへのsizeof

C++03では、sizeof演算子は型とオブジェクトに対してしか適用できない。そのため、以下のようには使用できない:
struct SomeType { OtherType member; };

size_t memberSize = sizeof(SomeType::member); // C++03では動かない。
この例では、OtherTypeのサイズを取得したい場面であるが、C++03ではこれは不正となりコンパイルエラーとなる。C++11では認められる。
ちなみに、C++03で同様のことをしたい場合、以下のようにすればよい:
struct SomeType { OtherType member; };

size_t memberSize = sizeof(static_cast<SomeType*>(0)->member);
C++標準ライブラリの拡張

大量の新機能が、C++11標準ライブラリに追加される。新しいライブラリの多くは現行の標準規格で実装できるが、C++11のコア言語の新機能に（程度の差はあれど）依存しているものもある。
導入されるライブラリの大部分は、C++ Standards Committee's Library Technical Report（TR1と呼ばれる）の文書で定義されている。TR1の最終稿は、2005年に出されている。なお、TR1の多くはBoost C++ライブラリが基になっている。
TR1ライブラリの実装は既に数種類が利用可能であり、std::tr1名前空間を用いて呼び出せる。C++11ではstd名前空間に移動される。
委員会は、2つ目のTechnical Report (C++ Technical Report 2) をC++11の標準化後に予定している。C++11に間に合わないライブラリ提案は、TR2や、さらに先のTechnical Reportに置かれることになる。
以下の提案は、C++11に搭載されることが予定されているものである。
C++標準ライブラリの拡張 > 標準ライブラリの改良

C++11では言語に多数の新機能が提供され、既存の標準ライブラリもその恩恵を受けられる。例えば、大半の標準ライブラリのコンテナは右辺値参照に基づいたムーブコンストラクタを利用して、重いコンテナを高速に移動したり、新たなメモリ位置に中身を移動できる。標準ライブラリは必要に応じてC++11の新機能を使って改良される。それには下記のようなものが含まれるが、必ずしもこれだけに限定されるわけではない。
右辺値参照とそれに付随するムーブのサポート
UTF-16とUTF-32の文字型のサポート
可変個引数テンプレート (完全な転送を可能にするための右辺値参照と共に)
コンパイル時の定数式
decltype
明示的な変換関数
関数へのdefault/delete指定
加えて、C++が標準化されてから長い時間が経過し、標準ライブラリを使った大量のコードが書かれてきた。その結果、改良を施すことができる標準ライブラリの部分が明らかになった。その場所の多くは標準ライブラリのアロケータである。C++11には現在のアロケータのモデルを補うためにスコープに基づく新しいモデルが含まれる。
C++標準ライブラリの拡張 > スレッディング

スレッドクラスにより、関数オブジェクトを元に新たなスレッドの起動が可能になる。各時点において、あるスレッドが実行中のスレッドへのjoin（スレッドの終了を待つこと）も可能である。（可能であれば）ネイティブスレッドオブジェクトにアクセスし、プラットフォーム固有の操作を行うことも可能となるだろう。
スレッド間の同期のためにミューテックスや条件変数がライブラリに追加され、RAII方式のロックやロックアルゴリズムの使用も容易になる。
低レベル処理の高効率性のためには、スレッド間通信をミューテックスのオーバーヘッドなしで行う機能も必要となる。これは、適切なメモリバリアと不可分操作を用いることで達成できる。不可分操作ライブラリにより、各操作を行うのに必要な最小限の同期だけを指定できる。
スレッドプールのような高レベルスレッディング用のライブラリも作業中であるが、C++11標準にすべて搭載されてはいない。C++11では主に基礎となるライブラリが定義され、将来のTechnical Reportに含まれることが望まれる。
C++標準ライブラリの拡張 > タプル型

タプルとは、決められた次元数の、異なる種類の型のオブジェクトから構成されたコレクションである。ペア (std::pair) を拡張して、任意の数のオブジェクトを格納できるようにしたものと考えても良い。あらゆる型のオブジェクトが、タプルの要素になりうる。
この新ユーティリティは、新ヘッダとC++言語拡張を通して実装される。つまり:
可変長引数テンプレート
参照への参照
関数テンプレートのデフォルト引数（C++03ではクラステンプレートにしかデフォルト引数を定義できない）
以下が、<tuple>ヘッダで定義されているタプルである:
template <class... Types> class tuple;
タプル型の定義例と使用例を挙げる:
using test_tuple_t = std::tuple<int, double, long&, const char *>;
long lengthy = 12;
test_tuple_t proof(18, 6.5, lengthy, "Ciao!");
lengthy = std::get<0>(proof); // lengthy に値 18 が代入される。
std::get<3>(proof) = "Beautiful!"; // タプルの第4要素を変更。
タプルproofを内容の定義なしに生成することも可能であるが、タプル要素の型がデフォルトコンストラクタを持つ場合に限られる。さらに、タプルを別のタプルに代入することも可能である。ただし、代入可能なのは、タプルの型が同じで各要素の型がコピーコンストラクタを持つ場合、もしくは右辺側のタプルの各型が左辺側のタプルのそれぞれの型と変換可能な場合、左辺側のタプルの各要素型が適切なコンストラクタを持つ場合である。
std::tuple<int, double, std::string> t1;
std::tuple<char, short, const char *> t2('X', 2, "Hola!");
t1 = t2; // OK。
// 最初の2つの要素は変換可能で、
// 3つ目の型 std::string は const char * から構築できる。
比較演算子も使用可能であり（タプルの要素数が同じ場合）、タプルの特性を確認する2つの式が使用可能である（コンパイル時のみ）。
std::tuple_size<T>::value: タプルTの要素数を返す。
std::tuple_element<I, T>::type: タプルTのI番目のオブジェクトの型を返す。
C++標準ライブラリの拡張 > ハッシュテーブル

C++標準ライブラリへのハッシュテーブル（順序付けの無い連想コンテナ）の導入要求は、最も繰り返されてきた要求の1つである。これは、時間的な制約のみのために、現在の標準（1995年、1998年）に導入されなかった。ハッシュテーブルは最悪の場合（大量の衝突が発生）の効率は平衡木に劣るが、現実のアプリケーションでは多くの場合効率的である。
衝突の管理は、チェイン法によってのみ行われる。これは、委員会には、多くの実装上の問題（特に要素の消去が認められるような場合）があるオープンアドレス法を標準化する機会がないからである。非標準のライブラリの持つ、独自のハッシュテーブル実装と名前が衝突しないように、"hash"の代わりに"unordered"を使用している。
ハッシュテーブルには4種類あり、同じキーを持つ要素を認めるかどうかと、キーに値を関連付けるかどうかで区別される。
| ハッシュ表の型 | 値の関連付け | 重複するキー |
| --- | --- | --- |
unordered_set: 
| unordered_multiset |  | ○ |
| unordered_map | ○ |  |
unordered_multimap: ○
新クラスは、コンテナクラスの要件を全て満たし、要素へのアクセスに必要な全てのメソッドを備える:insert, erase, begin, end.
この新ユーティリティは、C++言語の拡張は必要ない。<functional>ヘッダへの小さな拡張と、<unordered_set>ヘッダ、<unordered_map>ヘッダの導入を行うのみである。他の標準クラスには変更の必要がなく、標準ライブラリの他の拡張にも依存しない。
C++標準ライブラリの拡張 > 正規表現

正規表現のために作られた、多くの非標準あるいは準標準のライブラリがある。このようなアルゴリズムを使うのは非常に一般的なので、オブジェクト指向言語の能力を用いて、標準ライブラリにもこの機能が導入される。<regex>で提供される正規表現はECMAScriptとの互換性がある。POSIXなどの正規表現もサポートする。ただし、Perlの正規表現はサポートされないため、Perl正規表現を使いたければBoost C++ライブラリのBoost.RegexかBoost.XPressiveを使うことになる。
新ライブラリでは、新ヘッダ<regex>が定義され、2つの新クラスが導入される:
正規表現を表すクラステンプレートbasic_regex
結果を表すクラステンプレートmatch_results
検索のためにregex_search関数が使われ、「検索と置換」とためにregex_replace関数が使われ、新たな文字列を返す。アルゴリズムregex_searchとregex_replaceは正規表現と文字列を取り、結果をmatch_resultsに収める。
以下にmatch_resultsの使用例を示す:
const char *reg_esp = "[ ,.\\t\\n;:]"; // 分割文字のリスト。

regex rgx(reg_esp); // regex型は「char型」を引数にした、basic_regexテンプレートのインスタンス。
cmatch match; // cmatch型は「const char *型」を引数にした、match_resultsテンプレートのインスタンス。
const char *target = "Polytechnic University of Turin ";
 
// reg_espの文字で分割された、targetの全単語を分別。
if (regex_search(target, match, rgx)) {
  // 単語が特定の文字で分割されていた場合は表示。
  for (int a = 0; a < match.size(); a++) {
    string str( match[a].first, match[a].second );
    cout << str << "\n";
  }
}
注意: C++の文字列リテラルではバックスラッシュはエスケープ文字として扱われるため、例ではバックスラッシュを二つ重ねている。C++11のraw文字列機能により、この問題は回避できる。
regexライブラリ自体は、既存のヘッダの変更や言語拡張を必要としない。
C++標準ライブラリの拡張 > 一般用途のスマートポインタ

動的メモリ確保は、プログラミング言語の歴史においても昔からの論点である。C/C++では動的に確保したメモリに対する明示的な解放が必要だが、Javaなどに代表される多くの現代的プログラミング言語は、ガベージコレクションによる自動メモリ管理の仕組みを備えている。
C++のポインタには、多くの興味深い性質がある:
コピーできる。
代入できる。
void *を総称的ポインタとして使える。
静的キャストで、基底クラスのポインタに変換できる。
動的キャストで、派生クラスのポインタに変換できる。
一方、C++のポインタには主に以下のような欠点や危険な性質がある:
動的に割り当てられたメモリを手動管理する責任がプログラマ側にある。
メモリ上の、不正なアドレスや未割り当てのアドレスが参照できる。
この問題を解消・軽減するためのイディオムとして、RAIIに基づいたスマートポインタがよく利用される。スマートポインタは、通常のポインタの利点を維持したまま、弱点を大幅に削ったものである。C++03までの標準C++ライブラリにもスマートポインタの一種としてstd::auto_ptrが存在したが、制約が多く、決して使いやすいとは言えなかった。C++11では、Boost C++ライブラリをベースとした、いくつかの新しいスマートポインタが標準化された。
クラステンプレートstd::shared_ptrは、同じオブジェクトに対する「同等の」参照をカウントする機能（参照カウント）を持ち、関連するスマートポインタ間でオブジェクトの所有権を共有する。さらに、標準コンテナの要素とすることも可能である。
同じオブジェクトを参照するポインタの数を得るには、shared_ptrのメンバ関数であるuse_countが使えるだろう。メンバ関数resetは、スマートポインタをリセットする。リセットされたポインタは「空」になり、use_countを呼び出すとゼロを返す。
以下に、shared_ptrの使用例を示す:
#include <iostream>
#include <memory>
int main() {
  std::shared_ptr<double> p_first(new double(-100));
  std::cout << "Ref count = " << p_first.use_count() << std::endl;
  std::cout << *p_first << std::endl;
  {
    std::shared_ptr<double> p_copy = p_first;
    std::cout << "Ref count = " << p_first.use_count() << std::endl;
    std::cout << "Ref count = " << p_copy.use_count() << std::endl;
    std::cout << *p_copy << std::endl;
    *p_copy = 21.2;
  } // 'p_copy'は破壊されるが、まだ参照が残っているので、割り当てられたdoubleは破壊されない。
  std::cout << "Ref count = " << p_first.use_count() << std::endl;
  std::cout << *p_first << std::endl;
  return 0; // 'p_first'が破壊され、参照がなくなり、同時に割り当てられたdoubleも破壊される。
}
これと関連し、弱い参照としてstd::weak_ptrテンプレートも導入される。これもスマートポインタ・参照と同様に振舞うが、shared_ptrとの違いは、参照先の値がポインタによって「所有」されず、弱参照ポインタが存在していても破壊され得る点である。これは、弱参照ポインタには参照先オブジェクトが破壊されてしまうことによる実行時エラーが発生しやすいことを意味している。しかしこれにより、オブジェクトの生存時間に影響しない形で参照を持つことが可能となり、循環参照を防止できる。
このユーティリティは<memory>ヘッダに変更を必要とするが、C++言語拡張は必要としない。
また、std::unique_ptrが前述のauto_ptrの代わりとして導入され、auto_ptrは非推奨とされる。unique_ptrはauto_ptrの全機能を提供するが、左辺値からの暗黙的な移動の際に起こる挙動が異なる。unique_ptrは、C++11のMove Semanticsを用いたコンテナになっている。
C++標準ライブラリの拡張 > 拡張可能な乱数の枠組み

コンピュータは決定的な振る舞いをするものであるが、疑似乱数による乱数列を生成することにより、（外見だけでも）非決定的な振る舞いが必要となるようなアプリケーションがある。
標準に用意されている方法は、rand関数のみである。しかし、十分な定義がされていないため、そのアルゴリズムは完全にライブラリ開発者に任せられている。新たな乱数生成ユーティリティは<random>ヘッダを通して定義される。他のヘッダやC++言語への修正は必要としない。
乱数生成器は、内部状態と、結果を計算し次の状態を生成するための関数をもつ。この2つの特性によって、乱数生成エンジンが定まる。他の特性として、生成結果や乱数の間隔や密度の分布も重要である。
C++標準ライブラリの拡張 > 拡張可能な乱数の枠組み > 擬似乱数エンジン

新ライブラリには、数種の擬似乱数生成エンジンが導入される。これらはテンプレートクラスであり、必要に応じて特殊化できる。擬似乱数エンジンの内部状態は種（一般には変数の集合）によって決定される。
| テンプレートクラス | int/float | 質 | 速度 | 内部状態の大きさ（※） |
| --- | --- | --- | --- | --- |
| linear_congruential | int | 低 | 中 | 1 |
| subtract_with_carry | 両方 | 中 | 遅い | 25 |
| mersenne_twister | int | 良 | 速い | 624 |
※使われる型の次元数・バイト数倍される。
エンジンの質はクラステンプレートdiscard_blockを用いて向上でき、クラステンプレートxor_combineと組み合わせることも可能である。利便性のため、<random>ヘッダには数種の標準エンジンが定義されている。例として、mersenne_twisterから実体化されるmt19937クラスを示す。
typedef mersenne_twister<''implementation-defined'', 32, 624, 397, 31, 0x9908b0df,
                         11, 7, 0x9d2c5680, 15, 0xefc60000, 18>
        mt19937 ;
C++標準ライブラリの拡張 > 拡張可能な乱数の枠組み > 非決定的乱数エンジン

random_deviceクラスを用いて、unsigned int型の非決定的乱数を生成できる。実装には、システムから独立した入力を持つデバイス（例えば、非同期的な外部カウンタや、特殊なトランスデューサーなど）の使用や、伝統的な「結果を調節する」擬似乱数エンジンの使用が必要である。libstdc++やlibc++では、/dev/urandomを読み出す実装となっている。
C++標準ライブラリの拡張 > 拡張可能な乱数の枠組み > 乱数分布

新ライブラリには、一様分布から確率論で定義された分布まで、多種類の分布が定義されている:
離散一様分布uniform_int
ベルヌーイ分布bernoulli_distribution
幾何分布geometric_distribution
ポアソン分布poisson_distribution
二項分布binomial_distribution
連続一様分布uniform_real
指数分布exponential_distribution
正規分布normal_distribution
ガンマ分布gamma_distribution
明らかであるが、標準の分布を実体化しても構わないし、ユーザ自身の互換性のある分布を用いても構わない。
以下は、新ライブラリを用いた簡単な例である:
uniform_int_distribution<int> distribution( 0, 99 );
mt19937 engine;
auto generator( bind( distribution, engine ) );
int random = generator();  // 0から99の値を代入
C++標準ライブラリの拡張 > 参照ラッパ

参照ラッパはテンプレートクラスstd::reference_wrapperのインスタンスとして得られる。参照ラッパは、C++言語の通常のリファレンス ('&') にも似ている。オブジェクトから参照ラッパを得るには、テンプレート関数std::refを使う（constな参照の場合はstd::crefが使用される）。
参照ラッパはテンプレート関数と使用する場合に有用であり、特に引数としてコピーではなく参照を取る必要がある場合に便利である:
#include <iostream>
#include <functional>

// 引数 r として int への参照を受け取り、それを増加させる関数。
void inc(int& r) {
  r++;
}

// 関数を呼び出す高階関数テンプレート。
template<class F, class P>
void invoke(F f, P t) { f(t); }

int main() {
  int i = 0;
  invoke(inc, i);
  // invoke<void(int& r), int> が実体化される。
  // よって i の値は変更されない。
  std::cout << i << std::endl; // 0 が出力される。

  invoke(inc, std::ref(i));
  // invoke<void(int& r), std::reference_wrapper<int>> が実体化される。
  // よって i の値が変更される。
  std::cout << i << std::endl; // 1 が出力される。

  return 0;
}
この新ユーティリティは現在の<utility>に追加される。C++言語の拡張は必要としない。
なお、上記の高階関数テンプレートは、のちにC++17にて可変長引数テンプレートstd::invokeとして標準化されている。
C++標準ライブラリの拡張 > 関数オブジェクトの多相的ラッパ

関数オブジェクトの多相的ラッパ（「多態的関数オブジェクトラッパ」とも呼ばれる）は、意味的にも構文的にも関数ポインタに似ている。しかし、引数がラッパの引数型と変換可能である関数を参照できる点など、束縛が緩和されている。
次の例で、特性を理解できるだろう:
#include <functional>

namespace {
  bool adjacent(long x, long y) {
    return (x + 1 == y) || (x - 1 == y);
  }
}

...

// クラステンプレート std::function を用いてラッパを生成する。
std::function<int (int, int)> funcA;

// 関数ポインタのように、std::function は NULL または nullptr との比較が可能。
std::cout << "Is function empty? " << std::boolalpha << (funcA == nullptr) << std::endl;

// std::function が何も参照していない場合、
// 関数呼び出し演算子を実行すると std::bad_function_call 例外がスローされる。
try {
  const int a = funcA(1, 2);
} catch (const std::exception& ex) {
  std::cout << "Exception reason = " << ex.what() << std::endl;
}

std::plus<int> add;
// std::plus は template<class T> T plus(T, T); として宣言されている。
// そのため、add の型は int add(int x, int y) となる。

funcA = add; // 引数型が一致しているため、代入可能。
std::cout << "Is function empty? " << std::boolalpha << (funcA == nullptr) << std::endl;
std::cout << "ResultA = " << funcA(1, 2) << std::endl;

std::function<bool (short, short)> funcB;
// std::function は explicit operator bool() をサポートする。
if (!funcB) { // 何も代入されていないので、常に成立。
  funcB = &adjacent; // 引数の型・戻り値の型が変換可能なので、代入できる。
  std::cout << "ResultB = " << funcB(0, -1) << std::endl;

  struct test {
    bool operator()(short x, short y) const {
      return (x * y) % 2 == 0;
    }
  } fobj;
  funcB = fobj;
  std::cout << "ResultB = " << funcB(3, 7) << std::endl;
}

funcA = funcB; // ラッパ同士の引数の型・戻り値の型がそれぞれ変換可能なので、正当。
クラステンプレートstd::functionは<functional>ヘッダで宣言される。C++言語への変更は必要としない。
C++標準ライブラリの拡張 > メタプログラミングのための型特性

メタプログラミングとは、他のプログラム（もしくは自分自身）を生成、修正するプログラムを生成することである。これらの動作は、コンパイル時、もしくは実行時に発生する。C++標準化委員会は、テンプレートを通したコンパイル時メタプログラミング（テンプレートメタプログラミング）を可能にするライブラリの導入を決定した。
以下は、現在の標準でのメタプログラミングの例である: 指数計算に、テンプレート実体化の再帰を用いている。
template<int B, int N>
struct Pow {
  // 再帰呼び出しと再結合
  static const int value = B * Pow<B, N - 1>::value;
};

template<int B>
struct Pow<B, 0> {  // 終了条件、''N == 0''
  static const int value = 1;
};
int quartic_of_three = Pow<3, 4>::value;
多くのアルゴリズムは、型の違うデータに適用可能である。C++のテンプレートはジェネリックプログラミングをサポートし、より小さく有用なコードを作れる。それでも、アルゴリズムは使用されている型の情報を必要とすることも多い。この種の情報は、型特性を使用してテンプレートクラスの実体化時に展開できる。
型特性は、オブジェクトの分類やクラス（または構造体）の性質を示すものである。新ヘッダの<type_traits>で宣言される。
次の例は、関数テンプレートelaborateの例である。この関数は、渡されたデータ型に基づき、二つのアルゴリズム (algorithm.do_it) から一方を実体化する:
// 一つ目の動作
template<bool B>
struct algorithm {
  template<class T1, class T2>
  int do_it(T1&, T2&) { /*...*/ }
};
// 二つ目の動作
template<>
struct algorithm<true> {
  template<class T1, class T2>
  int do_it()(T1 *, T2 *) { /*...*/ }
};
 
// elaborateの実体化の際に、自動的に正しい動作をする方が実体化される。
template<class T1, class T2>
int elaborate(T1 A, T2 B) {
  // T1が整数で、T2が浮動小数の時に二つ目の動作を行う。
  // 他の場合は一つ目の動作を行う。
  return algorithm<is_integral<T1>::value && is_floating_point<T2>::value>::do_it(A, B);
}
ヘッダ<type_transform>で定義された型特性を用いると、型変換の処理を生成することも出来る（static_castとconst_castはテンプレート中では不十分）。
この種のプログラミングで、美しく簡潔なコードを書ける。しかし、このテクニックの弱点はデバッグである。コンパイル時のデバッグは不適切であるし、プログラム実行時には非常に難しい。