キーワードnoexceptは多くの関数シグネチャに適切に適用できますが、実際にいつ使用することを検討すべきかはわかりません。これまでに読んだ内容に基づくと、最後の最後に追加された は、noexcept移動コンストラクターがスローするときに発生するいくつかの重要な問題に対処しているようです。ただし、そもそも についてさらに読むきっかけとなったいくつかの実用的な質問に、まだ満足のいく回答を提供できませんnoexcept。
例外をスローしないことはわかっているものの、コンパイラが独自にそれを判断できない関数の例はたくさんあります。このようなすべての場合
noexceptに関数宣言に追加する必要がありますか?すべての
noexcept関数宣言の後に追加する必要があるかどうかを考える必要があると、プログラマーの生産性が大幅に低下します (そして率直に言って、面倒です)。 の使用についてより注意する必要がある状況はどれですか。また、暗黙の で済む状況はどれですか。noexceptnoexcept(false)を使用した後、パフォーマンスの向上が実際に見られるのはいつでしょうか
noexcept? 特に、 を追加した後に C++ コンパイラがより良いマシン コードを生成できるコードの例を示してくださいnoexcept。noexcept個人的には、コンパイラーに特定の種類の最適化を安全に適用するための自由度が増すため、この点は気になります。最近のコンパイラーはnoexcept、この点をうまく活用しているでしょうか。そうでない場合、近い将来に一部のコンパイラーが活用するようになると予想されますか。
ベストアンサー1
実際に使用するための十分な時間がないため、これに対する「ベスト プラクティス」の回答を出すのは時期尚早だと思います。throw 指定子がリリースされた直後にこれについて質問された場合、回答は現在とは大きく異なるものになります。
すべての関数宣言の後に追加する必要があるかどうかを考える必要があると、
noexceptプログラマーの生産性が大幅に低下します (率直に言って、面倒です)。
そうですね、関数が決して例外をスローしないことが明らかな場合に使用してください。
を使用した後、パフォーマンスの向上が実際に見られるようになるのはいつでしょうか? [...] 個人的には、特定の種類の最適化を安全に適用するためにコンパイラーに提供される自由度が増すため
noexcept、 を気にしています。noexcept
チェックやオーバーロードの可能性があるため、コンパイラによる最適化ではなく、ユーザーによる最適化が最大の最適化の利点であるように思われますnoexcept。ほとんどのコンパイラは、例外をスローしない場合はペナルティなしという例外処理方法に従っているため、処理コードを削除することでバイナリ サイズを縮小することはできるかもしれませんが、コードのマシン コード レベルで大きな変化 (または何らかの変化) が生じるとは考えられません。
noexcept4 つの主要メソッド (コンストラクター、代入、デストラクタは既に ) で を使用すると、コンテナなどのテンプレート コードではチェックが「一般的」であるnoexceptため、最も優れた改善が実現される可能性があります。たとえば、 は、マークされていない限り(またはコンパイラが推測できない限り)、クラスの移動を使用しません。noexceptstdstd::vectornoexcept