noexceptを実際に使用する必要があるのはいつですか？

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

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

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

2. 使用後にパフォーマンスの改善が見られるのはいつ現実的に期待できnoexceptますか？特に、C ++コンパイラーがを追加した後でより優れたマシンコードを生成できるコードの例を示しますnoexcept。

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

これを実際に使用するのに十分な時間がなかったため、「ベストプラクティス」の答えを出すのは時期尚早だと思います。スロー指定子が出た直後にこれについて尋ねられた場合、答えは今とは大きく異なります。

noexceptすべての関数宣言の後に追加する必要があるかどうかを考える必要があると、プログラマーの生産性が大幅に低下します（率直に言って、苦痛になります）。

それでは、関数がスローしないことが明らかな場合に使用します。

使用後にパフォーマンスの改善が見られるのはいつ現実的に期待できnoexceptますか？[...]個人的には、noexcept特定の種類の最適化を安全に適用するためにコンパイラーに提供された自由の増加のために気にしています。

最適化による最大の効果は、ユーザーによる最適化によるものであり、コンパイラーによるものではなく、チェックnoexceptとオーバーロードの可能性があるためです。ほとんどのコンパイラーは、例外なしの例外処理方法に従っているため、コードのマシンコードレベルで多くの（または何でも）変更されるとは思えませんが、おそらく、コードの処理。

使用noexcept四大に（彼らはすでにしているようなコンストラクタ、代入、デストラクタではないnoexceptとして可能性の高い最善の改善の原因になります）noexceptチェックは、このようなのようなテンプレートコードの「一般的」でありstd、容器。たとえば、std::vectorマークされていない限り、クラスの移動は使用しませんnoexcept（または、コンパイラはそれ以外の場合はそれを推測できます）。

私が最近繰り返しているように：セマンティクスを最初に。

追加noexcept、noexcept(true)およびnoexcept(false)セマンティクスについてまず第一です。偶発的に、いくつかの可能な最適化が調整されるだけです。

プログラマーがコードを読んでいるとき、の存在はの存在noexceptと似てconstいます。これにより、発生する可能性のあるものと発生しない可能性のあるものを理解することができます。したがって、関数がスローするかどうかを知るかどうかを考えるのに時間をかける価値があります。念のため、あらゆる種類の動的メモリ割り当てがスローされる場合があります。

では、可能な最適化について説明しましょう。

最も明白な最適化は、実際にはライブラリで実行されます。C ++ 11は、関数が存在するかどうかを知ることができるいくつかの特性を提供します。noexcept標準ライブラリの実装自体は、それらの特性を使用してnoexcept、可能であれば、操作するユーザー定義オブジェクトの操作を優先します。このような動きの意味。

それがあるため、コンパイラは、データを例外処理からの脂肪（多分）のビットを剃ることがあり、アカウントにあなたが嘘をついているかもしれないという事実を取ること。マークされた関数noexceptがスローする場合std::terminateは、呼び出されます。

これらのセマンティクスが選択された理由は2つあります。

• noexcept依存関係がまだ使用していない場合でもすぐにメリットがあります（下位互換性）
• noexcept理論的にはスローされる可能性があるが、指定された引数では予期されない関数を呼び出すときの指定を許可する

これは実際には、コンパイラーのオプティマイザーに（潜在的に）大きな違いをもたらします。コンパイラーは、実際には、何年もの間、関数定義の後の空のthrow（）ステートメントと適切な拡張機能によってこの機能を備えてきました。最近のコンパイラーがこの知識を利用してより良いコードを生成することを保証します。

コンパイラのほぼすべての最適化では、関数の「フローグラフ」と呼ばれるものを使用して、正当なものについて推論します。フローグラフは、一般に関数の「ブロック」と呼ばれるもの（1つの入口と1つの出口を持つコードの領域）とブロック間のエッジで構成され、フローのジャンプ先を示します。Noexceptはフローグラフを変更します。

あなたは特定の例を求めました。このコードを考えてみましょう：

void foo(int x) {
    try {
        bar();
        x = 5;
        // Other stuff which doesn't modify x, but might throw
    } catch(...) {
        // Don't modify x
    }

    baz(x); // Or other statement using x
}

barラベルが付けられている場合、この関数のフローグラフは異なりますnoexcept（実行の終わりbarとcatchステートメントの間をジャンプする方法はありません）。とラベル付けされているnoexcept場合、コンパイラは、baz関数の実行中にxの値が5であることを確認します。x= 5ブロックは、batch（x）ブロックを「支配」すると言われていbar()ます。

