歴史: C++11以前、std::vectorは再割り当て中にコピー操作のみを依存していました。なぜならムーブセマンティクスが存在しなかったからです。C++11でムーブセマンティクスが導入され、性能の大幅な向上が約束されましたが、重要な安全性のジレンマも引き起こしました。再割り当ての途中でムーブコンストラクタが例外をスローすると、コンテナは元の状態に簡単に戻れなくなります。なぜなら、ソースオブジェクトがムーブ後の状態に残される可能性があるからです。
問題: std::vectorがその容量を使い果たし、拡張が必要になると、既存の要素を新しいメモリに転送する必要があります。このプロセス中に例外が発生すると、強い例外安全性の保証により、コンテナが元の状態を維持することが要求されます（全か無かのセマンティクス）。しかし、ムーブコンストラクタがスローすることは、ソースオブジェクトを破壊的に変更するため、この要件に違反します。もし100番目のムーブがスローされた場合、前の99個の要素はすでに破壊されているか無効になっており、ロールバックは不可能です。
解決策: C++標準は、std::vectorがstd::move_if_noexcept（またはstd::is_nothrow_move_constructibleによる同等のコンパイル時トレイト検出）を使用してムーブとコピーの操作を選択することを義務付けています。要素型のムーブコンストラクタがnoexceptとしてマークされていない場合、ベクターは保守的にコピー操作に戻ります。コピーはソースオブジェクトをそのままに残すため、例外をキャッチでき、元のバッファは触れられなくなり、強い保証が維持されます。
問題の説明: 高頻度取引エンジンにおいて、リアルタイム市場深度を表すオーダーブックのスナップショットを保持するstd::vectorを管理していました。市場のオープンスパイク時に頻繁にベクターの拡張が必要でした。このシステムは超低遅延（マイクロ秒の感度）と完全なクラッシュ安全性を必要とし、再割り当て中に発生する例外はオーダーブックの状態を壊したりメモリリークを引き起こすことはできませんでした。
解決策 1: 事前確保によるオーバープロビジョニング 非常に大きな容量（例えば、100万要素）を前もって確保して再割り当てを完全に回避することを考えました。利点: 拡張中の例外リスクを排除し、ポインタの安定性を保証します。欠点: 低アクティビティ期間中（1日の99%）にかなりのRAMを浪費し、同居サーバーのメモリ制約に違反し、容量を超えるブラックスワンイベントに対処できません。
解決策 2: std::listに切り替え 再割り当ての必要を排除するためにstd::vectorをstd::listに置き換えました。利点: 自然に強い例外安全性が保証され、イテレータが安定しています。欠点: キャッシュローカリティが破壊され（イテレーションが5-10倍遅くなる）、ノードごとのメモリオーバーヘッド（16-24バイト余分）、マルチスレッド環境でのアロケータ競合を引き起こす断片化。
解決策 3: noexceptムーブセマンティクスの強制 すべてのスナップショットタイプをstd::unique_ptrを使用してヒープリソースに変更し、ムーブコンストラクタを明示的にnoexceptとしてマークしました。利点: ムーブが速く（コピーより80%速い）、強い例外安全性を維持し、標準コンテナと互換性があります。欠点: ムーブの経路に例外をスローする操作を持たないことを保証するための厳密なコードレビューが必要で、クラス設計に制約（ムーブ内でスローするリソース取得を使用できない）が発生します。
選ばれた解決策: 解決策 3を選び、すべての重要なデータ構造をnoexceptムーブ可能にするためのコードベース監査を実行しました。**static_assert(std::is_nothrow_move_constructible_v<Data>)**を使用して再発を防ぐための静的アサーションを追加しました。
結果: 市場のスパイク時の遅延が42%減少し、注入された例外を伴うストレステスト中にゼロの破損イベントを維持しました。このシステムは例外安全性に関する規制監査要件を満たしました。
なぜstd::vectorは再割り当て中に特に強い例外安全性を要求するのか、基本的な保証ではなく？ 基本的な例外安全性は、プログラムがリソースリークなしに有効な状態に留まることだけを要求します。これにより、コンテナが部分的に移動された状態に残ることができます。しかし、再割り当てはユーザーの視点からは原子的な操作です—バッファポインタが変更されるか、されないかのいずれかです。もしstd::vectorが基本的な安全性しか提供しなかった場合、例外が発生すると、コンテナは古いメモリにある要素と新しいメモリにある要素の両方を持つか、一貫性のないサイズ/容量カウントを持つことになり、クラスの不変条件に違反し、次の操作で未定義の動作を引き起こす可能性があります。強い保証は取引的なセマンティクスを保証します: 成長が完全に成功するか、ベクターは正確にそのままであるかのどちらかです。
コンパイラは実行時のオーバーヘッドなしでnoexceptムーブコンストラクタのチェックを最適化する方法は？
std::vectorは、std::is_nothrow_move_constructible<T>を利用しています。これはコンパイル時のトレイトです。実装は通常、スローされる可能性のあるムーブコンストラクタに対してコピーをトリガーするlvalue参照を返し、スローされない場合にムーブをトリガーするrvalue参照を返す関数テンプレートであるstd::move_if_noexceptを使用します。このディスパッチは、関数のオーバーロードとテンプレートインスタンス化を通じてコンパイル時に発生し、ランタイムのブランチなしに最適なコードパスを生成します。ムーブがnoexceptであることが証明されると、コンパイラはフォールバックコピー経路を完全に削除できるため、コストゼロの抽象化が実現されます。
ムーブのみの型（コピー不可）でそのムーブコンストラクタがnoexceptでない場合はどうなりますか？
std::unique_ptrのような（ムーブのみの）型が例外をスローするムーブコンストラクタを持っている場合（仮定的に）、std::vectorは不可能な選択に直面します。コピーできず（型がコピー不可）、安全にムーブもできません（スローする可能性があります）。C++17以前には、再割り当てが必要な操作でコンパイルエラーが発生していました。C++17以降、標準はstd::vectorがスローされるムーブを使用することを義務付けていますが、基本的な例外安全性のみを提供します—ムーブがスローされた場合、要素が失われたり、コンテナが不特定の有効な状態に残される可能性があります。これが、標準ライブラリ内のすべてのムーブのみの型（std::unique_ptr、std::fstreamなど）がnoexceptムーブを保証する理由であり、カスタムのムーブのみの型もそれに従うべき理由です。