map.emplace(key, value_args...) のような引数を使用して std::map::emplace を呼び出す場合、C++ 標準は実装に対して、一時的な std::pair<const Key, T>（またはそのノードの同等物）を構築することを要求します。その後でキーの一意性をチェックします。もしキーが既に存在している場合、このノードは即座に破棄され、マップされた値 T の高コストな構築が無駄になります。
std::piecewise_construct タグは、この動作を変更し、後続の2つのタプル引数をそれぞれキーと値のコンストラクタへの引数リストとして扱うようにコンテナにシグナルを送ります。コンストラクタ引数を std::forward_as_tuple でラップすることにより、コンテナはマップされた値の実際のインスタンス化を新しく割り当てられたノード内に遅延させ、キーが一意であることが確認された場合にのみ実行します。これにより、値が最終的なメモリ位置で正確に一度だけ構築され、挿入が失敗した場合には決して構築されないことが保証されます。
高頻度取引プラットフォームでは、デシリアライズされた Order オブジェクト（ベクターと文字列を含む重い構造体）を std::map<OrderID, Order> にキャッシュする必要がありました。最初の実装は orders.emplace(id, DeserializeOrder(buffer)) を使用していました。プロファイリングにより、市場の急騰時に15%の CPU 時間が、重複する ID のために直ちに破棄された Order オブジェクトの構築に無駄に費やされていることが明らかになりました。
解決策 1: チェック後挿入。 挿入を呼び出す前に if (orders.find(id) == orders.end()) を明示的にチェックすることを検討しました。これにより無駄な構築を避けましたが、2回の木の走査が必要になり—1回は find、もう1回は emplace—比較コストを倍増させ、キャッシュの局所性を悪化させました。
解決策 2: 手動ノード抽出。 orders.extract(id) で手動で std::map::node_type を作成し、空の場合は再挿入することを検討しましたが、これにはノードを埋めるためにマップの外で Order を前もって構築する必要があり、元の問題が再導入されました。
解決策 3: std::piecewise_construct。 orders.emplace(std::piecewise_construct, std::forward_as_tuple(id), std::forward_as_tuple(buffer)) を採用しました。これにより、ノードが挿入されることが保証されるまでデシリアライズが遅延されました。このことでパフォーマンスの問題は解決されましたが、構文は冗長で引数のライフタイムに関してエラーが発生しやすくなりました。
選ばれたアプローチと結果: 最終的に私たちは C++17 に移行し、orders.try_emplace(id, buffer) を使用しました。これにより、成功した挿入のみに基づく Order の構築が行われる効率保証が得られ、構文がクリーンになり、ダングリング参照のリスクが減少しました。システムのレイテンシはピーク負荷時に12%低下しました。
std::piecewise_construct の引数を準備する際に、std::make_tuple の代わりに std::forward_as_tuple を使用しなければならないのはなぜですか？
std::make_tuple は、その引数を崩してタプルを作成します。値をタプルストレージにコピーまたはムーブします。もしマップされた型がコピー不可であるか、または大きなオブジェクトを渡している場合、make_tuple はコンパイルに失敗するか、無駄なコピーオーバーヘッドを伴います。std::forward_as_tuple は、元の値のカテゴリを保持する参照（左辺値または右辺値）のタプルを作成し、間接的なコピーなしに直接オブジェクトのコンストラクタへパーフェクトフォワーディングを可能にします。
std::piecewise_construct を使用する際、std::forward_as_tuple でラップされた参照が挿入の完了まで有効であることを確実にすることがなぜ重要ですか？
forward_as_tuple は、それに渡された一時オブジェクトのライフタイムを延長しません；それは単に参照をキャプチャするだけです。もし map.emplace(std::piecewise_construct, std::forward_as_tuple(CreateTempKey()), std::forward_as_tuple(args...)) と書いた場合、CreateTempKey() が返す一時オブジェクトは、emplace が内部でノードを構築しようとする前に、全体の式の終わりで破棄されます。これにより、タプルはダングリング参照を保持することになり、その結果、コンストラクタがキーにアクセスするときに未定義の動作が発生します。
std::map::try_emplace は、キー自体の扱いに関して emplace + piecewise_construct のイディオムとどう違うのですか？
piecewise_construct はキーと値の両方の構築を遅延させることができる一方で、try_emplace はキーと値の構築引数を明示的に分離します。try_emplace はキーを参照（または値）として受け取り、挿入が成功した場合にのみ残りの引数をマップされた型のコンストラクタに転送します。これは、try_emplace が複数の引数からキーをインプレースで構築できないことを意味し—キーオブジェクトは既に存在するか、単一の引数から構築可能である必要があります—対して piecewise_construct は両方のコンポーネントの構築を遅延させることができます。しかし、try_emplace は手動のタプル管理の構文上の冗長性とライフタイムに関する危険を排除します。