コードに追加し始めましnoexceptたが、わざわざインライン関数に追加するのが賢明かどうか疑問に思っています。明らかに不要な場合、オプティマイザーは実行時チェックを省略すると思います...しかし、人間/スタイルの観点から、ゲッター、設定、インクリメント関数などの簡単な関数に noexcept を追加する価値はありますか? 完全に明白な何かの視覚的な混乱だと思います。私は、インライン関数が noexcept を省略できるというルールについて議論していますが、通常の .hpp/.cpp 関数は、スローしない場合はそれを持たなければなりません。
第二に、(チェス エンジンに) 割り当てがなく、STL やその他の失敗する可能性のあるものが含まれていないため、まったくスローできないコードが大量にあるため、成功は常に保証されます。実行時チェックのために noexcept が遅くなることはありませんか? マクロを使用してビルドnoexcept用に切り替えるが、コンパイル時のみのリリース用に切り替える人はいますか?DEBUGthrow()
インライン関数がリーフレベルの関数である場合、つまり関数自体を呼び出さない場合、理論的には、コンパイラはそれがスローされず、そうでなければ生成された可能性のある例外処理を省略すると判断できます。したがって、パフォーマンスに関しては、不要であることが判明する可能性があります。
そうは言っても、追加によるパフォーマンスの低下は期待できませんnoexcept。例外の伝播を処理するために生成する必要があったコードは、noexcept. noexcept 関数から例外がスローされた場合、コンパイラはスタックの巻き戻しを完全に省略できることに注意してください。これは主に、 の直接的なメリットがnoexceptもたらされる場所です。
スタイルの推奨事項については、何よりもまず、それnoexceptがインターフェイスの有用な部分になるかどうかを検討してください。移動操作などはnoexcept、アルゴリズム上の理由から大きなメリットを得ることができますが、それ以外にもnoexcept、あなた、インターフェース、およびインターフェースのユーザーにとってどこに価値があるかを決定するのは、実際にはあなた次第です。
これがあなたの質問に答えない場合は、私の答えにコメントしてください。さらに明確にします。
補足:throw()は、C++11 で非推奨になっているだけでなく、 と同じ保証を与えませんnoexcept。宣言された関数によって例外がスローされた場合throw()、スタックはその関数の呼び出し元まで完全に巻き戻されなければなりません。この動作については、C++ 標準のバージョン N3337 の 15.5.2.1 を参照してください。
関数に noexcept または noexcept(true) 指定子を追加することで、ランタイム チェックを追加して std::terminate を呼び出すようにコンパイラに要求します。したがって、パフォーマンスにわずかな影響があります。あなたはそれから何かを得るはずです。さもなければ私には意味がありません。標準ライブラリには次の特徴があります。
is_nothrow_constructible,
is_nothrow_default_constructible,
is_nothrow_move_constructible,
is_nothrow_copy_constructible,
is_nothrow_assignable,
is_nothrow_move_assignable,
is_nothrow_copy_assignable,
is_nothrow_destructible.
標準ライブラリのコンテナーは、含まれている型でこれらの特性を使用して最適化 (コピーではなく移動) を実行することが知られています。多分他のいくつかの最適化、私は知りません。これは、適切なコンストラクターまたは代入演算子に noexcept 指定子を追加すること (もちろん、実際にスローしない場合) に意味があります。標準コンテナーでクラスを使用する場合、これらの特性は true を返し、パフォーマンスが向上します。
getter や setter などの通常の関数に noexcept を追加するのは良い考えではないと思います。パフォーマンスが低下し、何も得られません。コードがスローせず、標準ライブラリを使用しない場合 - 私のアドバイス: noexcept はまったく使用しないでください。