問題タブ [exception-specification]

これに関する2つの質問:

• 指定子を強制的g++に無視する方法はありthrowますか?
  (たとえば、私が覚えているように、Visual Studio は とは異なり、スロー指定子を無視しますthrow())

• スロー指定子が正しいかどうかを強制的g++にチェックすることは可能ですか?つまり、スロー指定子を持つ関数が関数を呼び出すかどうかをチェックすることです(これはワンパスコンパイラで実行できます)。指定子とthrow、指定子に違反する例外の実行を監視しますか? (注:大量の警告が発生する可能性があるため、スロー指定子なしで関数を監視しないでください)

編集: 2 番目の質問にいくつかの例を追加します。

次があるとします。

例外を試行/キャッチするか、if ステートメントを使用してさまざまな結果を処理する方がよいでしょうか?

便宜上ファイルをコピーし、ifs を使用してファイルが存在しないイベントを処理し、各メソッドのスローを宣言する短いプログラムを Java で作成していますが、try/catch は使用しません。

これらの if と関連するセクションを try/catch に置き換えるべきですか、それともユーザーの小さなコミュニティと共有するための「許容できる」プログラミングですか?

std::exceptionそのコンストラクタがである必要がありますthrow()。それでも、引数としてstd::runtime_erroraを受け入れます。これは、どこかに格納されていることを示します。したがって、割り当てまたはコピーの構築はどこかで行われている必要があります。そして、のために、それは操作ではありません。std::stringstd::stringstd::stringnothrow

では、どのようにruntime_error::runtime_error会うのthrow()でしょうか？

（コンテキストとして、例外タイプを実装していてstd::string、呼び出しサイトから数秒を保存したいのですが、正しく実行したいのですが...）

私が持っているとします：

デフォルトのデストラクタの例外仕様は何ですか? デフォルトのデストラクタは次と同等です:

C++11 標準のセクション 15.4 は、デストラクタの暗黙的な定義によって直接呼び出される関数の例外仕様に依存すると述べています。この場合、メンバーも基本クラスもないため、暗黙のデストラクタによって直接呼び出される関数はありません。これは標準のあいまいさ (または省略) ですか?

もちろん、暗黙的に throw() がある場合は、すべてのサブクラスが throw() でデストラクタを宣言する必要があるため、これは重要です。デストラクタで例外をスローするのは悪い考えだとは言わないでください。例外仕様がまったく使用されていない多くのレガシー コードを扱っています。

参考までに、私が試したとき：

GCC 4.4 でエラー (例外仕様の不一致) が発生しましたが (ただし、正しいコマンド ライン スイッチがなかった可能性があることは認めます)、「11」コンパイラを使用する XCode 4.3 では発生しませんでした。

私はVC2010を使用しており、次のコードを書いて「set_unexpected」機能をテストしています。

ただし、「my_unexpected_handler」は呼び出されません (文字列はコンソールに出力されません。my_unexpected_handler にブレークポイントを設定しようとしましたが、実行されませんでした)。

コードの何が問題になっていますか?

ありがとう

申し訳ありませんが、予期しない例外を誤解していました。ただし、コードを次のように変更しても

それはまだ動作しませんか？つまり、「my_unexpected_handler」は呼び出されません。

関数が有効な例外リストにない例外をスローした場合の標準的な動作は何ですか? たとえば、このコードを実行すると:

GCC と Visual Studio C++ コンパイラでは動作が異なります。

• VS 2010 では、予期しない例外が一般的な例外ハンドラーでキャッチされます。
• GCCunexpected()では、例外をキャッチする代わりにハンドラー関数が呼び出されます。

この違いはなぜですか？unexpected()MS C++ コンパイラがcallbackを呼び出さないのはなぜですか?

最初の免責事項: これは「言語戦争」を引き起こすためのものではありません。私は自分のレポートのためにこれ (主題に関する明確化) が本当に必要であり、有効で確固たる議論をしたいだけです.
わかりましたので、ここで質問があります
。C++ では、良いことよりも悪いことを引き起こすと考えられていたため、C++ 11 標準から例外仕様が削除されました。
一方、Java では、例外仕様は何か良いものと見なされています。
これらの 2 つの概念 (例外仕様を持つ目的) は、これら 2 つの言語で異なりますか? そのため、これらの 2 つのコミュニティで異なるように見られているのですか、またはそれらの概念は類似/同一ですか?
どちらですか？例外指定は良いことですか、それとも悪いことですか? または、Java では良いので (ここでいくつかの理由を見たいと思います)、C++ で悪いのは (理由はここにある) からです。
建設的な助けをしてくれた人に感謝します。

関数シグニチャでの使用（ではない）について多くの議論を読みましたがthrow(X)、ISO C ++で指定されている（そして現在のコンパイラで実装されている）方法はかなり役に立たないと思います。しかし、なぜコンパイラはコンパイル時に例外を強制することができないのでしょうか。

