問題タブ [noexcept]

私が知る限り、SO コミュニティは、関数を宣言することで、他のnoexcept方法では不可能な意味のあるコンパイラーの最適化が可能になるかどうかについて意見が分かれています。(特にコンパイラの最適化について話しているのであって、に基づくライブラリ実装の最適化ではありませんmove_if_noexcept。) この質問の目的のために、noexcept意味のあるコード生成の最適化が可能になると仮定しましょう。inlineその前提で、関数を宣言することは理にかなっていますnoexceptか? そのような関数が実際にインライン化されていると仮定すると、呼び出しサイトで関数tryから生じるコードの周りにブロックに相当するものをコンパイラが生成する必要があるように思われます。それなしinlineterminatenoexcept、そのtryブロックは不要のようです。

noexcept私の当初の関心は、Lambda 関数が暗黙的に であることを考えると、宣言する意味があるかどうかということでしたが、Lambdaだけでなく、どの関数でinlineも同じ問題が発生することに気付きました。inline

より効果的な C++で、Scott Meyers は言います

C++ は、例外としてスローされたオブジェクトがコピーされることを指定します。

次に、コピー コンストラクターが順番に例外をスローすると、std::terminateが呼び出されるので、これがすべての例外のコピー コンストラクターを宣言する正当な理由になるnoexceptと思います (また、ヒープからメモリを割り当てるオブジェクトをスローしないように、のようにstd::string）。

std::bad_allocしかし、GCC 4.7.1 に同梱されている標準ライブラリの実装では、とのコピー コンストラクタが定義されていないことに驚きましたstd::exception。彼らはそれらを定義すべきではありませんnoexceptか？

C++11 およびドラフト C++14 では、逆参照演算子 (operator*およびoperator->)shared_ptrは bothnoexceptです。しかしunique_ptr、operator->は ですがnoexcept、そうでoperator*はありません。operator*ではないのはなぜですかunique_ptr noexcept(または、なぜ であるoperator*のですshared_ptr noexceptか)?

このコードは、clang(3.4) ではコンパイルできますが、gcc (4.7.1) ではコンパイルできません。誰が私が間違っているのか教えてもらえますか?

編集

gcc エラー メッセージは次のとおりです。

アトミックな time_point を保持しようとしてこの問題が発生しました。参照してください (デフォルトのコンストラクターが利用可能な場合、アトミックには noexcept デフォルトのコンストラクターが必要です): http://cplusplus.github.io/LWG/lwg-active.html#2165

単純な問題は、std::atomic または同様のものが現在の std の下でコンパイルに失敗することです。

std::chrono::clock_type::now() を考慮すると、 noexcept です。タイムポイント自体がそうではないのは奇妙に思えます。

N3797の時点で、C++ 標準ではswap、特に指定されていない限り、コンテナーの関数が例外をスローしないことを要求しています[container.requirements.general]( 23.2.1§10 )。

• swapスローしないように指定されているメンバー関数が宣言されていないのはなぜnoexceptですか?

_{同じ質問が特殊な非メンバーswapオーバーロードにも当てはまります。}