Exception-safe memory handling with COM

Question

When using COM, I typically rely on ATL smart pointers, like ATL::CComPtr and ATL::CComBSTR, for resource management. But some of the methods I'm calling use output parameters to return pointers to allocated storage that I have to free. For example:

WCHAR *pszName = nullptr;
if (SUCCEEDED(pShellItem->GetDisplayName(SIGDN_FILESYSPATH, &pszName))) {
  DoSomething(pszName);
  CoTaskMemFree(pszName);
}

Note that GetDisplayName allocates memory for the string and returns a pointer to it through the output parameter. It's the caller's responsibility to free that memory with CoTaskMemFree.

If DoSomething throws an exception, then the above code will leak. I'd like to use some sort of smart pointer for pszName to avoid such leaks, but the API takes WCHAR**, so I don't see how I can pass anything but the address of a dumb pointer. Since I'm not the one allocating, I can't use RAII.

I can use RRID if I can make a deleter like this:

struct CoTaskMemDeleter {
  void operator()(void *p) { ::CoTaskMemFree(p); }
};

And then immediately assign the returned pointer to a standard smart pointer like this:

WCHAR *pszName = nullptr;
if (SUCCEEDED(pShellItem->GetDisplayName(SIGDN_FILESYSPATH, &pszName))) {
  std::unique_ptr<WCHAR, CoTaskMemDeleter> guard(pszName);
  DoSomething(pszName);
}

That works, but it seems error-prone to introduce an extra guard variable. For example, this approach leaves pszName pointing at the released memory, so it would be easy to accidentally use it again.

Is there a cleaner way to use a smart pointer or an RAII wrapper for COM-server allocated memory returned by output parameter? Am I missing something that ATL provides?

What's so bad about freeing the memory yourself? To me, it doesn't seem worth the effort to do anything else. — evanmcdonnal, Mar 14 '13 at 20:40
@evanmcdonnal - or just not having to worry about an early return somewhere that bypasses the clean up code. Even if you get it right initially, some maintenance dev may break it later without anyone realizing. RAII is just safer. — Scott Smith, Nov 20 '20 at 16:10

score 15 · Accepted Answer · answered Mar 14 '13 at 21:01

15

ATL already has this one out of the box:

CComHeapPtr<WCHAR> pszName;
const HRESULT nResult = pShellItem->GetDisplayName(..., &pszName);
// Hooray, pszName will be CoTaskMemFree'd for you on scope leave 
// via ~CComHeapPtr

CHeapPtr can be derived to implement other resource releasers in a similar way. CComHeapPtr is a MSDN documented class .

answered Mar 14 '13 at 21:01

Roman R.

68,205
6
94
158

1

I saw CComHeapPtr in the ATL docs, but I didn't realize that `CoTaskMemAlloc`/`Free` use `CComAllocator`. My next reaction was, "How does that compile?", since `&pszName` would appear to be `CComHeapPtr*` rather than `WCHAR**`. Then I discovered that the ATL pointer classes overload unary `operator&`, which I thought was forbidden but is actually just strongly discouraged. That overload also prevents you from keeping those in an STL container. – Adrian McCarthy Mar 14 '13 at 21:25
The smart template class is similar to well known `CComPtr` by wrapping pointer and taking one reference `*` from the template argument: `IUnkown*` is wrapped by `CComPtr`, and `WCHAR*` is wrapped by `CHeapPtr`. Yes both overload `&` in particular to raise assertion failure once you attempt to expose non-NULL pointer as a placeholder to accept new raw value. – Roman R. Mar 14 '13 at 21:34
1

Just out of curiosity: Who discourages writing operator& ? – StuartRedmann Mar 19 '13 at 13:08
@Roman: Sorry, I should have added an Adrian to my comment. – StuartRedmann Apr 03 '13 at 19:32
1

@StuartRedmann: Several times I've heard the advice to avoid overloading the address-of operator. Before C++11, STL containers couldn't hold objects with an overloaded address-of operator, which may have been a motivation for that advice. For example, see "Resistance to overloaded address-of operators" on this page: http://msdn.microsoft.com/en-us/library/hh567368.aspx – Adrian McCarthy Dec 17 '13 at 23:58
@Adrian: Ah, I remember. I agree insofar that one should know the consequences of overloading the address-of operator. However, I think that STL containers should still work for objects that provide a non-standard operator& (IOW, an operator& that does some fancy stuff). I can't imagine why STL containers need to know the address of an object except for efficiency reasons. – StuartRedmann Dec 18 '13 at 13:44
@myself: Found it: http://stackoverflow.com/questions/2719832/why-is-overloading-operator-prohibited-for-classes-stored-in-stl-containers – StuartRedmann Dec 20 '13 at 06:20

Exception-safe memory handling with COM

1 Answers1