次に、「一定の伝播」と呼ばれる処理を実行して、より効率的なコードを生成できます。ここで、bazがインライン化されている場合、xを使用するステートメントには定数も含まれる可能性があり、実行時評価であったものをコンパイル時評価などに変えることができます。

とにかく、短い答え：noexceptコンパイラーに、よりタイトなフローグラフを生成させ、フローグラフを使用して、あらゆる種類の一般的なコンパイラー最適化を推論します。コンパイラーにとって、この性質のユーザー注釈は素晴らしいです。コンパイラはこのことを理解しようとしますが、通常は不可能です（問題の関数は、コンパイラから見えない別のオブジェクトファイルにあるか、見えない関数を推移的に使用している可能性があります）。気付かれていないためにスローされる可能性があるいくつかの些細な例外のため、暗黙的にラベルを付けることはできませんnoexcept（たとえば、メモリを割り当てるとbad_allocがスローされる場合があります）。

noexcept一部の操作のパフォーマンスを劇的に向上させることができます。これは、コンパイラーがマシンコードを生成するレベルでは発生しませんが、最も効果的なアルゴリズムを選択することで発生しますstd::move_if_noexcept。他の人が述べたように、この選択はfunctionを使用して行います。たとえば、の増加std::vector（たとえば、を呼び出すときreserve）は、強力な例外安全性保証を提供する必要があります。T移動コンストラクタがスローしないことがわかっている場合は、すべての要素を移動できます。それ以外の場合は、すべてTのをコピーする必要があります。これについては、この投稿で詳しく説明しています。

使用後にパフォーマンスの向上を観察する以外は、いつ現実的に使用できnoexceptますか？特に、noexceptを追加した後、C ++コンパイラーがより良いマシンコードを生成できるコードの例を示します。

えっと？時間はないですか？決して。

noexcept以下のためにあるのコンパイラと同じように、パフォーマンスの最適化constコンパイラのパフォーマンス最適化のためです。つまり、ほとんどありません。

noexcept主に、「あなた」がコンパイル時に関数が例外をスローできるかどうかを検出できるようにするために使用されます。注意：ほとんどのコンパイラーは、実際に何かをスローしない限り、例外に対して特別なコードを発行しません。したがって、関数の使用方法についてのヒントnoexceptを与えるのと同じくらい、関数を最適化する方法についてのコンパイラのヒントを与えることではありません。

のようなテンプレートmove_if_noexceptは、移動コンストラクタが定義されているかどうかを検出し、定義されていない場合はタイプのの代わりにnoexceptを返します。安全に移動できるかどうかは、移動するという言い方です。const&&&

一般に、noexceptそうすることが実際に役立つと思われるときに使用する必要があります。一部のコードはis_nothrow_constructible、そのタイプに該当する場合、異なるパスを使用します。それを行うコードを使用している場合は、noexcept適切なコンストラクタを自由に使用してください。

つまり、移動コンストラクタや同様の構成要素に使用しますが、それに慣れる必要はありません。

でBjarneの言葉（C ++言語、第4版プログラミング、ページ366）：

終了が許容可能な応答である場合、キャッチされない例外は、それがterminate（）（§13.5.2.5）の呼び出しに変わるため、それを達成します。また、noexcept指定子（§13.5.1.1）はその欲求を明示的にすることができます。

成功するフォールトトレラントシステムはマルチレベルです。各レベルは、歪みすぎずにできるだけ多くのエラーに対処し、残りをより高いレベルに残します。例外はそのビューをサポートします。さらに、terminate()例外処理メカニズム自体が破損している場合、またはメカニズムが不完全に使用されている場合にエスケープを提供することにより、 このビューをサポートし、例外をキャッチしません。同様に、 noexcept回復しようとしても実行不可能と思われるエラーを簡単に回避できます。

double compute(double x) noexcept;     {
    string s = "Courtney and Anya";
    vector<double> tmp(10);
    // ...
}

