views:

247

answers:

2

I have a COM function that should return a SafeArray via a LPSAFEARRAY* out parameter. The function creates the SafeArray using ATL's CComSafeArray template class. My naive implementation uses CComSafeArray<T>::Detach() in order to move ownership from the local variable to the output parameter:

void foo(LPSAFEARRAY* psa)
{
    CComSafeArray<VARIANT> ret;
    ret.Add(CComVariant(42));
    *psa = ret.Detach();
}

int main()
{
    CComSafeArray<VARIANT> sa;
    foo(sa.GetSafeArrayPtr());

    std::cout << sa[0].lVal << std::endl;
}

The problem is that CComSafeArray::Detach() performs an Unlock operation so that when the new owner of the SafeArray (main's sa in this case) is destroyed the lock isn't zero and Destroy fails to unlock the SafeArray with E_UNEXPECTED (this leads to a memory leak since the SafeArray isn't deallocated).

What is the correct way to transfer ownership between to CComSafeArrays through a COM method boundary?


Edit: From the single answer so far it seems that the error is on the client side (main) and not from the server side (foo), but I find it hard to believe that CComSafeArray wasn't designed for this trivial use-case, there must be an elegant way to get a SafeArray out of a COM method into a CComSafeArray.

+2  A: 

The problem is that you set the receiving CComSafeArray's internal pointer directly. Use the Attach() method to attach an existing SAFEARRAY to a CComSafeArray:

LPSAFEARRAY ar;
foo(&ar);
CComSafeArray<VARIANT> sa;
sa.Attach(ar);
Amnon
Surely this isn't the way `CComSafeArray` is supposed to be used, it goes against the grain of `CComVariant` and `CComBSTR`.
Motti
As you saw in the code, the CComSafeArray expects the SAFEARRAY to be locked. You have to lock it some way or the other.
Amnon
And there is no Attach-like functionality that locks and also no Detach-like function that doesn't Unlock - so the work has to be done on either the callers or the callees side.
Georg Fritzsche
+1  A: 

I'd guess that where was no intent to allow such a use case. Probably it was not the same developer who wrote CComVariant & CComPtr :)

I believe that CComSafeArray's author considered value semantics as major goal; Attach/Detach might simply be a "bonus" feature.

Andrey
And even with this reasonong, I still feel like `CComSafeArray`'s default ctor and `GetSafeArrayPtr` are design flaws/workarounds...
Andrey