問題タブ [uniform-initialization]

私はこの問題を奨励します: もし私が持っているなら

gcc は次のように与えます:

move.cc: 関数 'int main()' 内: moves.cc:15:7: エラー: 'A' A b{a} の初期化子が多すぎます。

しかし、A b{a} の代わりに A b(a) を使用すると、すべて正しくコンパイルされます。デフォルトのコンストラクターを宣言すると、それもコンパイルされます。なぜそう機能するのですか？

C++

キーワードなしで1 つのパラメーター (または、1 つを除いてすべてが既定値を持ついくつかのパラメーターを持つ ctor への 1 つの引数呼び出し) を使用するコンストラクターは、1 つの暗黙的な変換を実行できることを読みました。の ctor に2 つのパラメーターがあり、のctor に2つのパラメーターがある 2 つのクラスがある場合、そのステートメントは、修飾されていない s の2 つのセットによる のctor への呼び出しが、2 つの の ctorへの呼び出しに変換されるべきではないことを暗示しているようです。では、なぜ次のコードはコンパイルされるのでしょうか?explicitFoo intBar FooBarintBarFoo

均一な初期化を使用するように一部のコードを更新する際に、現在の「古いスタイル」の括弧スタイルのドロップインのモダンな代替品になると思いました。これが常に当てはまるとは限らないことはわかっていますが (明らかな例vector<int>)、理解できない別の違いに出くわしました。

エラーで clang3.5 の下でコンパイルに失敗します: (gcc でも失敗します)

これを機能させるには、2 つの異なる変更がありますObject。それにデータ メンバーを追加するか、空のコピー コンストラクタ本体を指定します。

これらが違いを生む理由がわかりません。

次のコードは、XCode 5.0 を使用して正常にコンパイルされますが、Visual Studio 2013 ではコンパイルされません。

これは、Visual Studio が報告するエラーです。

クラス定義でこのようなベクトルを初期化する方法の例を見つけることができませんでした。

どのコンパイラが正しいですか?

構文が有効でない場合、コンストラクター初期化子リストで m_vector を初期化する唯一のオプションはありますか?

C++11 では、{} スタイルの初期化が導入されました。しかし、これらの2つの形式は

同じ？

均一な初期化は、重要かつ便利な C++11 機能です。{}ただし、次の理由から、どこでも使用できるわけではありません。

egの集約初期化にstd::arraysは の使用が必要であることに注意してください。ベクトル コンストラクターが選択される{{}}問題全体は、 を使用してコンストラクターを呼び出す必要があることで回避できたように思えます。{{}}std::initializer_list

これは議論されたと思いますが、これに反対する理由は何でしたか? 標準的な提案からの引用/リンクは、回答として優先されます。

アップデート。— N2532には次のような記述があります。

(3) 厄介なあいまいなケースは、短い初期化子リストの場合にのみ発生します [...]

(5) なぜ言語規則は、(完全に正当な理由で) 簡潔さとあいまいさの制御を望むプログラマーに、(完全に正当な理由で) より明示的であることを好むプログラマーを喜ばせるためにもっと書くことを強制する必要がありますか?

[...]

プログラマーが f(X) が呼び出されることを期待しているとします。af(Y) はどのようにして通話を「ハイジャック」するのでしょうか?

(4) X には初期化子リスト コンストラクターがないが、Y にはあると仮定します。この場合、initializer-list コンストラクターに与えられた優先順位は、ハイジャッカーに有利に働きます (プログラマーが何らかの形で f(X) が呼び出されることを予期していたことを思い出してください)。これは、ユーザー定義の変換を使用して f(y) が f(X) を呼び出すことを誰かが期待し、誰かが正確に一致する f(Y) を持ってくることに似ています。{…} を使用する人は、初期化子リスト コンストラクターの可能性を覚えていると期待するのが妥当だと思います。[鉱山を強調]

キーはcan beにあると思います。つまり、均一な初期化を使用する必要はありません。{}次の理由から、正しく使用するのは困難です。

• 呼び出したいコンストラクターをチェックするだけでなく、initializer_listそれに勝つ可能性のある (そしておそらく勝つ)コンストラクターを取得するコンストラクターもチェックする必要があります。

• を使用してコードを記述{}し、将来誰かがstd::initializer_listコンストラクターを追加すると、コードが壊れて静かに行われる可能性があります。

AコンストラクターA(int, bool)と を持つクラスがある場合でもA(std::initializer_list<double>)、後者は前者よりも選択されます( IMOA a{0, false};はナッツです) 。コンストラクタ。initializer_list

あなたのコードが静かに壊れる可能性があるという事実は、私を大いに心配させます.