19

アンマネージ C++、Visual Studio 2008 以降で新しいプロジェクトを作成する場合、どの例外処理モデルを使用しますか?

/EHa オプションを使用するとコードの効率が低下し、SEH 例外もキャッチされることは理解していますよね?

そのため、私はそのオプションを避け、通常は /EHsc を使用して、catch(...) ハンドラーで実際にスローされた C++ 例外のみをキャッチし、アクセス違反やその他の構造化された例外をキャッチしていません。コードにアクセス違反がある場合、catch(...) {} でマスクされたくありません。

私は、catch(...) {} が何もしないことを望んでいて、アクセス違反があった場合にそれを実行することさえ望んでいる他の人とコーディングしています。これは、私には本当に悪い考えのように思えます。悪いコーディングによるバグがある場合、耳に指を突っ込んで「ラララララ！」と大声で言いたくないでしょう。プログラムがクラッシュする必要がないようにするには？実際、コーディング エラーが原因でコードが悪い状態になっている場合、本当にコードを続行しますか?

したがって、私の一般的な考えは、/EHa はより大きな/より遅いコードを作成し、致命的なバグが存在する場合に未定義の状態で実行し続けるコードをプログラマが書くことを回避できるようにするというものです。

ところで、私が話しているのはアプリケーションとサービス コードであり、その大部分は私たちが書いているものです。低レベルのデバイスドライバーなどではありません。

あなたの考えを考慮してください。

4

2 に答える 2

22

/EHa は 2 つのことを行います。何よりもまず、コード アナライザーが C++ 例外をスローする可能性のあるコードを認識できない場合に、ローカル クラス変数のデストラクターを自動的に呼び出す例外フィルターを省略する最適化を抑制します。これにより、C++ 例外だけでなく、あらゆる種類の例外に対してスタックの巻き戻しが安全になります。これらの例外フィルターのオーバーヘッドは、x86 では時間、x86 と x64 の両方ではスペースです。

はい、catch(...) の動作が変更され、C++ だけでなく、SEH 例外もフィルター処理されるようになりました。本当に厄介なもの、非同期ハードウェア例外をすべてキャッチするので、これは確かにギャンブルです。個人的には、すべての C++ 例外をキャッチすることも非常に擁護できるとは思いませんが、プログラムの状態がどの程度変更され、なぜ失敗したのかについては漠然とした考えしかありません。

__try/__except現実的には、独自の例外フィルターを作成し、悪いフィルターをキャッチしないようにするには、using に切り替える必要があります。C++ 例外の例外コードは 0xe04d5343 ("MSC") です。_set_se_translator() を使用することも別の方法です。

于 2010-12-11T07:25:30.147 に答える
6

/EHa は .NET interop で安全なので使用しますが、/EHsc は安全ではない可能性があります。たとえば、ネイティブ (C++) 例外が CLR コンポーネントに伝播するときにデストラクタが呼び出されないを参照してください。

ただし、コードの特定のビットについて追加のパフォーマンスが本当に重要であり、.NET (またはその他のもの) との互換性が必要ない場合は、確かに、/EHsc は問題ないように思えます。

/EHsc も /EHa もほとんどのメモリ エラーをキャッチしないため、これらを使用してアクセス違反をキャッチすることは絶望的なケースです。

于 2010-12-10T23:01:27.930 に答える