SAFE_RELEASE/SAFE_DELETEを知らない人々は幸いである。
SAFE_RELEASE MUST DIE
こんな感じのマクロ：
wtf.cpp
// "安全な"COMポインタの解放処理マクロ
#define SAFE_RELEASE(p) if(p){ p->Release(); p=NULL; }
// "安全な"配列の解放処理マクロ
#define SAFE_DELETE(p) if(p){ delete[] p; p=NULL; }
あくまでC++言語のお話。C言語？知らない子ですね。
C言語でCOMを操作するとか、きがくるっとる。
慈悲は無い
SAFE_RELEASEやSAFE_DELETE、またはそれに類するマクロは、絶対に使わないこと。
見た目だけC++ templateに変えても(SafeRelease)、本質的には同じである。何も改善していない。絶対に使わないこと。
- 嬉々としてこのマクロを紹介するWebサイトを見かけたら、インターネット回線を切断してからWebブラウザを閉じ、該当サイトURLをブロックリストに追加しましょう。
- このマクロを使っているソースコードを見かけたら、エディタをそっと閉じてPCに向かって清めの塩をまき、ファイルをランダムデータで3回上書きしてから削除しましょう。
- このマクロを使っているプログラマを見かけたら、<censored>。
あと、MSDNはいい加減になんとかしてくれ。C++ templateに変えたからといって、決して許されるものでは無い。この誤訳に至っては、翻訳者は<censored>
スマートポインタ is awesome.
腐臭漂うC時代の負債マクロではなく、C++コンパイラやC++ライブラリが提供する「スマートポインタ(Smart Pointer)」を利用すること。絶対に。
COMオブジェクト参照カウントのリリース(IUnknown::Release())を行いたければ、以下のスマートポインタが利用できます。
- Active Template Library(ATL)の
CComPtrクラス,CComQIPtrクラス - Visual C++コンパイラ組込の
_com_ptr_tクラス - Boost.Smart Pointersライブラリの
intrusive_ptrクラス
動的確保された配列の解放(delete[])を行いたければ、以下のスマートポインタが利用できます。
- C++11標準ライブラリの
unique_ptrクラス - Boost.Smart Pointersライブラリの
scoped_arrayクラス,shared_arrayクラス
というより、動的配列を確保している大半のケースでは、単にC++標準コンテナ std::vectorクラス で間に合います。
- 有効要素数(
size())とバッファ容量(capacity())という属性情報を、セットで管理しています。動的配列ではプログラマの責任で別途管理が要りますが、面倒くさいしバグの温床にしかなりません。 -
std::vector<T>の全要素は、連続したメモリ領域に配置されると保証されています。例えばT=charとすれば汎用の「メモリバッファ」として使えます。 -
operator[]を介した要素アクセスコストまで気にするなら、走査直前にT* ptr = &vec[0];とでもしてptr[n]アクセスすればゼロオーバーヘッドになります。
感情論はこれくらいにして、理性的な解説も
SAFE_RELEASEマクロは、何がどう駄目なのかを列挙していきます。よくありそうなCOMクライアントコードを考えます。
legacy_macro.cpp
bool my_func()
{
ISomething *pObj = NULL;
IFoo *pFoo = NULL;
HRESULT hr;
// Somethingクラスを作成（ISomethingインターフェイス取得）
hr = CreateComObject(CLSID_Something, &pObj);
// (戻り値hrチェック省略)
// IFooインターフェイスを取得
hr = pObj->QueryInterface(IID_Foo, &pFoo);
if (FAILED(hr)) {
// 関数を抜ける前にはReleaseを忘れずに！
SAFE_RELEASE(pObj);
return false;
}
// 別関数another_funcを呼び出し
if (!another_func(pFoo)) {
// 関数を抜ける前にはReleaseを忘れずに！
SAFE_RELEASE(pFoo);
SAFE_RELEASE(pObj);
return false;
}
// まだまだ処理が続くよ...
// 関数を抜ける前にはReleaseを忘れずに！
SAFE_RELEASE(pFoo);
SAFE_RELEASE(pObj);
return true;
}
ATL提供のスマートポインタを使うと、次のように書けます：
modern_sp.cpp
#include <atlbase.h>
bool my_func()
{
// Somethingクラスを作成（ISomethingインターフェイス取得）
CComPtr<ISomething> pObj;
HRESULT hr = CreateComObject(CLSID_Something, &pObj);
// (戻り値hrチェック省略)
// IFooインターフェイスを取得
CComQIPtr<IFoo, &IID_Foo> pFoo = pObj;
// QueryInterfaceが呼び出される
if (!pFoo)
return false; // 自動的にReleaseされる
// 別関数another_funcを呼び出し
if (!another_func(pFoo)) {
return false; // 自動的にReleaseされる
}
// まだまだ処理が続くよ...
return true; // 自動的にReleaseされる
}
- マクロ版では結局プログラマの責任で、関数
returnの直前で解放処理を記述しなければなりません。コード構造が変更されたり、新しいインターフェイスが追加された時に、対応する解放処理の追記を忘れるとリソースリークします。スマートポインタ版では自動的に解放してくれます。 - マクロ版は例外安全ではありません。
another_func()や後続処理からC++例外が送出されて関数my_funcを抜ける場合、インターフェイスはReleaseされずにリソースリークします。スマートポインタ版では例外による関数脱出であっても安全です。 - マクロ版はスマートポインタ版に比べて、本質的な処理コードに対するBookkeepingコードの比率が高くなり、ソースコードの**"ノイズ"が増えます**。コードの可読性が低くなることで、保守性・拡張性にも悪影響を与えます。
- C++を使っているのですから、変数宣言を関数先頭で行うのではなく。代入するタイミングで宣言すべきです。変数スコープを必要最小限に限定することは、ソースコードの可読性／保守性／拡張性を改善し向上させます。（マクロ版でも実施可能ですが、レガシーコードでは大抵C言語スタイル、つまり関数先頭で一括宣言するケースが多いようです。）