C++11は、プログラミング言語 C++ のISO標準 ISO/IEC 14882:2011 の略称である。規格の策定中は2009年中の標準化を目指していたため、C++0x という仮称で呼ばれていた。ISO/IEC 14882:2003 (C++03) に代わるものとして、2011年8月12日にISOによって承認された。後継のC++14が2014年8月18日に承認されている。コア言語への機能追加や標準C++ライブラリの拡張を施し、C++TR1ライブラリの大部分を（数学的特殊関数ライブラリを除いて）取り込んでいる。C++ への修正はコア言語と標準ライブラリの双方に及ぶ。委員会は、新規格の個別の要素の策定に際して次のような方針をとった。初心者はプログラマ人口の多くを占める。また、多くの初心者は自身が習得した一部の言語機能に拘泥しがちであり、知識を広げようとはしない。従って、初心者への配慮は重要であると考えられた。また、C++の言語仕様の大きさ（アプリケーションやプログラミング・スタイルの多様性も含む) を考えると、どれだけ長い経験を積んだプログラマも新しいプログラミングパラダイムの前では未経験者になり得ることから重要な配慮であると言える。C++ コア言語の特筆すべき改良点には、マルチスレッドのサポートや、ジェネリックプログラミングのサポート、一様な初期化構文やパフォーマンス向上等が挙げられる。このページでは、コア言語の機能拡張や変更点を、実行時パフォーマンス向上、ビルド時パフォーマンス向上、使いやすさの向上、全く新しい機能の4つに分けて説明する。機能によっては複数の項目に該当するが、最もよく当てはまる項目で述べることとする。以下の機能は、主に何らかのパフォーマンス向上を狙ったものである。スピードの向上とメモリ効率の改善の両方が含まれる。C++03以前は、一時変数 (代入演算子の右側に置かれることから、右辺値と呼ばれる) に変更を加えるのは意味がないものと考えられており、関数に参照として渡す場合にはcodice_1型としてしか渡すことができなかった。しかし、場合によっては変更できるほうが都合のよいこともあった。例えば所有権の移動（ムーブ）である。C++11 では、右辺値参照と呼ばれる新たな参照型 codice_2 が追加された。これにより、右辺値を変更可能なまま関数に渡すことができ、右辺値からのムーブを実現できる。例えば、codice_3 は内部的には C スタイル配列のサイズ付きのラッパである。従来は、codice_3 の一時変数が生成されたとき、新たな codice_3 を生成してそこに全ての右辺値データをコピーしないといけなかった。コピーの後、一時変数は破壊され、内容は削除される。右辺値参照があれば、codice_3 への右辺値参照を取る codice_3 の「ムーブコンストラクタ」を用いることで、単に右辺値から配列へのポインタを取り出してコピーし、空のオブジェクトを残す、ということが実現できる。この場合、配列のコピーは起こらず、空の一時変数を破壊してもメモリの破壊は起こらない。仮にcodice_3 にムーブコンストラクタがない場合、通常通りにコピーコンストラクタが codice_9 として呼ばれる。ムーブコンストラクタがある場合、ムーブコンストラクタが呼ばれ、メモリの割り当てが回避できる。標準ライブラリにムーブコンストラクタが記述されていれば、既存のコードは変更を加えることなく右辺値参照のメリットを享受することができる。codice_3の一時変数を返す関数は、明示的にcodice_11に変更する必要はない。なぜなら、一時変数は自動的に右辺値であるとみなされるからである。安全上の理由から、右辺値参照として宣言された名前つきの変数をそのまま右辺値として関数に渡すことはできない（そのような変数は左辺値となる）。codice_12 を明示的に呼び出すことで、この制限を回避できる。右辺値参照の文言の特性と左辺値参照 (通常の参照) の文言の若干の修正により、右辺値参照を使って完全な関数転送を開発者が提供できるようになる。可変長引数テンプレートと組み合わせ、関数テンプレートから、決まった型の引数を取る別の関数へと引数を転送できる。これは、コンストラクタ引数の転送に最も有用であり、引数に基づいて自動的に的確なコンストラクタを呼ぶようなファクトリ関数の生成に使用できる。C++ には既に定数式が存在している。定数式とは、codice_13 のように、常に同じ結果を返し副作用の無いものである。定数式はコンパイラの最適化の対象となり、多くの場合コンパイル時に演算が行われ、プログラム中にはその結果のみが格納される。また、C++ の仕様中でも、多くの箇所で定数式の使用が必要となる。配列の定義にも要素数として定数式が必要であるし、列挙子の値にも必要である。しかし、関数呼び出しやオブジェクトコンストラクタが出現すると、定数式ではなくなる。単純な例を挙げると:codice_14 が定数式でないため、これは C++ では不正となる。実際には codice_15 は実行時に一定値を返すが、コンパイラにそれを知らせる方法がないのである。理論上、関数はグローバル変数に影響を与える、実行時に結果が変わる他の関数を呼ぶ、などの理由がある。C++11 では、キーワード codice_16 が導入される。これにより、関数やオブジェクトコンストラクタがコンパイル時定数であることを保証できる。上の例は、以下のように書き直せる:これによりコンパイラは、codice_15 がコンパイル時定数であることを理解し、検証できる。codice_16 を関数に使用する場合、関数内でできることは非常に制限される。まず、関数は非 void 型の戻り値を持たねばならず、内容として "return "expr" の形を持たねばならない。そして、引数を置き換えた後、codice_19 は定数式でなくてはならない。ここでいう定数式では、codice_16 として定義された他の関数を呼ぶか、他の定数式データ変数を使うかしかできない。さらに、定数式内ではあらゆる形の再帰はできず、 codice_16 が付けられた関数は定義されるまで翻訳単位中で呼ぶことはできない。定数式の値として、変数を定義することも可能である:定数式データ変数は暗黙的に const である。定数式データ変数には、定数式の結果か定数式コンストラクタの結果のみを格納できる。ユーザー定義型から定数式データ値を作るには、コンストラクタを codice_16 として宣言すればよい。定数式関数と同様、定数式コンストラクタは翻訳単位中で使用する前に定義されていなくてはならない。そして、関数本体は空でなくてはならず、メンバを定数式で初期化しなくてはならない。また、このような型のデストラクタは自動生成のものであるべきである。constexpr として生成された型のコピーも、codice_16 として定義されるべきである。こうすることで、constexpr な関数から返された値もconstexprとなる。コピーコンストラクタや演算子オーバーロードといった、クラスの全てのメンバ関数も、定数式関数の定義と同様 codice_16 として宣言できる。これにより、コンパイラはクラスのコピーやその他の処理をコンパイル時に行える。定数式関数・コンストラクタは、非 constexpr パラメータで呼べる。constexpr な整数リテラルが非 constexpr 変数に代入できるように、constexpr 関数を非 constexpr パラメータで呼び出せるし、その結果を非 constexpr 変数に格納できるのである。constexpr キーワードは、式の全ての内容が constexpr である場合のコンパイル時定数性の可能性をコンパイラに伝えるだけのものである。C++03では、構造体が Plain Old Data (POD) 型として扱われるためにはいくつかのルールに従う必要がある。これを満たす型は C と互換性のあるオブジェクトレイアウトを生成する。しかし、C++03 におけるルールは必要以上に厳しく、より多くの型をPOD 型にしてもよいのではないかという指摘があった。C++11 では POD の定義に関して、いくつかのルールが緩和されている。クラス・構造体は、それが "trivial" であり、"standard-layout" であり、すべての非静的データメンバがPOD型であるとき、POD型とみなされる。trivial なクラス・構造体は、以下のように定義される。standard-layout なクラス・構造体は、以下のように定義される。C++03では、ある翻訳単位で完全に引数が特定されたテンプレートが見つかったとき、コンパイラは常にそのテンプレートを実体化しなければならない。このことはコンパイルの時間を劇的に増加させる。特に、同じパラメータを用いたテンプレートが複数の翻訳単位で実体化されるときは顕著である。そして、C++03 にはそのようなテンプレートの実体化を止めさせる手段もなかった。C++11 では、これに対して外部テンプレートが導入された（これは外部変数に対するアナロジーである）。C++03 には、特定の場所での実体化を強制的にコンパイラに命じる構文がある。C++11 では、以下のような構文が導入された。これにより、コンパイラはこの翻訳単位ではテンプレートの実体化をしないようになる。以下の機能は、主に言語を使いやすくするためのものである。例えば型安全性や、類似したコードの繰り返しを削減すること、間違ったコードが書かれにくくすることなどが含まれる。C++03では、初期化リストの考え方を C から引き継いでいる。つまり、構造体のメンバ定義の順に、引数を波括弧codice_25の中に記述するというものである。初期化リストは再帰的に適用されるので、構造体の配列や構造体を含む構造体にも使用できる。この初期化リストは、静的なデータの初期化や構造体を特定の値に初期化したいときなどに有用である。C++ にはコンストラクタもあるが、初期化リストの方が有用である。しかし、C++03 では初期化リストは Plain Old Data (POD) 型と認識された構造体・クラスにしか適用できなかった。codice_3 などの非 POD クラスには初期化リストは使えないのである。C++11 では、初期化リストの考え方がテンプレートと結び付けられた。これには、codice_27 を用いる。これによって、コンストラクタなどの関数は、初期化リストを引数として取ることができる。これにより、codice_28 は、整数の列から構築できるようになる。このコンストラクタは、初期化リストコンストラクタと呼ばれる特殊なコンストラクタである。このコンストラクタを持つクラスは、統一的な初期化構文の適用の際に特別に扱われる（後述）。codice_29 クラスは、C++11 標準ライブラリのファーストクラスの型である。しかし、これを構築できるのは、{ } 構文を用いてコンパイラが静的に構築する場合だけである。一度構築されたらその後コピーはできず参照渡しするしかない。初期化リストは定数であり、一度構築されたらそのメンバを変更することは出来ず、メンバ中のデータも変更できない。codice_27 は実際の型であるため、クラスコンストラクタのみならずそれ以外の場所でも使用できる。例えば、一般の関数の引数とすることもできる。C++03 には、型の初期化に関して多くの問題点があった。初期化に複数の方法があり、しかもお互いを取り替えたときに同じ結果になるわけではなかった。例えば、従来のコンストラクタの構文は関数宣言と同じ形をしており、場合によってはコンパイラが正しく判定できないことがあった。また、初期化リストは集約型やPOD型にしか使うことができなかった。C++11 では、どんなオブジェクトでも初期化できる完全に統一的な記法が導入された。これは初期化リスト構文の拡張である。codice_31 の初期化は完全に C 形式の初期化リストと同様に振る舞う。すなわち、各データメンバーは、初期化リストのそれぞれの値によってコピー初期化される。必要ならば暗黙の型変換が行われ、型変換が不可能ならば、コンパイルに失敗する。codice_32 の初期化は、単純にコンストラクタを呼ぶだけである。型が明らかな場合、次のように書くこともできる。統一的な初期化構文は、必ずしもコンストラクタ構文の代用となるものではない。コンストラクタ構文が必要な場合もある。クラスが初期化リストコンストラクタ(codice_33) を持つような場合、（初期化リストがシーケンスコンストラクタの型に適合するのならば）初期化リストコンストラクタが優先して適用される。例えば、C++11 の codice_3 は、そのテンプレート型の初期化リストコンストラクタを持つ。つまり、のように書いた場合、初期化リストコンストラクタが呼ばれる。固定長の codice_3 を生成するための、サイズを指定する引数ひとつを取るコンストラクタcodice_36を呼ぶためには、標準のコンストラクタ構文を使う必要がある。C++03やCでは、変数の型は使用に際して明示的に指定されねばならない。しかし、テンプレート型やテンプレートメタプログラミングなどにおいては、特に関数の戻り値型が複雑に定義されているような場合、型を簡単に書き下せないことがある。そのような場合には、中間結果を変数に格納することが難しく、メタプログラミングライブラリの内部仕様を知っていなくてはならなくなる場合もある。C++11 ではこの制約を軽減する方法が二つ提供された。一つ目の方法は、明示的に初期化される変数の定義に codice_37 キーワードを使う方法である。これにより、初期化子によって変数の型が特定される。codice_38 の型は、テンプレート関数 codice_39 がその引数に応じて返す戻り値の型である。これはコンパイラにとっては容易に判別できるが、ユーザーが調べるのは困難である。codice_40 の型はまだ分かりやすい。これは、整数リテラルの型である codice_41 となる。二つ目の方法は、キーワード codice_42 である。これによって、式の型をコンパイル時に決定できる。codice_37 で宣言した変数の型はコンパイラにしか分からないので、codice_42はcodice_37 と組み合わせて使うと特に有用である。codice_37 はコードの冗長性を省くのにも有用である。例えば、以下のように書かれている場合、codice_37を使えばもっと短く書くことができる。コンテナをネストして使うような場合、違いはもっと大きくなる。一方、そのような場合は codice_48 を使うこともできる。C++03では、リストの要素を列挙するためには多くのコードを書く必要があった。一方C#やJavaのような言語には、リストの最初から最後までをたどるシンプルな「foreach」文が備わっている。C++11にも同様の機能が追加された。codice_49文を使ってリストの要素を簡単に列挙することができる。この形式のcodice_49文は範囲に基づく (range-based) codice_49 と呼ばれる。この形式は、Cスタイルの配列や、初期化リスト、イテレータを返すcodice_52関数とcodice_53関数が定義されたあらゆる型に対して使うことができる。codice_52とcodice_53を持つ標準ライブラリのコンテナはすべてこの形式で列挙できる。C++ 標準では、特に codice_56 や codice_57 といった C++ 標準ライブラリのアルゴリズム関数と組み合わせた時に、アルゴリズム関数の呼び出しの近くで述語関数を定義したいと思う機会が多い。しかし、このためには関数内部でクラスを定義するしかなかった。この方法は記述量が多く、またコードの流れを妨げがちである。加えて、標準 C++ の規則では、関数の中で定義されたクラスをテンプレートの中で使うことを認めていないので、結局どうしても使うことは不可能であった。これに対して、C++11ではラムダ関数が定義できるようになった。ラムダ関数は以下のように定義される:これは、codice_41型の引数を二つとり、codice_41型の値を返すラムダ式である。その内容はcodice_25 の中に記述される。ラムダ関数の内容が "return "式" の形式である場合には、戻り値型を省略することができる。このラムダ関数の戻り値型は codice_61 になる。ラムダ関数が値を返さない場合、つまり戻り値型が codice_62 の場合も戻り値型を省略できる。ラムダ関数の外で定義された変数であっても、ラムダ関数の中で使用することができる。この種のものは一般にクロージャと呼ばれる。クロージャはcodice_63の中に記述する。これは、リストの全要素の合計を表示する例である。変数 codice_64 がラムダ関数のクロージャの一部として格納される。これはスタック変数 codice_64 への参照なので、代入することで外側の codice_64 の値も変更される。codice_67 は参照を表すシンボルである。スタック変数に対応するクロージャ変数は、codice_67を付けずに定義することも可能で、その場合はラムダ関数は値をコピーする。これにより、スタック変数を参照するのかコピーするのかどちらの意図があるのかわかるようになる。スタック変数を参照することは危険な場合がある。例えば (C++11 標準の) codice_69 オブジェクトに格納するなどして、ラムダ関数を生成したスコープの外側で使いたい場合は、ラムダ関数がスタック変数を参照していないことをよく確認する必要がある。ラムダ関数がその定義のあるスコープの内側で実行されることが保証されている場合は、次のように記述すれば、スタック変数をひとつひとつ指定せずに全ての利用可能なスタック変数を使用できる。codice_63の中には次のような指定が可能である。また、ラムダ関数がクラスのメンバ関数により定義された場合、そのクラスのフレンドであると見なされる。そのようなラムダ関数は、そのクラス型のオブジェクトへの参照を使って、内部のメンバにアクセスできる。この例は、このラムダ関数の生成するスコープが codice_71 のメンバ関数の中にある場合にのみ動作する。codice_72 ポインタは、各時点でメンバ関数が作動しているオブジェクトを指しているが、その扱いは特別である。ラムダ関数中に明示的な指定が必要になる。codice_73 または codice_74 形式のラムダ関数を用いていれば、codice_72の記述は必要ない。ラムダ関数の型はコンパイラ依存であり、明示的に記述することはできない。ラムダ関数を引数として取得したい場合は、その型をテンプレート型にするか、codice_69 などの型消去の仕組みを使う必要がある。codice_37 キーワードを使ってラムダ関数をローカル変数に格納することはできる。標準Cの関数宣言の構文は C 言語の機能に対しては最適なものであった。C++ は C から離れて発展してきたが、その基本的な構文を維持しつつ、必要に応じて拡張してきた。しかし、C++ がさらに複雑になってくると、多数の制約、特にテンプレート関数の宣言に関する制約が露呈するようになった。例えば、次の書き方は C++03 では認められていない。codice_78 型は、codice_79 と codice_80 の型を加算して作られる型であり、それらの実際の型によって決まる。前述の codice_42 という C++11 の機能を使うこともできない。パーサーが codice_82 を解析する時点で、codice_83 と codice_84 はまだ定義されておらず、有効な識別子にはなっていない。したがって、この書き方も C++ に適合していない。この問題に対処するために、C++11 では次のような関数の定義と宣言の構文が導入された。この構文は、非テンプレート関数の宣言や定義にも使用できる。この構文で使われるcodice_37キーワードは、自動型推論の場合とは異なった意味をもつ。現在のC++では、コンストラクタは他のコンストラクタを呼び出せず、各コンストラクタでクラスメンバの初期化を全て行わなくてはならない。これはしばしば初期化コードの重複を招く。また、基底クラスのコンストラクタは、派生クラスに直接は公開されない。つまり、基底クラスのコンストラクタと殆ど同等であったとしても、派生クラス側でコンストラクタを定義する必要がある。他にも、constでないデータメンバは、メンバの宣言時に初期化できず、コンストラクタで初期化しなければならない。C++11では、このような問題点に対する解決策が提供された。まず、C++11では、コンストラクタが他の同等なコンストラクタを呼び出すこと（委譲）が可能になる予定である。これにより、コンストラクタが他のコンストラクタを最小のコード追加で利用できるようになる。他の言語（Java等）では、既にこれを取り入れている物もある。構文は以下のようになるであろう:注意すべき点として、C++03では1つのコンストラクタの動作完了と同時にオブジェクトの構築は完了していると考えることができていたが、C++11では一度のオブジェクトの構築に"全ての"コンストラクタが動作完了しなければならない、と考えなくてはならない点である。複数のコンストラクタが動作することを認めるので、委譲を行う各コンストラクタは完全に構築が完了したオブジェクトに対して動作することを意味する。派生クラスのコンストラクタは、基底クラスでのコンストラクタ間委譲が全て終了した時点で呼び出されることになるであろう。次に基底クラスのコンストラクタに関して、C++11では、基底クラスのコンストラクタを継承する様にクラスに対して指定することが可能になる。これにより、コンパイラは派生クラスのコンストラクタ呼び出しを基底クラスのそれへと転送するコードを生成することになる。注意すべき点は、この機能は、全てのコンストラクタ呼び出しを基底クラスに転送するか、全く転送しないか、の二者択一の機能であることである。他の注意点として、多重継承時の制限もある。同じシグネチャを持つ2つのコンストラクタに転送することはできないし、転送先のコンストラクタと同じシグネチャを持つコンストラクタを後で宣言することはできない。構文は以下のようになるであろう:最後にメンバの初期化に関して、C++11では、メンバの初期化に以下のような構文が認められる:この例では、コンストラクタが初期化内容を上書きしない限り、codice_86は5に初期化される。上書きする例は次のようになる:この場合、空のコンストラクタではcodice_86はクラス定義に従って初期化されるが、int引数を取るコンストラクタの場合はその引数に従って初期化されることになるであろう。現行のC++標準では、ユーザーが基底クラスの仮想関数をオーバーライドする際、誤って意図に反する新しい仮想関数を作成する可能性がある：ユーザーがcodice_88を基底クラスの同名関数のオーバーライド関数として設計したが、引数の型が異なるため新しい仮想関数が生成される。C++11では、overrideキーワードの導入により、このような問題が解消された：コンパイラがoverrideキーワードで明示された仮想関数が基底クラスのオーバーライド先と一致するかをチェックし、一致しない場合にエラーを報告する。overrideの他にfinalキーワードがある。finalで表記された仮想関数のオーバーライドは許可されない。現行のC++標準では、定数codice_89に、整数定数とヌルポインタという2つの役割が与えられている（この振る舞いは、Cの黎明期（1972年）から続いている）。長い間プログラマは、codice_89の代わりに定数codice_91を使って、この潜在的な曖昧性を大体は回避してきた。しかし、C++になされた2つの設計上の選択が、新たな曖昧性をもたらした。Cでは、codice_91はプリプロセッサマクロであり、codice_93かcodice_89と展開されるよう定義されている。C++では、codice_95型から他のポインタ型への暗黙の変換は認められないので、Cの1つ目の定義と同じくNULLを定義すると、codice_96のような単純な例でもコンパイルエラーになる。これを修正するため、C++ではcodice_91はcodice_89へと展開される。codice_89は、あらゆるポインタ型への変換が特別に認められているのである。この結果、オーバーロード機構と酷い相互作用を引き起こす。例えば、以下のような宣言がありcodice_100として呼び出す場合、codice_101の方が呼ばれることになる。この挙動は、多くの場合に意図されたものではない。新標準では、ヌルポインタを指定するためにのみ予約された新たなキーワードcodice_102が導入される。codice_102は整数型との比較や代入はできないが、あらゆるポインタ型との比較・代入ができる。互換性のため、codice_89の現行の機能も残されるが、この新構文が上手くいけば、C++委員会はcodice_89とcodice_91をヌルポインタとして使用することを非推奨と宣言し、意味の重複を排除するであろう。C++03では、列挙型は型安全でなかった。列挙型が異なっていても、実質的には整数として扱われていた。このため、型の違う列挙型の値同士が比較できてしまった。C++03で唯一提供されていた型安全性は、整数や、ある列挙型の値が、暗黙的に他の列挙型には変換されない、ということだけである。また、内部的な整数型はコンパイラの実装に依存しており、列挙型のサイズに依存するコードは可搬ではなかった。さらに、列挙型の値のスコープは、列挙体が定義されたスコープと同じとなる。そのため、二つの列挙型が、同じ名前のメンバをもつことはできなかった。C++11では、以上のような問題のない、特別なクラス化された列挙型が導入された。codice_107（またはcodice_108）宣言を用いることで、これを表現できる。この列挙は型安全である。enum classの値が暗黙的に整数値に変換されることはなく、したがって整数値と比較することもできない（codice_109はコンパイルエラーになる）。enum classの内部的な型はコンパイラの実装に依存しない。デフォルトではcodice_41であり、次のように明示的に指定することもできる。列挙名は列挙型のスコープで定義される。列挙名を使うときには、codice_111のように明示的にスコープを指定しなければならない。上の例では、codice_112は未定義である。さらに、C++11では従来スタイルの列挙型にも、明示的なスコープや内部的な型の指定ができる。この場合、列挙名は列挙型のスコープで定義される（codice_113）が、後方互換性のため、列挙型が定義されたスコープにも定義される（codice_112）。C++11では列挙型の前方宣言も可能である。以前は列挙型のサイズが内容によって決まっていたため、列挙型は前方宣言できなかった。明示的あるいは暗黙的に列挙のサイズが決定できさえすれば、前方宣言が可能である。テンプレートを用いた総称プログラミングを導入するのに、新形式の括弧を導入するのが必要であった。そのためC++には、丸括弧"()"、角括弧"[]"、波括弧"{}"に加えて、山括弧"<>"が導入された。しかし、これにより字句的曖昧さが生じ、（プログラマの意図とは違う、という意味で）間違って解析され、構文エラーになるという事態が発生した:C++11の字句解析では、最も深くネストした開き括弧が山括弧"<"である場合、">"は、次に">"や"="が続いていても山閉じ括弧として扱われる。これにより、上記のエラーは最後のものを除いて修正される。最後のものを修正するには、曖昧さを取り除くために丸括弧を足さなくてはならない。こうすることで、"("から")"の間については、コンパイラは<>の文字を山括弧と扱わなくなる。C++規格には、一引数コンストラクタを暗黙的な型変換関数として扱われないようにするための修飾子として、codice_115キーワードが導入された。しかし、これは変換関数には何の効果も無い。例えば、スマートポインタのクラスは、本物のポインタと同じように振る舞うためにcodice_116を持っていることがある。この変換を追加することで、codice_117としてそれをテストできる（ポインタが非NULLならtrueを、NULLならfalseと判定できるはずである）。しかし、この変換を認めると、不本意な変換も発生してしまう。C++のcodice_118は算術型として定義されているため、整数型やさらには浮動小数点型としてまで変換されてしまい、ユーザーが意図しない数値型としての動作を引き起こしてしまうのである。C++11では、codice_115キーワードを変換関数にも適用できるようになる。コンストラクタへの適用と組み合わせ、さらなる暗黙的型変換を防止できる。C++03では、typedefを定義する際にできることは、他の型に対して別名を付けることだけであり、存在するすべてのテンプレート引数が指定されたテンプレートの特殊化に対して別名をつけることもこれに含まれる。typedefのテンプレートを作ることはできない。例えば:これはコンパイルできない。C++11では以下の構文でこれが可能になった。C++11ではcodice_120構文は型の別名付けにも使用できる。C++11には、透過的ガベージコレクションの機能は直接には導入されない。代わりに、C++11標準には、C++でのガベージコレクションの実装を容易にする仕様が導入された。完全なガベージコレクションのサポートは、もっと後の標準やTechnical Reportに回されることになった。C++標準にはcodice_121のメンバになれるオブジェクトの型に対する制限がある。例えば、trivialでないコンストラクタが定義されているオブジェクトは共用体の中に含めることが不可能である。共用体に課された制限の多くは無くてもよいと考えられたため、次期標準では参照型を除いて共用体のメンバの型の制限が全廃される。この変更により、共用体は使いやすく強力で有用なものになる。以下はC++11で許される共用体の簡単な例である:この変更は現行の規則を緩めるだけなので、既存のコードを破壊することはない。以下の機能は、従来のC++では全く不可能であったり、異常に冗長な記述が必要だったり、可搬性の無いライブラリを使わないといけなかったりしたような機能を提供するものである。現行の標準C++のテンプレート（クラステンプレート・関数テンプレート）は、あらかじめ決められた個数の引数しか取れない。C++11では、テンプレート定義の際にあらゆる型の引数を任意数取れるようになる:この"tuple"クラステンプレートは、 テンプレート引数としていくらでも型名を取れる:引数の数が0であったとしても、"class tuple<> someInstanceName"のように記述できる。可変長テンプレート引数の個数に0を認めない場合は、以下のように定義すればよい:可変長テンプレート引数を取る関数も定義でき、Cの可変長引数機構に似ているが、型安全な仕組みがもたらされる。テンプレート定義時には"Params"の左側に"..."演算子を配置するが、関数シグネチャ中では"Params"の右側に使うことを注意する必要がある。テンプレート引数仕様のように、"..."演算子を型名の左側におく場合、これは"pack"演算子となる。この演算子は、型が0個以上となり得ることを示す。"..."演算子が型名の右側にある場合は、"unpack"演算子であり、pack演算子でまとめられた型のそれぞれに対して、複製の処理が行われるようになる。上の例では、codice_122関数の引数にはcodice_123にそれぞれの型がまとめられて渡される。可変長テンプレート引数自体は関数・クラスの実装に使えるものではないため、可変長引数テンプレートの使用は再帰的に行われる。例えば、典型的な例として、C++11における"printf"の代替の定義例を以下に挙げてみよう:これは再帰呼び出しを使っている。可変長テンプレート引数バージョンの"printf"は自身を再帰的に呼び出し、"args"が空の場合はシンプルな方の"printf"が呼ばれることになる。可変長テンプレート引数に順次アクセスする簡単な方法は無い。しかし、unpack演算子を用いることで、どこでも仮想的にテンプレート引数を解体できる。例えば、クラスを以下のように使用できる:unpack演算子により、codice_124の各基底クラス型が複製され、このクラスは渡された各型の導出クラスとなる。また、codice_124の基底型を初期化できるように、コンストラクタは各基底クラスへの参照を取る。関数テンプレートでは、取った可変長引数を先へと転送できる。右辺値参照と組み合わせることで、完璧な転送が行える。この特殊なファクトリ関数は、メモリリークに対する安全性のため、割り当てられたメモリをcodice_126に自動的に包むものである。上記のように、引数リストを解体してcodice_127のコンストラクタへと渡している。codice_128構文で、const性などを保ちつつ、引数の適切な型をコンストラクタへと転送できる。unpack演算子により、それぞれのパラメータに上記の伝播文法を適用できる。また、テンプレートパラメータの数を以下のように決定できる:codice_129は2となり、codice_130は0となるであろう。現行の標準C++には2種類の文字列リテラルがある。1つ目は、ヌル終端されたcodice_131型配列を生成する、ダブルクオートで囲まれた形式のものである。2つ目は、ヌル終端されたcodice_132型配列を生成する、L" "で囲まれたものである。しかし、どちらもUnicodeで符号化された文字列リテラルをサポートするものではない。C++コンパイラでのUnicodeサポートを強化するため、codice_133型の定義が修正され、少なくとも8ビット符号単位のUTF-8符号化形式を格納できて、コンパイラの基本実行文字セットのあらゆる文字を格納するのに十分な大きさを持つ、とされた。以前は後者だけを満たしていれば良いとされていた。C++11では、UTF-8, UTF-16, UTF-32の3つのUnicode符号化形式がサポートされる。先ほど述べたcodice_133の定義の変更に加え、C++11には2つの新たな文字型、codice_135とcodice_136が加わる。それぞれ、UTF-16、UTF-32の符号単位を格納するよう設計されている。以下に、それぞれの符号化形式で文字列リテラルを作る方法を示す:1つ目の文字列の型は、普通のcodice_137である。2つ目は、codice_138であり、3つ目はcodice_139となる。Unicode文字列リテラルを作るときには、Unicodeの符号位置を直接に文字列に埋め込めると便利である。C++11では、以下のような構文が使えるようになる:'u'の後の数字は16進数であり、接頭辞'0x'をつける必要は無い。'u'は16ビットのUnicode符号位置を示すものであり、32ビットのUnicode符号位置を示す場合は'U'と16進数を用いる。正当なUnicode符号位置のみが入力できる。例えば、UTF-16のサロゲートペア（代用対）のために予約された、0xD800–0xDFFFの範囲の代用符号位置は使用できない。XMLファイルのリテラルを用いる場合や、スクリプト言語のリテラルを用いる場合など、手動でエスケープしなくてよい文字列も有用である。C++11では、raw文字列リテラルが導入される:1つ目の場合、()括弧記号で挟まれた箇所全てが文字列となる。'"'や''の文字はエスケープする必要は無い。2つ目の場合、codice_140からcodice_141までが文字列となる。codice_142という文字列は、実際には任意の文字列でよい。これにより、')'文字をraw文字列リテラルで使用できるようになる。raw文字列リテラルは、ワイドリテラルや各種Unicodeリテラルと組み合わせて利用できる。他の多くの言語と同様、現行の標準C++にも数種のリテラル値がある。例えば、"12.5"はコンパイラがcodice_143型の浮動小数点値へと変換するリテラル値である。しかし、リテラル値にはいくつもの修飾子がある。"12.5f"というリテラルは、浮動小数点値ではあるがcodice_144型の値を生成するように伝える。このような修飾子はC++仕様として規定されており、C++のコード中では新たな修飾子を生成することは不可能であった。C++11では、ユーザーが新たな種類のリテラル修飾子を定義できるようにし、リテラル修飾子の文字列を基にオブジェクトを生成できるようになる。リテラルの変換過程が再定義され、二つの段階、rawとcookedへと分けられた。rawリテラルは特定の型の文字の並びであり、cookedリテラルは単一の型である。例えば、C++リテラルのcodice_145は、rawリテラルとしてはcodice_146という文字の並びであり、cookedリテラルとしては整数値1234である。codice_147は、rawリテラルとしてはcodice_148であり、cookedリテラルとしては整数値10である。常にcooked形式として処理される文字列リテラルを除き、リテラルはraw形式にもcooked形式にも拡張される。文字列リテラルが例外なのは、文字列には、文字列の型と特別な意味の指定を行う接頭辞があるからである。ユーザー定義リテラルは全て接尾辞である。接頭辞リテラルを定義することは出来ない。raw形式のリテラルを処理するユーザー定義リテラルは、以下のように定義できる:1つ目の文で、接尾辞「_Suffix」を定義している。ユーザーが定義する接尾辞はアンダースコアで始める（アンダースコアで始まらないものは将来の標準のために予約されている）。2つ目の文では、ユーザー定義リテラル関数によって定義されたコードを実行している。この関数には、Cスタイルの文字列としてヌル終端された"1234"が渡される。rawリテラルを処理するもう1つの方法は、可変長引数テンプレートを使うことである:これにより、codice_149としてリテラル処理関数が実体化される。この形式では、文字列のヌル終端文字は無い。これを行う主目的は、C++11のcodice_16を使い、codice_151をconstexprで構築可能かつコピー可能とし、リテラル処理関数をcodice_16関数とすることで、コンパイラにリテラルの変換を完全にコンパイル時に行わせることである。cookedリテラルの場合は、cookedリテラルの型が使われ、代替となるテンプレート形式は無い:文字列リテラルの場合、以下のものが使用でき、前述の新たな文字列接頭辞と組み合わせられる:文字リテラルも同様に定義できる。C++標準化委員会はマルチスレッドの標準的サポートの導入を計画している。これには2つの側面がある。つまり、複数スレッドが1つのプログラム中で共存できるメモリモデルを定義することと、スレッド間相互作用のサポートを定義することである。2つ目に関してはライブラリによって提供される。#スレッディングを参照のこと。複数のスレッドが同じメモリ位置にアクセスする可能性がある環境下でのプログラム記述には、メモリモデルが必要となる。つまり、ルールを遵守するプログラムは正しく実行されるであろうと思われるが、ルールに従わないプログラムはコンパイラの最適化に依存する未定義の振る舞いや、の問題を抱えることになる。マルチスレッド環境においては、各スレッドごとに独立した変数が必要となることがある。このような変数は、関数でのローカル変数としては既に存在するが、グローバル変数、また静的変数としてはまだ無い。新たな"スレッドローカル"記憶クラスが、（現存の"static"、"動的"、"auto"に加えて）次期標準に提案されている。スレッドローカル記憶域は、記憶クラス指定子 codice_153によって指定することになるであろう。スレッドローカル記憶クラスは、static記憶クラスを持ち得るあらゆるオブジェクト（プログラムの実行期間全体にわたって存在しているようなもの）にも付けられるだろう。つまり、スレッドローカルなオブジェクトは、static記憶クラスの変数と同様のやり方で、コンストラクタで初期化されデストラクタで破壊されるということである。現行の標準C++では、オブジェクトにコンストラクタ、コピーコンストラクタ、代入演算子 (codice_154)、そしてデストラクタが与えられていない場合、コンパイラが自動的にそれらを提供する。ユーザーは自身のバージョンを定義することで、デフォルトの動作を上書きできる。また、C++は全てのクラスに適用されるグローバルな演算子（codice_155やcodice_156）も提供しており、その動作もユーザーが上書きできる。しかし、デフォルトで作られる関数の生成を制御する方法が非常に少ないという問題がある。例えば、クラスを実質的にコピー不能にするには、コピーコンストラクタと代入演算子をprivateとして宣言し、定義しないことによって実現できる。これらの関数を使用しようとすると、コンパイラやリンカがエラーを報告するようになるというわけである。しかし、これは理想的な解法とはいえないであろう。さらに言えば、例えばデフォルトコンストラクタなど、コンパイラに対して明示的に生成するよう伝えておくことも有用である。オブジェクトに「どんなものであれ一つでも」コンストラクタが定義されているのであれば、コンパイラはデフォルトコンストラクタを生成しない。また、特別なコンストラクタとコンパイラが生成するデフォルトとを両方持っておくことも有用な場面がある。C++11では、これらコンパイラが生成する関数の使用・不使用を明示できるようになる。例えば、以下のクラスはデフォルトコンストラクタの使用を明示している:また逆に、明示的に無効にすることも可能である。以下の例はコピー不能な型の例である:codice_157演算子で割り当てられないようにすることも出来る:このオブジェクトは、スタック上か、他の型のメンバとしてしか割り付けられない。移植性の無いトリックを使いでもしない限り、直接ヒープには割り当てられないのである（ユーザー割り当てのメモリ上にコンストラクタを呼ぶ方法は配置newしかなく、その使用は上記のように禁じられているので、オブジェクトは適切に構築できない）。codice_158という指定は、どんな関数の呼び出しも禁止できる。これは、メンバ関数を特定の型で呼び出すのを禁止するのに使える。例えば:codice_143でcodice_160を呼ぼうとすると、暗黙のcodice_41への変換を行うのではなく、コンパイラによってエラーになる。以下のようにすることで、codice_41型以外の型では呼べないようにする総称化が出来る:32ビットのシステムにおいて、最低でも64ビットあるような整数型、codice_163があると便利である。C99標準では既にこの型が標準Cに導入されているし、C++用コンパイラの殆どで長期的にサポートされている拡張でもある（実際、コンパイラによってはC99で導入される前からサポートしているものもある）。C++11でも同様に、この型が標準C++に導入される。これは、一部の64ビットシステム上では余り有用ではない。一般的な64ビットシステム上でのデータサイズを挙げると:（これはLP64と呼ばれるモデルである）それでも、32ビットシステムや、64ビットWindows環境（LLP64モデルであり、longが32ビットである)では、64ビット整数としてcodice_163を使うのが根強い。C++委員会は、C委員会（お互いに連絡を取っており、グループに大きな重なりがあるが、C++委員会とは独立である）の決定と合わない新たな組み込み型の標準化を避けてきた。しかし今や、codice_163（略してcodice_170）は事実上の標準であり、さらにはC99で本当の標準化もされているので、この難局も解消されるだろう。C++委員会はcodice_163を組み込み型として認可する予定である（codice_172も含まれる）。将来的に、十分な要求があったり、128ビットのレジスタを持つようなプロセッサが現れたりすれば、codice_163は128ビット型として使われるようになるだろう。C++標準には、表明を確認する2つの方法として、codice_174マクロとcodice_175プリプロセッサディレクティブがある。しかし、このどちらもテンプレート使用時には不適切である。codice_174マクロでの確認は実行時であり、codice_175プリプロセッサディレクティブでの確認はプリプロセス時である。どちらもテンプレート実体化時の確認には使えないため、テンプレート引数に依存する特性の検証には適していない。そこで、コンパイル時点での表明確認の新たな手法として新たなキーワードであるcodice_178が導入される。宣言は以下のような形になるであろう:以下に、codice_178の使用法の例を挙げる:"constant-expression"がcodice_180となる場合、コンパイラはエラーメッセージを生成する。1つ目の例はcodice_175プリプロセッサディレクティブの代替の例である。2つ目の例の方は、codice_182クラステンプレートの各実体化において表明の確認をしている。静的な表明はテンプレート以外での使用も有益である。例えば、codice_170がcodice_41より大きいサイズであることに依存するアルゴリズムの実装のように、標準では保障されていない箇所の確認などの用途がある（このような仮定はほとんどのシステム、コンパイラで正しいだろうが、全ての環境で正しいとは言えない）。現行の標準C++では、codice_185演算子は型とオブジェクトに対してしか適用できない。そのため、以下のようには使用できない:この例では、codice_186のサイズを取得したい所であるが、C++03ではこれは不正となりコンパイルエラーとなる。C++11では認められる。ちなみに、C++03で同様のことをしたい場合、以下のようにすればよい:大量の新機能が、C++11標準ライブラリに追加される。新しいライブラリの多くは現行の標準規格で実装できるが、C++11のコア言語の新機能に（程度の差はあれど）依存しているものもある。導入されるライブラリの大部分は、"C++ Standards Committee's Library Technical Report"（TR1と呼ばれる）の文書で定義されている。TR1の最終稿は、2005年に出されている。TR1ライブラリの実装は既に数種類が利用可能であり、codice_187名前空間を用いて呼び出せる。C++11ではcodice_188名前空間に移動される。委員会は、2つ目のTechnical Report (C++ Technical Report 2)をC++11の標準化後に予定している。C++11に間に合わないライブラリ提案は、TR2や、さらに先のTechnical Reportに置かれることになる。以下の提案は、C++11に搭載されることが予定されているものである。C++11では言語に多数の新機能が提供され、既存の標準ライブラリもその恩恵を受けられる。例えば、大半の標準ライブラリのコンテナは右辺値参照に基づいたムーブコンストラクタを利用して、重いコンテナを高速に移動したり、新たなメモリ位置に中身を移動できる。標準ライブラリは必要に応じてC++11の新機能を使って改良される予定である。それには下記のようなものが含まれるが、必ずしもこれだけに限定されるわけではない。加えて、C++が標準化されてから長い時間が経過し、標準ライブラリを使った大量のコードが書かれてきた。その結果、改良を施すことができる標準ライブラリの部分が明らかになった。その場所の多くは標準ライブラリのアロケータである。C++11には現在のアロケータのモデルを補うためにスコープに基づく新しいモデルが含まれる。スレッドクラスにより、関数オブジェクトを元に新たなスレッドの起動が可能になる。各時点において、あるスレッドが実行中のスレッドへのjoin（スレッドの終了を待つこと）も可能である。（可能であれば）ネイティブスレッドオブジェクトにアクセスし、プラットフォーム固有の操作を行うことも可能となるだろう。スレッド間の同期のためにミューテックスや条件変数がライブラリに追加され、RAII方式のロックやロックアルゴリズムの使用も容易になる。低レベル処理の高効率性のためには、スレッド間通信をミューテックスのオーバーヘッドなしで行う機能も必要となる。これは、適切なメモリバリアと不可分操作を用いることで達成できる。不可分操作ライブラリにより、各操作を行うのに必要な最小限の同期だけを指定できる。スレッドプールのような高レベルスレッディング用のライブラリも作業中であるが、C++11標準にすべて搭載されてはいない。C++11では主に基礎となるライブラリが定義され、将来のTechnical Reportに含まれることが望まれる。タプルとは、決められた次元数の、異なる種類の型のオブジェクトから構成されたコレクションである。ペア (std::pair) を拡張して、任意の数のオブジェクトを格納できるようにしたものと考えても良い。あらゆる型のオブジェクトが、タプルの要素になりうる。この新ユーティリティは、新ヘッダとC++言語拡張を通して実装される。つまり:以下が、codice_189ヘッダで定義されているタプルである:タプル型の定義例、使用例を挙げる:タプルcodice_190を内容の定義なしに生成することも可能であるが、タプル要素の型がデフォルトコンストラクタを持つ場合に限られる。さらに、タプルを別のタプルに代入することも可能である。ただし、代入可能なのは、タプルの型が同じで各要素の型がコピーコンストラクタを持つ場合、もしくは右辺側のタプルの各型が左辺側のタプルのそれぞれの型と変換可能な場合、左辺側のタプルの各要素型が適切なコンストラクタを持つ場合である。比較演算子も使用可能であり（タプルの要素数が同じ場合）、タプルの特性を確認する2つの式が使用可能である（コンパイル時のみ）。C++標準ライブラリへのハッシュテーブル（順序付けの無い連想コンテナ）の導入要求は、最も繰り返されてきた要求の1つである。これは、時間的な制約のみのために、現在の標準（1995年、1998年）に導入されなかった。ハッシュテーブルは最悪の場合（大量の衝突が発生）の効率は平衡木に劣るが、現実のアプリケーションでは多くの場合効率的である。衝突の管理は、チェイン法によってのみ行われる。これは、委員会には、多くの実装上の問題（特に要素の消去が認められるような場合）があるオープンアドレス法を標準化する機会がないからである。非標準のライブラリの持つ、独自のハッシュテーブル実装と名前が衝突しないように、"hash"の代わりに"unordered"を使用している。ハッシュテーブルには4種類あり、同じキーを持つ要素を認めるかどうかと、キーに値を関連付けるかどうかで区別される。新クラスは、コンテナクラスの要件を全て満たし、要素へのアクセスに必要な全てのメソッドを備える:codice_196, codice_197, codice_198, codice_199.この新ユーティリティは、C++言語の拡張は必要ない。codice_200ヘッダへの小さな拡張と、codice_201ヘッダ、codice_202ヘッダの導入を行うのみである。他の標準クラスには変更の必要がなく、標準ライブラリの他の拡張にも依存しない。正規表現のために作られた、多くの非標準、準標準のライブラリがある。このようなアルゴリズムを使うのは非常に一般的なので、オブジェクト指向言語の能力を用いて、標準ライブラリにもこの機能が導入される。新ライブラリでは、新ヘッダcodice_203が定義され、2つの新クラスが導入される:検索のためにcodice_206関数が使われ、「検索と置換」とためにcodice_207関数が使われ、新たな文字列を返す。アルゴリズムcodice_206とcodice_207は正規表現と文字列を取り、結果をcodice_205に収める。以下にcodice_205の使用例を示す:注意: C++の文字列リテラルではバックスラッシュはエスケープ文字として扱われるため、例ではバックスラッシュを二つ重ねている。C++11のraw文字列機能により、この問題は回避できる。codice_212ライブラリは、既存のヘッダの変更や言語拡張を必要としない。動的メモリ確保は、プログラミング言語の歴史においても昔からの論点である。多くの現代的プログラミング言語（Javaなど）は、自動メモリ管理の仕組みを備えている。C++のポインタには、多くの興味深い性質がある:C++のポインタの主要な欠点は:新たな"スマートポインタ"は、通常のポインタの利点を維持したまま、弱点を大幅に削ったものである。新テンプレートクラスcodice_214は、現在の標準C++ライブラリに存在するauto_ptrに似ているが、同じオブジェクトに対する「同等の」参照をカウントする機能が追加され、関連するスマートポインタ間でオブジェクトの所有権を共有する。さらに、標準コンテナの要素とすることも可能である。同じオブジェクトを参照するポインタの数を得るには、codice_214のメンバ関数であるcodice_216が使えるだろう。メンバ関数codice_217は、スマートポインタをリセットする。リセットされたポインタは「空」になり、codice_216を呼び出すとゼロを返す。以下に、codice_214の使用例を示す:これと関連し、弱い参照としてcodice_220テンプレートも導入される。これもスマートポインタ・参照と同様に振舞うが、codice_214との違いは、参照先の値がポインタによって「所有」されず、弱参照ポインタが存在していても破壊され得る点である。これは、弱参照ポインタには参照先オブジェクトが破壊されてしまうことによる実行時エラーが発生しやすいことを意味している。しかしこれにより、オブジェクトの生存時間に影響しない形で参照を持つことが可能となり、循環参照を防止できる。このユーティリティはcodice_222ヘッダに変更を必要とするが、C++言語拡張は必要としない。また、codice_223がcodice_224の代わりとして導入され、codice_224は非推奨とされる。codice_223はcodice_224の全機能を提供するが、左辺値からの暗黙的な移動の際に起こる挙動が異なる。codice_223は、C++11のMove Semanticsを用いたコンテナになっている。コンピュータは決定的な振る舞いをするものであるが、乱数列を生成することにより、（外見だけでも）非決定的な振る舞いが必要となるようなアプリケーションがある。標準に用意されている方法は、codice_229関数のみである。しかし、十分な定義がされていないため、そのアルゴリズムは完全にライブラリ開発者に任せられている。新たな乱数生成ユーティリティはcodice_230ヘッダを通して定義される。他のヘッダやC++言語への修正は必要としない。乱数生成器は、内部状態と、結果を計算し次の状態を生成するための関数をもつ。この2つの特性によって、乱数生成エンジンが定まる。他の特性として、生成結果や乱数の間隔や密度の分布も重要である。新ライブラリには、数種の擬似乱数生成エンジンが導入される。これらはテンプレートクラスであり、必要に応じて特殊化できる。擬似乱数エンジンの内部状態は種（一般には変数の集合）によって決定される。※使われる型の次元数・バイト数倍される。エンジンの質はクラステンプレートcodice_231を用いて向上でき、クラステンプレートcodice_232と組み合わせることも可能である。利便性のため、codice_230ヘッダには数種の標準エンジンが定義されている。例として、codice_234から実体化されるcodice_235クラスを示す。codice_236クラスを用いて、codice_237型の非決定的乱数を生成できる。実装には、システムから独立した入力を持つデバイス（例えば、非同期的な外部カウンタや、特殊なトランスデューサーなど）の使用や、伝統的な「結果を調節する」擬似乱数エンジンの使用が必要である。libstdc++やlibc++では、/dev/urandomを読み出す実装となっている。 新ライブラリには、一様分布から確率論で定義された分布まで、多種類の分布が定義されている: 明らかであるが、標準の分布を実体化しても構わないし、ユーザ自身の互換性のある分布を用いても構わない。以下は、新ライブラリを用いた簡単な例である:参照ラッパはテンプレートクラスcodice_247のインスタンスとして得られる。参照ラッパは、C++言語の通常のリファレンス ('&')にも似ている。オブジェクトから参照ラッパを得るには、テンプレート関数codice_248を使う（constな参照の場合はcodice_249が使用される）。参照ラッパはテンプレート関数と使用する場合に有用であり、特に引数としてコピーではなく参照を取る必要がある場合に便利である:この新ユーティリティは現在のcodice_250に追加される。C++言語の拡張は必要としない。関数オブジェクトの多相的ラッパ（「多態的関数オブジェクトラッパ」とも呼ばれる）は、意味的にも構文的にも関数ポインタに似ている。しかし、引数がラッパの引数型と変換可能である関数を参照できる点

出典:wikipedia