問題タブ [noexcept]

g++ 4.9 および clang 3.4 でテストすると、このコードがコンパイルされないのはなぜですか。

しかし、このコードは次のことを行います。

f_helper 関数を定義する必要はありません。その場合、decltype によって指定された正しい戻り値の型が必要です。

最初のコードも 1 つまたは 2 つの引数に対してコンパイルされますが、3 つ以上の引数で呼び出そうとすると、呼び出す関数が一致しないというエラーが発生します。最初のコードの clang エラーは次のとおりです。

通常 newは、割り当てが失敗した場合、または構築が失敗した場合にスローできます (他のケースがある場合は修正してください)。ただし、配置 new はスペースを割り当てないため、コンストラクターがTスローしない場合、new 式はスローできますか?

つまり、次のnoexcept仕様は正しく安全ですか?

通常、C++03 までのデストラクタは、任意の例外をスローすることが許可されていました。

ただし、C++11 では、明示的な例外指定のないすべてのデストラクタがnoexceptデフォルトになりました。これはオーバーライドできますnoexcept(false)が、このコードは C++11 より前のコンパイラでは受け入れられません。

noexcept(false)1 つの解決策は、コンパイラ固有の s をチェックすることによっての必要性を検出することです#defineが、これでも既知のコンパイラ セットに対するそのようなコードの適用可能性は制限されます。

С++11 と C++03 の両方でデストラクタから任意の例外をスローできる移植可能な方法はありますか?

次のコードをコンパイルしようとしてclang++ -std=c++11 -cいますが、失敗します:

Clang 3.4.2 で表示されるエラー メッセージは次のとおりです。

ここで何が欠けていますか？

Scott Meyers の新しい C++11 ブックからの次のドラフトには、次のように書かれています (2 ページ、7 ～ 21 行)。

コール スタックの巻き戻しと、場合によっては巻き戻しの違いは、コード生成に驚くほど大きな影響を与えます。noexcept 関数では、オプティマイザは、例外が関数の外に伝播する場合にランタイム スタックを巻き戻し可能な状態に保つ必要はありません。また、例外が関数を離れた場合に、noexcept 関数内のオブジェクトが構築の逆の順序で破棄されることを保証する必要もありません。 . その結果、noexcept 関数の本体内だけでなく、関数が呼び出されるサイトでも最適化の機会が増えます。このような柔軟性は、noexcept 関数に対してのみ存在します。「throw()」例外仕様を持つ関数には、例外仕様がまったくない関数と同様に、それがありません。

対照的に、「C++ パフォーマンスに関するテクニカル レポート」5.4のセクションでは、例外処理を実装する「コード」および「テーブル」の方法について説明しています。特に、「table」メソッドは、例外がスローされず、スペースのオーバーヘッドのみがある場合、時間のオーバーヘッドがないことが示されています。

私の質問はこれです - Scott Meyers が巻き戻しとおそらく巻き戻しについて話しているとき、どのような最適化について話しているのですか? これらの最適化が適用されないのはなぜthrow()ですか? 彼のコメントは、2006 年の TR で言及されている「コード」メソッドにのみ適用されますか?

インターネットでどこを読んでも、自分のクラスをうまく機能させたい場合std::vector(つまり、自分のクラスのムーブ セマンティクスが によって使用された場合std::vector) は、ムーブ コンストラクターを 'noexcept' (またはnoexcept(true)) として宣言する必要があることを強くお勧めします。

実験としてstd::vectorマークしたのに、なぜそれを使用したのですか?noexcept(false)

出力：

なんで ？私は何を間違えましたか？

CXX_FLAGS を次のように設定して gcc 4.8.2 でコンパイル:

noexcept の使用にどれだけ注意を払うべきかについて、社内で議論が持ち上がりました。noexcept は、コンパイラのオプティマイザーに対して実際にはそれほど多くのことをしないことを知っていますnoexcept はstd::move_if_noexcept<>を使用するコード用で、ほとんどが STL コンテナーとそのアルゴリズムであると想定されます。

したがって、評価は次のようになります。次の場合を除き、noexcept を使用しないでください。

1. callable の実装がコンパイラに認識されない extern 関数およびクラス。

2. コンストラクターを移動し、代入演算子を移動し、STL コンテナーに含まれる可能性のある型を交換します。

3. それ以外の場合は、心配しないでください。

これは公正な評価ですか？何かが noexcept の場合に、より最適なコードを生成する STL の他の場所はありますか? もしそうなら、これはどのSTL実装であり、それが機能するためにnoexceptとマークする必要があるものは何ですか?また、どのようなパフォーマンス上の利点(メモリ割り当ての削減、複雑さの軽減)が得られますか?

編集： CashCowの提案された文言の変更を行いました。