Re: proper way of handling [out,retval] VARIANT * args
- From: "Alexander Nickolov" <agnickolov@xxxxxxxx>
- Date: Wed, 23 Aug 2006 10:16:15 -0700
Your code is correct. The pointer must not be NULL of course,
and the location it points to is presumed to be uninitialized, thus
VariantInit. Here VariantClear is a clear invitation for a crash.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Jason S" <jmsachs@xxxxxxxxx> wrote in message
news:1156349994.825654.193260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Oh wise masters of COM:
what's the proper way to handle an [out,retval] VARIANT *arg ?
Do you use VariantInit() after checking for a null arg, or
VariantClear?
STDMETHODIMP CBlah::get_something(VARIANT *pVal)
{
if (pVal == NULL)
return E_POINTER;
VariantInit(pVal);
// do some stuff, it may return an error
// everything is great, assign the VARIANT
CComBSTR b = L"something from blah";
V_VT(pVal) = VT_BSTR;
V_BSTR(pVal) = b.Detach();
return S_OK;
}
.
- References:
- proper way of handling [out,retval] VARIANT * args
- From: Jason S
- proper way of handling [out,retval] VARIANT * args
- Prev by Date: Re: Interface-based security?
- Next by Date: usage help for _com_ptr_t smart pointers created with #import
- Previous by thread: proper way of handling [out,retval] VARIANT * args
- Next by thread: Memory leakage in BHO
- Index(es):