10

パフォーマンスが重要なダイナミックリンクライブラリ（DLL）に取り組んでいますが、これも比較的小さいバイナリサイズである必要があります。明示的に例外をスローしないので、例外サポートを完全に無効にしたいと思います。ただし、例外が1つあります（意図しないしゃれ）。メモリが不足すると（OOM）、アプリケーションにエラーコードを報告して、適切に処理できるようにする必要があります。コードベースが大きすぎるため、すべての割り当てを個別にチェックしてエラーを伝播できず、触れてはいけない外部コードが含まれています。そこで、DLLのエクスポートされた関数でOOM例外をキャッチしたいと思います。

簡単なテストでは、Visual C ++2010でC++例外を無効にした場合（つまり、/ EHa、/ EHsc、または/ EHsフラグがない場合）、割り当てが多すぎると、catch（std :: bad_alloc＆）ブロックにジャンプすることが示されています。

したがって、希望どおりに機能するようです。ただし、次のレベル1の警告が表示されます：「C4530：C ++例外ハンドラーが使用されていますが、アンワインドセマンティクスが有効になっていません。/EHscを指定してください」。MSDNによると、「スローを実行する関数とスローをキャッチする関数の間のフレームに自動ストレージがあるオブジェクトは破棄されません」。

正確に私はここで何を失うでしょうか？ライブラリを介して作成されたものを削除でき、アプリケーションを最初からやり直すことができる限り、未定義の状態のままにしておくことは問題ありません（必要に応じて）。回復できないメモリリークの大きなリスクはありますか？

DLLは別のメモリプールを使用しますか？もしそうなら、アプリケーションにDLLをアンロードせずにパージできますか？アプリケーションが再初期化を実行するまで、ライブラリにそれ以上の（エクスポートされた）関数呼び出しを簡単に無視させることができます。

アドバイスありがとうございます。

4

1 に答える 1

1

いくつかの予備知識：

例外処理を有効にせずに例外をスローすることが未定義の動作であるかどうかはわかりませんが、スタック上のオブジェクトからスタックの巻き戻し/デストラクタ呼び出しを取得することはありません。

ミューテックス、ファイル、メモリなどにRAIIを使用してC ++スタイルのコードを記述している場合、これは非常に悪いことです。

次に進み、コードが本質的にCスタイルのコードであると仮定します。

1）Cランタイムライブラリに静的にリンクしている場合、DLLはメインアプリケーションとヒープを共有しません。DLLをアンロードすると、リークされたメモリが解放されますが、他のリソースに注意する必要があります。

2）Cランタイム（非常に一般的）に動的にリンクしている場合は、ヒープを共有しています。DLLから割り当てられたメモリを手動で解放する方法が必要になります。

DLLの境界の問題に悩まされすぎたので、例外を有効にしておくという観点から、何にお金を払っているのかを確認するための簡単なベンチマークをお勧めします。プラットフォームとコンパイラによっては、スローされない例外によるパフォーマンスへの影響はごくわずかです。

于 2013-02-07T00:48:02.003 に答える