ベクトルコンストラクターは、10のdoubleのメモリを取得できず、をスローする場合がありstd::bad_allocます。その場合、プログラムは終了します。std::terminate()（§30.4.1.3）を呼び出すことで無条件に終了します。関数の呼び出しからデストラクタを呼び出すことはありません。これは、実装定義との間のスコープからデストラクタかどうかである throwとnoexcept（例えば、計算に秒間（））が呼び出されます。プログラムはまさに終了しようとしているので、とにかくオブジェクトに依存するべきではありません。指定子を追加するnoexceptことで、コードがスローに対処するように作成されていないことを示します。

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

noexcept関数インターフェイスの一部であるため、注意が必要です。特に、ライブラリを作成している場合、クライアントコードはnoexceptプロパティに依存する可能性があります。既存のコードを壊す可能性があるため、後で変更するのは難しい場合があります。アプリケーションでのみ使用されるコードを実装する場合は、それほど心配する必要はありません。

スローできない関数がある場合は、それがとどまるのが好きか、それともnoexcept将来の実装を制限するだろうかと自問してください。たとえば、例外をスローすることにより（たとえば、単体テストの場合）不正な引数のエラーチェックを導入したり、例外の仕様を変更する可能性のある他のライブラリコードに依存したりする場合があります。その場合は、保守的にして省略した方が安全noexceptです。

一方、関数がスローしてはならないという確信があり、それが仕様の一部であることが正しい場合は、宣言する必要がありnoexceptます。ただし、noexcept実装が変更された場合、コンパイラは違反を検出できないことに注意してください。

2. noexceptの使用についてもっと注意する必要があるのはどの状況ですか？暗黙のnoexcept（false）を回避できるのはどの状況ですか？

最大の影響を与える可能性が高いため、集中すべき関数のクラスは4つあります。

1. 移動操作（割り当て演算子の移動とコンストラクターの移動）
2. スワップ操作
3. メモリ割り当て解除子（演算子の削除、演算子の削除[]）
4. デストラクタ（ただし、ユーザーnoexcept(true)が作成しない限り、これらは暗黙的に行われますnoexcept(false)）

これらの関数は一般的にnoexceptである必要があり、ライブラリ実装がnoexceptプロパティを利用できる可能性が最も高いです。たとえば、std::vector強力な例外保証を犠牲にすることなく、スローしない移動操作を使用できます。それ以外の場合は、要素のコピーにフォールバックする必要があります（C ++ 98の場合と同様）。

この種の最適化はアルゴリズムレベルで行われ、コンパイラーの最適化に依存しません。特に要素のコピーにコストがかかる場合は、大きな影響を与える可能性があります。

3. noexceptを使用した後、パフォーマンスの改善が見られるのはいつ現実的に期待できるでしょうか？特に、noexceptを追加した後、C ++コンパイラーがより良いマシンコードを生成できるコードの例を示します。

noexcept例外なしの仕様に対する利点、またはthrow()標準により、コンパイラーがスタックの巻き戻しに関してより自由にコンパイラーを使用できるようになります。このthrow()場合でも、コンパイラーはスタックを完全に巻き戻す必要があります（オブジェクト構造とまったく逆の順序で実行する必要があります）。

一方、このnoexcept場合、その必要はありません。スタックを巻き戻す必要はありません（ただし、コンパイラーは引き続き巻き戻すことができます）。この自由により、常にスタックを巻き戻すことができるというオーバーヘッドが低くなるため、コードをさらに最適化できます。

noexcept、スタックの巻き戻しとパフォーマンスに関する関連する質問では、スタックの巻き戻しが必要な場合のオーバーヘッドについて詳しく説明しています。

また、Scott Meyersの本「Effective Modern C ++」、「Item 14：Declare functions noexcept not exclude発信しないときは例外になる」も読んでください。

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

「私は[彼らは]決して投げないことを知っている」と言うとき、あなたは関数の実装を調べることによって、その関数が投げないことを知っています。そのアプローチは裏返しだと思います。

関数が例外をスローして関数の設計の一部となるかどうかを検討することをお勧めしますconst。引数リストと同じくらい重要で、メソッドがミューテーター（... ）であるかどうかです。「この関数は例外をスローしない」と宣言することは、実装上の制約です。省略しても、関数が例外をスローする可能性があります。つまり、関数の現在のバージョンと将来のすべてのバージョンで例外がスローされる可能性があります。これは、実装を困難にする制約です。しかし、一部のメソッドには、実際に役立つ制約が必要です。最も重要なのは、デストラクタから呼び出すことができるためですが、強力な例外保証を提供するメソッドでの「ロールバック」コードの実装にも使用できます。