2010-12-20 17 views
2

サードパーティライブラリのメモリ管理に問題があります。私はソースを持っていますが、それは非常に複雑です(COMのもの)、マクロとそれらの迷惑なMicrosoft注釈などでいっぱいで、私は起動する必要のない別のライブラリとやりとりします。今や、いくつかのクイックデバッグランタイムは、メモリが漏れていることを示しています。私はunique_ptrのような自己解放ポインタを広範に使用し、私が作成したすべてをリリースしたことを知っています。ソースを取り除く(そして理解する)ことが私の唯一の選択肢ですか?外部メモリ管理とCOM

また、演算子newでCOMオブジェクトを割り当てることは安全ですか、またはCOMヒープに移動する必要がありますか?

答えて

2

COMは、独自のCOMオブジェクトをどのように割り当てるかについて非常に無関係です。それらはクラスファクトリによって作成され、IUnknown :: AddRefメソッドとReleaseメソッドは参照カウントを保持します。クラスファクトリでoperator newを使用し、リリースでdelete thisを使用しても問題ありません。

インターフェイスメソッドで返すポインタについては注意が必要です。 BSTRやSAFEARRAYなどの一般的なオートメーションオブジェクトは、クライアントコードがそれらを解放できるように、実際にはCOMヒープに割り当てられる必要があります。 APIを使いこなすのはかなり難しいです。

クライアントコードがリークの原因となる可能性があります。リファレンスカウントがかなり標準的なCOMバグです。 AddRef/Release実装へのアクセス権を持っている場合、通常は簡単に診断できます。これをVistaやWin7でデバッグすることも強く推奨されています。間違ったヒープからメモリを解放しようとする試みを静かに無視しないヒープマネージャーがはるかに優れています。

もしあなたがかなり漏れているCOMサーバーであれば、<crtdbg.h>ヘッダーとユニットテストの問題を分離してインターフェイスメソッドを実行してください。

+0

+1また、BSTRは 'SysAllocString()'ファミリ関数を使って専用ヒープに割り当てられます。 – sharptooth