2012-04-21 13 views
0

戦略私は、次の戦略を実行に思っている

クラスメソッドでstd::bad_alloc例外を取り扱うときは、メモリは可能な限り/意味のないことが試みられます例外を再発行する前にオブジェクトを解放することができ、いくつかのstdコンテナ(STD ::ベクトル<>)を持っているのであれば、我々のような何かを行う可能性があります:

catch(std::bad_alloc& e) { 
    //free any memory in my std::vector member, how? by doing this dirty hack 
    ~myVec(); 
    new (&myVec) std::vector<myType>(); 
    throw; //rethrow exception 
} 

質問:は、上記の「汚いハック」への安全な戦略であります例外が展開されている間に途中でメモリを解放しますか?長所と短所は何ですか?

+0

例外がスローされると、スタックは巻き戻され、その上にある任意のオブジェクトにはデストラクタが呼び出されます。私はあなたの質問を理解していません。なぜなら、RAIIはそのようなケースを扱うことになっているからです。 –

+0

@EtiennedeMartel、確かに、スタック内のオブジェクトをカバーします。ここでは、例外を処理するオブジェクトのメンバーについて説明します。エラーの意味は明らかに、このようなエラーがメンバーデータがもう必要でないことを意味する必要があります。 – lurscher

+1

@lurscher:なぜですか?クラスをクリーンアップする必要がある場合、クラスはスタック上にあるか、スマートポインタによって所有されます。そうでなければ、それはきれいにする必要はありません。クラスメソッドで例外をスローしても、メンバ変数をクリアする必要はありません。 – Puppy

答えて

3

これを行う必要はありません。ベクターは自動的に破壊されます。それがRAIIの仕組みです。他の状況でベクターをクリアしたい場合でも、clear()メソッドが付属しています。または、あなたはただvec = std::vector<T>();を行うことができます。

+0

クリアはメモリを解放しません、それはちょうど(バッファがまだ保持されている)サイズをリセットします。 2番目に、ここのベクトルはエラーのために無用になるオブジェクトのメンバーですが、スタックには存在しません(このオブジェクトはまだ割り当てが解除されていないか、まったくないでしょう) – lurscher

+0

@lurscherなぜそれは役に立たなくなるのですか? –

+2

@lurscher:それが役に立たなくなったら、それはスタックに/スマートポインタによって所有されるべきです。また、 'vector'には' shrink_to_fit() 'メソッドがあります。 – Puppy