free a COleVariant object

hi
How to free a COleVariant object;
COleVariant var(string); // create a object and assign a string
var.Clear() doesn't free the string.

Eberhard
Thu Apr 21 04:17:21 CDT 2005

Tyagi schrieb/wrote:

> How to free a COleVariant object;
> COleVariant var(string); // create a object and assign a string
> var.Clear() doesn't free the string.

Normally it does, in the sense that is described in MSDN under
::VariantClear. Please describe in detail

- what you are doing (in particular, of which type "string" is and how
it is initialized)
- what you are expecting
- what you are observing

Tyagi
Thu Apr 21 17:23:55 CDT 2005

CString string=_T("this string will attach with COlevariant object");
COleVariant var(string);

Just write above 2 lines of code. Check the memory of string variable. Then
check the memory of var.bstrVal.
Both contains different memory locations. where contents of string are
written.
Now write following following statement
var.Clear();
Now check the memory location of var.bstrVal. string's contents are still
written at its location. which is wastage of memory. I think memory should
be free of var.bstrVal now. because var has been cleared.
"Eberhard Schefold" <eberhard.schefold@de.bosch.com> wrote in message
news:d47r31$3k9$1@ns2.fe.internet.bosch.com...
> Tyagi schrieb/wrote:
>
> > How to free a COleVariant object;
> > COleVariant var(string); // create a object and assign a string
> > var.Clear() doesn't free the string.
>
> Normally it does, in the sense that is described in MSDN under
> ::VariantClear. Please describe in detail
>
> - what you are doing (in particular, of which type "string" is and how
> it is initialized)
> - what you are expecting
> - what you are observing

Eberhard
Thu Apr 21 06:00:02 CDT 2005

Tyagi schrieb/wrote:

> Now check the memory location of var.bstrVal. string's contents are
> still written at its location. which is wastage of memory. I think
> memory should be free of var.bstrVal now. because var has been
> cleared.

The typical strategy for freeing a particular piece of heap space is simply
to mark it as free in the internal heap administration structures. There is
no need to explicitly overwrite the heap /data/. So, your observation
gives no indication that the memory has not been freed.

Oleg
Thu Apr 21 06:21:20 CDT 2005


> > Now check the memory location of var.bstrVal. string's contents are
> > still written at its location. which is wastage of memory. I think
> > memory should be free of var.bstrVal now. because var has been
> > cleared.
>
> The typical strategy for freeing a particular piece of heap space is simply
> to mark it as free in the internal heap administration structures. There is
> no need to explicitly overwrite the heap /data/. So, your observation
> gives no indication that the memory has not been freed.

When the application is running under debugger, or linked with Debug CRT,
the freed heap block is usually overwritten with a pattern that helps
to detect reuse-after-delete situations (unless special actions are taken
to disable such behavior).

In case of BSTR allocation, there is an additional cache involved, so it is possible
that the heap block is not freed when BSTR is released:
http://support.microsoft.com/?id=139071

Regards,
Oleg
[VC++ MVP]

Eberhard
Thu Apr 21 07:17:04 CDT 2005

Oleg Starodumov schrieb/wrote:

> When the application is running under debugger, or linked with Debug
> CRT, the freed heap block is usually overwritten with a pattern that
> helps to detect reuse-after-delete situations (unless special actions
> are taken to disable such behavior).
>
> In case of BSTR allocation, there is an additional cache involved, so
> it is possible that the heap block is not freed when BSTR is released:
> http://support.microsoft.com/?id=139071

Thank you for the elaboration. In fact, I didn't know that IMalloc (the
heap ultimately used for BSTRs) uses an overwrite pattern like the CRT
does.

I would like to stress for Tyagi, though, that the bottom line remains: No
change of the data after Clear() doesn't mean that the memory is wasted.

Oleg
Thu Apr 21 07:31:47 CDT 2005


> Thank you for the elaboration. In fact, I didn't know that IMalloc (the
> heap ultimately used for BSTRs) uses an overwrite pattern like the CRT
> does.
>

AFAIK it uses the default process heap internally (which enables
the debugging features (e.g. fill patterns) when started under debugger).

> I would like to stress for Tyagi, though, that the bottom line remains: No
> change of the data after Clear() doesn't mean that the memory is wasted.

Right.

Oleg