2012-02-14 61 views
0

ベクトルのpush_backメソッドが呼び出されると、C++例外がスローされます。デバッガでは、xmemoryファイルの中に例外がスローされているように見えます。xメモリコードのC++例外が深くスローされる

// TEMPLATE FUNCTION _Destroy 
template<class _Ty> inline 
void _Destroy(_Ty _FARQ *_Ptr) 
{ // destroy object at _Ptr 
    _DESTRUCTOR(_Ty, _Ptr); 
} 

私がbad_allocのcatchハンドラでのtry-catchのコードをラップしようとしたので、bad_alloc例外ではありません。私は例外が起こる見るのはここです。コードはそのステップをそこで実行しました。常に(...)catchハンドラに入ります。 bad_alloc例外ではない場合、何が起こっている可能性がありますか?

+0

[3のルール](http://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming))に従っていますか? –

+1

オブジェクトの種類は何ですか?例外の種類は何ですか?私はあなたがここに示した関数は例外ではないことを推測します。デストラクタはほとんど例外をスローしません。 (Like:never) –

答えて

0

xmemoryヘッダーは、標準C++ライブラリ(例えばMSVC++で出荷されている)のDinkumware実装の実装の詳細です。実際のエラーは、この特定の機能に関連する可能性は非常に低いです。私はマクロ_DESTRUCTORが(-Eまたは/ Eコンパイラフラグを使って調べることができる)どのマクロに展開するのか分かりませんが、必然的に関連する型のデストラクタを呼び出します。私はこのマクロがスローする例外を見たり、デストラクタのどれかが例外をスローするかどうかをチェックしたりします。また、例外の可能性をよりよく把握するには、std::exception const&をキャッチしてください。スローされるすべての例外は、この型から派生することをお勧めします。これは、標準のC++ライブラリによってスローされたすべての例外に当てはまります。しかし、システムによっては、定義されていない振る舞いの結果として例外がスローされることがあります。std::exceptionから派生しない場合があります(コードがメモリを複数回解放するなど)。 std::exceptionから派生するこのアドバイスに従わないと、残念なことに、デバッグの例外がかなり難しくなります。 std::exception const&が見つかったらwhat()のメンバーであるstd::exceptionを使って何が行われているのか調べることができます。

関連する問題