How does one return a local CComSafeArray to a LPSAFEARRAY output parameter?

Question

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.

Answer 1

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);

Answer 2

Just to confirm that the marked answer is the correct one. RAII wrappers cannot work across COM boundaries.

The posted method implementation is not correct, you cannot assume that the caller is going to supply a valid SAFEARRAY. Just [out] is not a valid attribute in Automation, it must be either [out,retval] or [in,out]. If it is [out,retval], which is what it looks like, then the method must create a new array from scratch. If it is [in,out] then the method must destroy the passed-in array if it doesn't match the expected array type and create a new one.

Answer 3

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.