なぜemplace_backの代わりにpush_backを使用するのですか？

C ++ 11ベクトルには新しい関数がありますemplace_back。push_backコンパイラの最適化に依存してコピーを回避するとは異なり、emplace_back完全な転送を使用して引数をコンストラクターに直接送信し、オブジェクトをインプレースで作成します。私にemplace_backは、すべてのpush_backことができるように思えますが、場合によっては、それがうまくいくこともあります（悪くなることはありません）。

どのような理由で使用する必要がありますpush_backか？

過去4年間、私はこの問題についてかなり考えてきました。push_backvs に関するほとんどの説明emplace_backは全体像を見逃しているという結論に達しました。

昨年、私はC ++ Now でC ++ 14の型の演繹についてプレゼンテーションを行いました。push_backvs. についてemplace_back13:49 から話し始めますが、その前にいくつかの裏付けとなる証拠を提供する有用な情報があります。

実際の主な違いは、暗黙的なコンストラクターと明示的なコンストラクターに関係しています。push_backまたはに渡したい引数が1つある場合を考えemplace_backます。

std::vector<T> v;
v.push_back(x);
v.emplace_back(x);

最適化コンパイラーがこれを手に入れたら、生成されたコードに関してこれら2つのステートメントに違いはありません。従来の知識ではpush_back、一時的なオブジェクトが作成され、次にそのオブジェクトが移動されvますemplace_backが、引数は転送され、コピーや移動なしで直接配置されます。これは、標準ライブラリで記述されたコードに基づいて当てはまる可能性がありますが、最適化コンパイラの仕事は記述したコードを生成することであると誤って想定しています。最適化コンパイラの仕事は、実際には、プラットフォーム固有の最適化の専門家で、保守性を気にせず、パフォーマンスだけを気にしていた場合に記述したコードを生成することです。

これらの2つのステートメントの実際の違いは、より強力なものemplace_backはあらゆるタイプのコンストラクターpush_backを呼び出すのに対し、より注意深いのは暗黙的なコンストラクターのみを呼び出すということです。暗黙のコンストラクタは安全であると想定されています。Uからを暗黙的に作成できる場合T、はUすべての情報をT損失なく保持できると言っています。aを渡すことはほとんどすべての状況で安全でTあり、U代わりにa にしても誰も気にしません。暗黙的なコンストラクターの良い例は、からstd::uint32_tへの変換std::uint64_tです。暗黙的な変換の悪い例はdoubleへの変換ですstd::uint8_t。

プログラミングには注意が必要です。強力な機能を使用するのは望ましくありません。強力な機能を使用するほど、誤って予期しないことを簡単に実行してしまうからです。明示的なコンストラクターを呼び出す場合は、の能力が必要ですemplace_back。暗黙のコンストラクタのみを呼び出したい場合は、の安全性を守ってくださいpush_back。

例

std::vector<std::unique_ptr<T>> v;
T a;
v.emplace_back(std::addressof(a)); // compiles
v.push_back(std::addressof(a)); // fails to compile

std::unique_ptr<T>からの明示的なコンストラクタがありT *ます。emplace_backは明示的なコンストラクターを呼び出すことができるため、所有していないポインターを渡しても問題なくコンパイルされます。ただし、vスコープから外れると、デストラクタは、スタックオブジェクトであるためdelete割り当てられなかったポインタを呼び出そうとしnewます。これは未定義の動作につながります。

これは発明されたコードだけではありません。これは私が遭遇した本番のバグでした。コードはstd::vector<T *>でしたが、コンテンツを所有していました。C ++ 11への移行の一環として、ベクターがそのメモリを所有しているT *ことstd::unique_ptr<T>を示すように正しく変更しました。ただし、私はこれらの変更を2012年の理解に基づいていました。その間、「emplace_backはpush_backで実行できるすべてのことを行うので、なぜpush_backを使用するのですか？」と考えたため、もに変更しpush_backましたemplace_back。

代わりに、より安全なを使用するようにコードを残した場合push_back、私はこの長年のバグを即座にキャッチし、C ++ 11へのアップグレードの成功と見なされたでしょう。代わりに、私はバグをマスクし、数か月後までそれを見つけませんでした。

push_back常に均一な初期化の使用を許可します。これはとても気に入っています。例えば：

struct aggregate {
    int foo;
    int bar;
};

std::vector<aggregate> v;
v.push_back({ 42, 121 });

一方、v.emplace_back({ 42, 121 });動作しません。

C ++ 11以前のコンパイラとの下位互換性。

emplace_backの一部のライブラリ実装は、Visual Studio 2012、2013、2015に同梱されているバージョンを含め、C ++標準で指定されたとおりに動作しません。

既知のコンパイラのバグに対応するためにstd::vector::push_back()、パラメータがイテレータまたは呼び出し後に無効になる他のオブジェクトを参照する場合に使用することをお勧めします。

std::vector<int> v;
v.emplace_back(123);
v.emplace_back(v[0]); // Produces incorrect results in some compilers

1つのコンパイラでは、vには、予想される123と123ではなく、値123と21が含まれます。これは、2回目の呼び出しのemplace_back結果、サイズが変更され、その時点でv[0]無効になるためです。

上記のコードの実際の実装でpush_back()はemplace_back()、次の代わりに使用します。

std::vector<int> v;
v.emplace_back(123);
v.push_back(v[0]);

注：intのベクターの使用は、デモンストレーションを目的としています。動的に割り当てられたメンバー変数を含むはるかに複雑なクラスでこの問題が見つかりemplace_back()、ハードクラッシュが発生しました。