問題タブ [noexcept]

このnoexceptキーワードは多くの関数シグネチャに適切に適用できますが、実際にいつ使用するかはわかりません。私がこれまで読んだことによると、最後の最後の追加はnoexcept、moveコンストラクターがスローするときに発生するいくつかの重要な問題に対処しているようです。noexceptしかし、そもそも私がもっと読むようになったいくつかの実際的な質問に対して、私はまだ満足のいく答えを提供することができません。

1. 私が知っている関数の例はたくさんありますが、コンパイラーはそれを自分で判断することはできません。そのような場合はすべてnoexcept、関数宣言に追加する必要がありますか？

   すべての関数宣言のnoexcept後に追加する必要があるかどうかを考えなければならないことは、プログラマーの生産性を大幅に低下させます（そして、率直に言って、首の痛みになります）。どのような状況で、の使用にもっと注意を払う必要がありますか？また、どのような状況で暗黙の使用を回避できますか？noexceptnoexcept(false)

2. 使用後のパフォーマンスの向上を現実的に期待できるのはnoexceptいつですか？特に、.を追加した後、C++コンパイラがより優れたマシンコードを生成できるコードの例を挙げてnoexceptください。

   noexcept個人的には、特定の種類の最適化を安全に適用するためにコンパイラーに提供される自由度が増したため、私は気にかけています。最新のコンパイラnoexceptはこのように利用していますか？そうでない場合、近い将来、それらのいくつかがそうすることを期待できますか？

noexceptに頭を悩ませています。

これは単純な関数ですが、idx <= 0 の場合にのみ例外がスローされることがわかります。わかりません。したがって、私の仕様 noexcept(idx > 0) では、この関数は idx > 0 の場合にのみ例外をスローしないことをコンパイラに伝えようとしています。

助けていただければ幸いです。正しく説明していることを願っています。簡単な説明だけでも結構です。

C ++ 11は、修飾子inlineで宣言された他の関数を呼び出すときに、関数またはメソッドに関する保証を提供しますか？noexcept

最適化コンパイラは、noexcept資格に従って、完全なEHとスタックの巻き戻しなしでインラインメソッドを自由に実装できると思います。単純なアクセサーメソッドでもこれを期待します。

この例は些細なことのように見えますが、他のクラスや関数を実装するために使用する場合は、例外の保証が重要になります。Q： C ++ 11標準はこれに対応していますか、それともインラインメソッドにマークを付ける必要がありnoexceptますか？または、クラスまたは関数の仕様に一致する必要noexceptがない限り、省略する方がよいでしょうか。

編集：混乱を避けるために：noexceptインラインメソッドには暗黙的ですか？

実行時とコンパイル時にそれぞれチェックされる以外に違いはありますthrow()か?noexcept

このウィキペディアの C++11 の記事では、C++03 のスロー指定子が非推奨であることを示唆しています。
なぜ、noexceptコンパイル時にすべてをカバーするのに十分なのですか?

[注:この質問とこの記事を確認しましたが、非推奨の明確な理由を特定できませんでした。]

関数呼び出し間の伝播をテストするために次のコードを作成しましたが、noexcept思ったように機能しないようです。GCC 4.7.2 では、関数は、noexcept直接またはテンプレート特殊化引数として渡された場合にのみ効果的にテストできます。ただし、テンプレート化された関数に引数として渡された場合、または通常の関数への関数ポインターとして渡された場合はそうではありません。その関数がその仮パラメーターを として宣言している場合でもnoexcept。コードは次のとおりです。

出力は次のとおりです。

noexceptネスが他の場合に伝播されないのはなぜですか? の場合、test1関数全体が の適切な型で「インスタンス化」されF、コンパイラはその時点で F がnoexcept関数であるかどうかを確実に認識します。ness宣言が完全に無視されているのに、なぜ私が書いtest3たように書くことができるのでしょうか?noexcept

標準はこれについて具体的に何かを言う必要がありますか?

例外安全なコードを書こうとしています。C++11 の noexcept 指定子を使用すると、この目標がはるかに達成しやすくなることがわかりました。

もちろん、一般的な考え方は、関数が呼び出すすべての関数も「noexcept」としてマークされている場合にのみ、関数を「noexcept」としてマークする必要があるということです。

問題は、さまざまな人々からのパッチがマージされることが多い大規模なコード ベースでは、この一貫性を維持するのが難しいことです。

したがって、「nothrow」とマークされた関数が「nothrow」とマークされていない関数を呼び出すすべての場所をリストできる静的分析を実行できるようにしたいと考えています。

マンページを見る限り、GCC はここで私を助けることはできません。役立つスタンドアロン ツールはありますか? それとも他のコンパイラですか？

次のコード スニペットをご覧ください。

clang svn の下では、正常にコンパイルされます。ただし、gcc 4.7.2 では、アサーションは失敗します。どちらが正しいですか？(gcc が正しければ、なぜですか?)

noexcept指定子とコンパイラの最適化に関する不明確なことを読みました。noexceptコンパイラを指定すると、次のことが最適化される場合があります。

• コンパイル時間（より高速なコンパイル）。
• 実行時間（コードの実行速度が速くなります）。
• または両方？
• またはなし？

デストラクタとnoexcept. 私の理解では、C++ 11 では、ユーザー定義を含むすべてのデストラクタはnoexcept(true)、たとえそれthrowからであっても、暗黙的に です。noexcept(false)そして、何らかの理由でそのようにしたい場合は、明示的に指定する必要があります。

GCC 4.7.2 では、ユーザー定義のデストラクタは、クラスとデストラクタがどれほどプリミティブであっても、暗黙的にnoexcept(false)です。ここで何が欠けていますか？ユーザー定義のデストラクタに関する隠れた落とし穴はありますか?