問題タブ [noexcept]

最近、私のコードではnoexcept(false)、主にコードを読む人のために、例外をスローすることがわかっている関数について明示的に書いています。ただし、これがコードの動作やコンパイラの解釈方法に影響するかどうかは疑問です。違いはありますか？

注：デストラクタは暗黙的に noexcept であり、それnoexcept(false)を変更するには指定する必要があることを認識しています。他の関数について疑問に思っています。

noexcept修飾子をラムダ式に適用できますか? もしそうなら、どのように？

noexcept関数の引数に制約を付けることができますか? たとえば、次のコードのように、コールバック関数がnoexcept?である必要があることを意味します。

これは次のコードでほぼ達成できますが、上記の代替のようなものを使用する方法があるかどうか疑問に思っています。

もちろん、ここでの問題は、コールバックが次の場合に発生するf_async可能性があることです-常により強力なステートメントを作成したい、つまり、コールバックを使用する場合にのみ呼び出し可能です。noexcept(false)noexcept(false)f_async noexceptnoexcept

次のプログラムを検討してください。

ではg++-4.8.1、静的アサーション障害がある、Explicitと思われるよう~Explicit()ですnoexcept。これは私の期待と一致しません。§12.4.3 によると:

例外仕様を持たないデストラクタの宣言は、暗黙の宣言と同じ例外仕様を持つと暗黙的に見なされます。

ここで面白いのは、 のチェックがImplicit、§15.4.14 (§12.4.7 まで) の私の解釈に従って動作しているように見えることです。

... fが ... デストラクタの場合 ... 暗黙の例外仕様が指定する ... f がnoexcept(true)直接呼び出すすべての関数が例外を許可しない場合、 f は例外仕様を持ちます。

g++-4.7が欠けis_nothrow_destructableているため、4.7 での動作を確認するために独自に作成しました。プログラムは完全に正常にコンパイルされているようです。私はこれが完全に間違っており、私の混乱の原因となる権利を留保します:

TL;DR:g++-4.8.1例外指定のない明示的に宣言されたデストラクタが常に であると考えるのはなぜnoexcept(true)ですか?

更新:これについてバグを開きました: 57645。この問題を回避する必要がある場合は、デストラクタに例外指定を追加できます (Thrower例の has のように)。

デフォルトの配置new演算子は、18.6 [support.dynamic] ¶1 でスローしない例外仕様で宣言されています。

ただし、5.3.4 [expr.new] ¶15によれreturn ptr;ばnoexcept、これは、オブジェクトのコンストラクターを呼び出す前に、コンパイラーが null を返さないことを確認する必要があることを意味します。

-15-
[注:例外をスローしない例外仕様 (15.4) で割り当て関数が宣言されていない限り、例外をスローしてストレージの割り当てに失敗したことを示しstd::bad_allocます (第 15 節、18.6.2.1)。それ以外の場合は、null 以外のポインターを返します。割り当て関数が例外をスローしない仕様で宣言されている場合、記憶域の割り当てに失敗したことを示すために null を返し、それ以外の場合は null 以外のポインターを返します。割り当て関数が null を返す場合、初期化は行われず、割り当て解除関数は呼び出されず、new-expression の値は null になります。

（一般的にではなく、具体的には Placementnewの場合）この null チェックは、小さいながらも残念ながらパフォーマンスに影響を与えるようです。

newコンパイラのコード生成を改善するために、パフォーマンスが非常に重要なコード パスで配置が使用されているコードをデバッグしており、アセンブリで null のチェックが観察されました。例外をスローする仕様で宣言されたクラス固有の配置newオーバーロードを提供することにより (スローできない可能性がありますが)、条件分岐が削除され、コンパイラは周囲のインライン関数に対してより小さなコードを生成することもできました。配置new関数がスローできなくても、スローできると言う結果は、測定可能なほど優れたコードでした。

そのため、配置の場合にnullチェックが本当に必要かどうか疑問に思っていましたnew。null を返すことができる唯一の方法は、null を渡す場合です。次のように書くことは可能であり、明らかに合法ですが、

なぜそれが役立つのかわかりません。プログラマーが配置を使用する前に null を明示的にチェックする必要がある場合は、より良いと思いますnew。

newnull ポインターのケースを正しく処理するために配置が必要だった人はいますか? (つまりptr、有効なメモリ位置である明示的なチェックを追加しません。)

newnull ポインターをデフォルトの配置関数に渡すことを禁止することが合理的かどうか、もしそうでない場合は、コンパイラーに値が null ではないことを伝えようとする以外に、不要な分岐を回避するためのより良い方法があるかどうか疑問に思っています。

または：

注意: この質問は意図的にマイクロ最適化にタグ付けされています。パフォーマンスを「改善」するために、すべてのタイプの配置をオーバーロードすることをお勧めしません。newこの影響は、非常に特定のパフォーマンスが重要なケースで、プロファイリングと測定に基づいて確認されました。

更新: DR 1748により、null ポインターを新しい配置で使用する動作が未定義になるため、コンパイラーはチェックを行う必要がなくなりました。

cplusplus.comのドキュメントに指定子がstd::chrono::steady_clock::nowあることに気付きました。ただし、最新の C++11 ドラフトでは、これに対する規定は見つかりませんでした (残念ながら、標準のコピーを持っていません)。noexcept

cplusplus.com ドキュメントの間違いですか、それとも指定子std::chrono::steady_clock::nowが必要noexceptですか?

通常は絶対に失敗しない関数があるとします。たとえば、次のようになります。

原則として、これは の候補になりnoexceptます。ただし、実装には動的メモリ管理が含まれる可能性が最も高いため、演算子でメモリを割り当てるときに常にstd::bad_allocnewをスローする可能性があります。

関数に noexcept のアノテーションを付けることをお勧めしますか?

実際的な観点からは、メモリ不足の状況を合理的な方法で処理することは非常に困難です。ほとんどのプログラムは、十分なメモリが利用可能であると想定しています。関数が をスローstd::terminateした場合に発生するように、 を呼び出すことは、その場合は合理的であるように思われます。noexceptstd::bad_alloc

私にとってnoexceptは、ある種のドキュメントです。ユーザー (またはオプティマイザー) が、この関数が決してスローしないと安全に想定できるという約束です。メモリ不足の状況を気にしないアプリケーションをプログラミングしている場合でも、それは有効な仮定です。

最も安全な推奨事項は、例外がスローされる可能性があるnoexcept場合は使用しないことだと思います。std::bad_alloc一方で、noexceptメモリ不足の状況を気にしない (つまり、std::terminateOK の場合) と仮定すると、とにかく使用する利点があるかどうか疑問に思います。