std::variantは、C++17で導入された、安全な型のユニオンの代替手段であり、エラーが発生しやすく手動管理されたCスタイルのユニオンを置き換えるために設計されています。それは、常に指定された代替型の1つを保持するという不変条件を強制し、コンパイル時の型安全性と直感的な値のセマンティクスを提供します。この設計は理論的には、std::visitやstd::getのような操作が常に有効な型を操作することを保証します。
valueless_by_exception状態は、型変更操作中に例外が発生したために、変種が値を保持していない特定の失敗モードを表します。この状況は、変種が新しい代替のためのスペースを確保するために現在の代替を破棄しなければならないときに発生しますが、その後の新しい代替の構築が例外を発生させると、オブジェクトは有効なアクティブメンバーを持たず、標準の変種の不変条件が一時的に破られます。
標準が提供する解決策は、基本的な例外安全性の保証を維持するために、この単一の無効状態を特に許可することです。この状態の間、変種は破壊可能であり、代入可能であり、リソースをクリーンアップし、新しい値をストレージに配置することができます。この条件から完全に回復するには、新しい値を正常に代入または配置する必要があり、有効な代替を確立し、内部状態をリセットすることで不変条件を復元します。
std::variant<std::string, int> v = "hello"; try { v.emplace<std::string>(10000000, 'x'); // bad_allocを投げる可能性あり } catch (...) { assert(v.valueless_by_exception()); v = 42; // 回復：再び有効 }
市場データメッセージを処理する高頻度取引システムを考慮してください。メッセージはstd::variant<PriceUpdate, OrderCancel, TradeExecution>として表されます。メモリが制約されている状況下で、大きなTradeExecutionオブジェクトを代入しようとすると、変種はすでに前のPriceUpdateを破棄してスペースを確保しているため、std::bad_allocを投げます。このシーケンスは、無価値な変種がパイプラインを通じて伝播し、下流のコードが有効なデータが存在すると仮定した場合に連鎖的な失敗を引き起こす可能性があります。
1つの解決策は、訪問または取得操作の前に、すべての変種アクセスを**valueless_by_exception()**チェックと手動回復ロジックでラップすることでした。このアプローチは未定義の動作に対する明確な安全性を提供しましたが、あらゆる使用地点で防御的なチェックでコードベースが混雑し、可読性が著しく低下し、重要な取引経路での受容できない遅延を引き起こしました。
別のアプローチは、**std::optional<std::variant<...>>**を使用して、空の状態を変種自体の外部に外部化することを検討しました。これにより、内部の変種が常に有効な型を保持することで内部の不変条件が保持されましたが、二次的な間接層が導入され、すべてのアクセスに対して二重逆参照が必要になり、APIの表面が複雑になり、高スループット処理中のキャッシュの局所性に影響を与える可能性がありました。
チームは最終的に、変種のタイプリスト内で明示的な「空」の状態を予約するために、std::monostateを変種タイプリストの最初の代替として選択しました。この選択により、変種が無価値になる可能性が完全に排除され、常にstd::monostateを保持できるため**index()**が常に有効な位置を返し、std::visitがリアルデータまたは空の状態ハンドラに成功裏にディスパッチされることが保証されます。
その結果、割り当て失敗を優雅に処理する堅牢なメッセージプロセッサが生まれ、無価値な無効状態ではなくモノステート代替に移行しました。このデザインは、無価値性のランタイムチェックを必要とせず、二重間接オーバーヘッドに苦しむことなく、厳密な型安全性を維持しました。開発者は変種が常に訪問可能であることを信頼でき、モノステートハンドラは空のメッセージについてのノーオプまたはデフォルト動作として機能しました。
なぜstd::variantは、変種が常にその指定された型の1つを保持すべきという一般的な設計原則に反して状態valueless_by_exceptionを許可するのか？
標準は、強力な例外安全性を、不変条件を維持することのコストを超えて優先します。保持されている代替を変更する際、変種は、リソースのリークや二重所有権の問題を防ぐために、新しい値を構築する前に古い値を破棄しなければなりません。この新しい構築が例外を投げた場合、変種は以前の状態にロールバックできず、そのストレージはすでに破棄されているため、新しい状態への移行を完了することができません。valueless_by_exception状態は、オブジェクトが破棄可能であり代入可能ではあるが、有効な代替を保持していないことを示す必要な脱出口として機能し、古い値がまだ存在しているかのように振る舞ったり、ストレージが未初期化のままであることから生じる未定義の動作を防ぎます。
状態valueless_by_exceptionの変種に対してstd::visitが呼び出された場合、どのように動作し、これがstd::monostateを保持する変種にアクセスすることとどのように異なるのか？
std::visitは、アクティブタイプインデックスがvariant_nposであり、訪問者オーバーロードにマッピングされないため、無価値な変種に遭遇するとすぐにstd::bad_variant_accessをスローします。これは、特定のインデックス位置を占める正当な空の型であるstd::monostateとは根本的に異なります。訪問者は、通常の制御フローの一部として空の状態を優雅に処理するためにstd::monostateに特定のオーバーロードを提供できます。無価値な状態は、型情報が完全に失われている真のエラー状態を表していますが、モノステートは、型システム内の有効で意図的な空の状態を表しており、訪問のディスパッチメカニズムに参加します。
無価値_by_exception状態から、変種オブジェクト自体を破棄して再構築することなく回復できますか？また、この回復を助ける特定の操作は何ですか？**
はい、回復は変種のラッパー自体を破棄することなく代入またはemplace操作を通じて可能です。v = T{}またはv.emplace<T>(args)を実行する際、型Tの構築が成功すれば、変種は無価値状態を脱出し、新しい型を保持します。これは、これらの操作が新しいアクティブな代替を確立するように定義されているため、ストレージが有効な値で再初期化され、内部インデックスがvariant_nposからTの位置にリセットされるからです。変種から単に読み取ることや非修正のオブザーバーを呼び出すことでは、状態は変わりません。有効な値をストレージに配置する成功した操作のみが、クラスの不変条件を回復し、無価値フラグをfalseにリセットできます。