std::vector<VARIANT>型のメモリ開放

Question

###環境
Windows10 64bit
Visual Studio 2019
C++17
###知りたいこと
std::vecotr<VARIANT>型の配列があり、
配列内にvt=VT_BSTRである要素が存在するものとします。

この場合、std::vector<VARIANT>型の配列が確保していたメモリは、
スコープを抜けたら全て解放される認識で相違ないでしょうか。
それとも各要素にVariantClear()が必要でしょうか。

Answer 1

どちらかというとvectorに直接VARIANTを投げ込むのではなく、一旦RAIIなラッパークラスを作って、それをvectorに格納するべきでしょうね。そうすれば開放はよしなにしてくれる。

Comments

[subka]

回答ありがとうございます。
一番間違いない手段ですね。

ただ、メモリが解放されるのであればVariantClear()の処理は不要と考えておりますので、
今回はメモリが解放されることが確認できましたので直接投げ込んでしまおうと思います。

[SaitoAtsushi]

CComVariant などのラッパーが用意されているので、なるべくならそういったフレームワークが用意しているものを使うと他の機能と組み合わせやすかったりするでしょうね。

[Bull]

解決したようなので余談ですが、VARIANT のラッパークラスとして variant_t があります。
variant_t にはデストラクタが定義されていて、VariantClear() を呼び出しています。
さらに余談ですが、BSTR にも ラッパークラスの bstr_t があって、いろいろと便利なメンバー関数が定義されています。

[subka]

SaitoAtsushiさん、Bullさん、コメントありがとうございます。
Variant型はいずれかのラッパークラスを利用する方向で検討します。

BSTRのラッパー bstr_t と CComBSTR は利用を検討したのですが、
条件如何でメモリリークが発生するという懸念があり、
現状メモリリークの発生条件を明確に出来ていないので、自分で明示的に開放しています。

Answer 2

この場合、std::vector<VARIANT>型の配列が確保していたメモリは、
スコープを抜けたら全て解放される認識で相違ないでしょうか。

相違ありません。が、開放の前に何らかの後始末(たとえばVariantClear)が必要だったとしても
それを自動的に呼んではくれません。必要なら各要素にたいして明示的に後始末してください。

※ VARIANT が class であるなら、そのデストラクタで後始末してあれば
開放に先立ってデストラクトされるので無問題

Comments

[subka]

回答ありがとうございます。
認識には相違ないのですね。

vectorのデストラクタでVariantClear()が呼ばれないのは認識しておりす。
VariantClear()はvt=VT_EMPTYとSysFreeString()しかしていない様なので、
該当のメモリが解放されるのであれば後始末も不要と考えています。

[episteme]

"該当のメモリ"はVARIANTが占める領域「だけ」です。
たとえばVARIANT内にポインタがあり、それがあらかじめ確保された領域を指していたなら、
その領域は未開放となります。それでよければ。

[subka]

度々ありがとうございます。
今回はVARIANT内にポインタがないことが確約されている為、その点は問題ないです。

[episteme]

え? VT_BSTRって文字列ですよね。であるならVariantClear()せにゃならんのでは?

[subka]

すみません。勘違いしてました。
VariantClear()必要ですね。