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.

Obfuscate

Which version of Visual Studio are you using? – Exciseman

This happens for both VS8 (2005) and VS9 (2008) – Obfuscate

Based on my experience I believe whoever designed CComSafeArray never actually used it. You can use your own wrapper class if you want. – Quag

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

Quag

Surely this isn't the way CComSafeArray is supposed to be used, it goes against the grain of CComVariant and CComBSTR. – Obfuscate

As you saw in the code, the CComSafeArray expects the SAFEARRAY to be locked. You have to lock it some way or the other. – Quag

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. – Scaler

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.

Baneberry

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.

Tobe

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