シグニチャに含まれる関数/メソッド定義を記述した場合throw(A,B,C)、コンパイラは、指定された関数の実装が例外的に正しいかどうかを判断するのに多くの問題を抱えることはないはずです。つまり、関数本体には

• throw以外はありませんthrow A; throw B; throw C;;
• throw (A,B,C);よりも制限の少ないthrow-signaturesを持つ関数/メソッド呼び出しはありません。

、少なくともtry{}catch()他の投げられたタイプを捕まえることの外で。これらの要件が満たされていない場合にコンパイラがエラーを発生させる場合、すべての関数は「安全」である必要があり、のようなランタイム関数unexpected()は必要ありません。これはすべて、コンパイル時に保証されます。

これには、すべての非C ++レルムコードがthrow()デフォルトで指定されている（デフォルトextern "C"で想定されている必要があります）か、例外の相互運用性がある場合は、適切なヘッダー（少なくともC ++の場合）も指定する必要がありthrowます。そうしないと、異なるコンパイル単位で異なる関数/メソッドの戻り型を持つヘッダーを使用する場合と比較できます。警告やエラーは発生しませんが、明らかに間違っています。スローされた例外は署名の一部であるため、それらも一致する必要があります。

このような制約を適用すると、次の3つの効果があります。

• ランタイムチェックに必要な暗黙のブロックをすべて削除するためtry{}catch、例外処理のパフォーマンスが向上します。
• 「例外がライブラリを大きくしすぎているので、それらをオフにします」という議論。追加のコードのほとんどは、すべての関数呼び出しでの不要な暗黙のthrow / catch命令にあるため、消えてしまいます。コードが適切に指定されていればthrow、そのほとんどはコンパイラーによって追加されません。
• 誰も例外を好まないようだったので、それはプログラミングの世界のほとんどを激怒させるでしょう。さて、これらは実際に使えるので、使い方を学ぶ必要があります。

古いコードに互換性コンパイラフラグを使用した場合、何も壊れませんが、新しい例外コードの方が高速であるため、それを使用して新しいコードを記述しないことには十分な動機があります。

私の質問を要約すると、なぜそのような強制はISO C ++で必要とされないのですか？そうでない強い理由はありますか？例外は別の関数の戻り値にすぎないといつも思っていましたが、自動的に制御されるため、次のような関数を記述しないようにすることができます。

さらに、変数の追加の自動破棄とスタック上の複数の関数を介した伝播により、次のようなコードは必要ありません。

;そして、正しい型だけに関数を要求returnできるのなら、なぜそれを要求できないのですthrowか？

例外指定子の方が優れているのはなぜですか？最初から説明したように作られていないのはなぜですか？

PS例外とテンプレートにいくつかの問題があるかもしれないことを私は知っています-この質問への答えに応じて、おそらく私はそれについて別の質問をします-今のところテンプレートを忘れましょう。

編集（@NicolBolasへの応答）：

コンパイラは、Yでは実行できなかった例外クラスXでどのような最適化を実行できますか？

比較：

と：

ここに、コンパイラがアセンブリレベルを生成しない疑似コードをいくつか含めました。ご覧のとおり、発生する可能性のある例外を知ることで、コードの量を減らすことができます。ここで破棄する追加の変数があれば、追加のコードはさらに長くなります。

私は Howard Hinnant のスタック アロケータを使用してきましたが、これは魅力的に機能しますが、実装の詳細が少しわかりません。

1. グローバル演算子newandがdelete使用されるのはなぜですか? allocate()anddeallocate()メンバー関数は、それぞれ and を使用し::operator newます::operator delete。同様に、メンバー関数construct()はグローバル配置 new を使用します。ユーザー定義のグローバルまたはクラス固有のオーバーロードを許可しないのはなぜですか?
2. アライメントが ではなく、ハードコードされた 16 バイトに設定されているのはなぜstd::alignment_of<T>ですか?
3. コンストラクタと例外仕様max_sizeがあるのはなぜですか? throw()これはお勧めできませんか (たとえば、より効果的な C++ 項目 14 を参照)。アロケーターで例外が発生したときに終了して中止する必要は本当にありますか? これは新しい C++11noexceptキーワードで変わりますか?
4. メンバー関数は、construct()(呼び出されているコンストラクターへの) 完全な転送の理想的な候補です。これは C++11 準拠のアロケータを記述する方法ですか?
5. 現在のコードを C++11 に準拠させるには、他にどのような変更が必要ですか?

非スロー機能について2つの質問があります。

1. なぜ関数を非スローにするのですか？

2. 関数を非スローにする方法は？関数内のコードが実際に発生する可能性がある場合throwでも、スローしないようにする必要がありますか？

次に例を示します。

のコードswapがまったくスローされない場合でも、追加する必要がありますthrow()か？なんで？