質問への回答
歴史：C++11で導入されたstd::initializer_listは、Cスタイルの集約初期化と現代のC++コンテナコンストラクタとの間のギャップを埋めるために設計されました。これは、const要素のコンパイラ生成配列を参照する二つのポインタ（またはポインタとサイズ）を含む軽量集約として実装されています。この設計は、リテラルリストをstd::vectorのコンストラクタのような関数に渡す際のゼロオーバーヘッドを重視しています。
問題：基盤となる配列は、一時オブジェクトであり、そのライフタイムはstd::initializer_listが作成される完全表現に結びついています。クラスがstd::initializer_listそのものを保持するのではなく、その内容をコピーせずに保存すると、メンバーは解放されたスタックメモリへのポインタのみを保持します。以降のアクセスは未定義の動作を引き起こし、ガーベージデータや再現が難しいクラッシュが発生します。
解決策：std::initializer_listをクラスメンバーとして保存しないでください。代わりに、std::vectorやstd::arrayのような所有コンテナに要素を早めにコピーしてください。ゼロコピーが必要な場合は、外部管理されたストレージを持つstd::span（C++20）を使用するか、イテレータを介して範囲を受け入れてください。これにより、データがコンストラクタ呼び出しより長生きし、オブジェクトのライフタイムに対して有効であることが保証されます。
class Bad { std::initializer_list<int> list_; public: Bad(std::initializer_list<int> list) : list_(list) {} // 危険 int sum() const { int s = 0; for (int i : list_) s += i; // UB: ダングリングポインタ return s; } }; class Good { std::vector<int> vec_; public: Good(std::initializer_list<int> list) : vec_(list) {} // 安全: データをコピー int sum() const { return std::accumulate(vec_.begin(), vec_.end(), 0); } };
生活からの状況
我々は、高頻度取引の構成ローダーでこの問題に遭遇しました。MarketConfigクラスは、そのコンストラクタで初期化リストを通じてデフォルトの価格階層を受け入れるため、MarketConfig cfg{{1.0, 2.0, 3.0}}のような構文をサポートしました。あるジュニア開発者は、「ヒープアロケーションを避ける」ために、メンバーとして**std::initializer_list<double>**を直接保存し、後でパケット処理中に階層を反復しようとしました。
提案された解決策の一つは、呼び出し元によって渡されたconst std::vector<double>&を保存することでした。これにより、呼び出し元がベクターのライフタイムを保持している場合、コピーが排除されますが、カプセル化を侵害し、一時リストのための持続的ストレージを呼び出し元に管理させることになります。別のオプションは、std::array<double, N>をテンプレートパラメータとして使用することでしたが、これは階層の数をコンパイル時に知らなければならず、これは動的にJSONオーバーレイから読み込まれる構成では不可能でした。
選択されたアプローチは、初期化リストをコンストラクタの直後にstd::vector<double>メンバーにコピーすることでした。これにより、階層データの単一のアロケーションとコピーが発生しましたが、構成状態の安全性と不変性が保証されました。変更後、プロダクションシミュレーション環境での偶発的なクラッシュが消え、Valgrindはもはや「サイズ8の未初期化値の使用」を報告しませんでした。
候補者がしばしば見落とすこと
なぜ const 参照にバインドされた std::initializer_list がメンバーに保存したときに基盤となる配列がダングリングしないのか？
標準では、std::initializer_listのバックアレイは一時的なものであり、そのライフタイムは、現在のスコープでリファレンスにバインドされたinitializer_listオブジェクト自体によってのみ延長されることが規定されています。std::initializer_listをコピーしてコンストラクタに渡すと、一時的な配列はコンストラクタが戻るまで生き続けます。リストをメンバーにコピーすることは、ポインタペアを複製するだけです。したがって、メンバーは構築表現が終了すると解放されたスタック空間を指します。元の引数がどのようにバインドされていたかに関係なく。
"初期化リストコンストラクタが勝つ"ルールは、 std::vector のコンストラクタオーバーロードセットとどのように相互作用し、 std::vector<int>(5, 10) と std::vector<int>{5, 10} はなぜ異なるのか？
直接リスト初期化（波括弧）に対するオーバーロード解決中に、C++は、引数リストがリストの要素タイプに暗黙的に変換できる場合、他のコンストラクタよりもstd::initializer_listを取るコンストラクタを優先します。**std::vector<int>**の場合、{5, 10}はinitializer_list<int>コンストラクタを選択し、2つの要素（5と10）のベクターを作成します。対照的に、(5, 10)はsize_t, const int&コンストラクタを選び、10で初期化された5つの要素のベクターを作成します。候補者は、非リストコンストラクタが通常のオーバーロード解決ルールに基づいてより適切である場合でも、この優先順位が適用されることを見落とすことが多いです。
constexpr関数はstd::initializer_listを安全に返すことができますか？ その場合、どのようなストレージ期間の制約がありますか？**
constexpr関数はstd::initializer_listを返すことができますが、基盤となる配列はランタイムで関数が呼び出された場合、自動ストレージ期間を持ちます。関数がコンスタント式コンテキストで呼び出された場合、配列は通常静的な読み取り専用メモリに保存されるため、安全になります。しかし、ランタイム引数で呼び出されたconstexpr関数からstd::initializer_listを返すと、関数スコープを終了した時点でダングリングポインタが発生します。これは、非constexpr関数と全く同様です。候補者はしばしばconstexprを「静的ストレージ」と混同し、返されたリストが常に無期限に有効であると誤って仮定します。