[ACCEPTED]-Usage of CoTaskMemAlloc?-com

Use CoTaskMemAlloc when returning a char* from 4 a native C++ library to .NET as a string.

C#

[DllImport("test.dll", CharSet=CharSet.Ansi)]
extern static string Foo();

C

char* Foo()
{
    std::string response("response");
    int len = response.length() + 1;
    char* buff = (char*) CoTaskMemAlloc(len);
    strcpy_s(buff, len, response.c_str());
    return buff;
}

Since .NET uses CoTaskMemFree, you 3 have to allocate the string like this, you 2 can't allocate it on the stack or the heap 1 using malloc / new.

Gosh, I had to think for a while for this 30 one -- I've done a fair amount of small-scale 29 COM programming with ATL and rarely have 28 had to use it.

There is one situation though 27 that comes to mind: Windows Shell extensions. If you are dealing 26 with a set of filesystem objects you might 25 have to deal with PIDLs (pointer to an ID list). These 24 are bizarre little filesystem object abstractions 23 and they need to be explicitly allocated/deallocated 22 using a COM-aware allocator such as CoTaskMemAlloc. There 21 is also an alternative, the IMalloc interface pointer 20 obtained from SHGetMalloc (deprecated) or CoGetMalloc -- it's 19 just an abstraction layer to use, so that 18 your code isn't tied to a specific memory 17 allocator and can use any appropriate one.

The 16 point of using CoTaskMemAlloc or IMalloc rather than malloc() is that 15 the memory allocation/deallocation needs 14 to be something that is "COM-aware" so 13 that its allocation and deallocation are 12 performed consistently at run-time, even 11 if the allocation and deallocation are done 10 by completely unrelated code (e.g. Windows 9 allocates memory, transfers it to your C++ code 8 which later deallocates, or your C++ code 7 allocates, transfers it to someone else's 6 VB code which later deallocates). Neither 5 malloc() nor new are capable of interoperating with 4 the system's run-time heap so you can't 3 use them to allocate memory to transfer 2 to other COM objects, or to receive memory 1 from other COM objects and deallocate.

This MSDN article compares a few of the various allocators 10 exposed by Win32, including CoTaskMemAlloc. It's 9 mainly used in COM programming--most specifically 8 when the implementation of a COM server 7 needs to allocate memory to return back 6 to a client. If you aren't writing a COM 5 server, then you probably don't need to 4 use it.

(However, if you call code that allocates 3 memory using CoTaskMemAlloc and returns 2 it back to you, you'll need to free the 1 returned allocation(s) using CoTaskMemFree.)

there is not really much which can go wrong 11 as the following calls all end up with the 10 same allocation:

CoTaskMemAlloc/SHAlloc -> IMalloc.Alloc -> GlobalAlloc(GMEM_FIXED)

only if you use non-windows 9 (compiler-library) calls like malloc() things will 8 go wrong.

Officially one should use CoTaskMemAlloc for 7 COM calls (like allocating a FORMATETC.ptd 6 field)

That CoTaskMemAlloc equals GlobalAlloc() will stay this way 'till 5 eternity is seen at the clipboard api versus 4 com STGMEDIUM. The STGMEDIUM uses the clipboard 3 structures and method and while STGMEDIUM 2 is com and thus CoTaskMemAlloc, the clipboard 1 apis prescribe GlobalAlloc()

CoTaskMemAlloc is same as malloc except 11 that former is used to allocate memory which 10 is used across process boundaries.

i.e., if 9 we have two processes, process1 and process2, assume 8 that process1 is a COM server, and process2 7 is a COM Client which uses the interfaces 6 exposed by process1. If process1 has to 5 send some data, then he can allocate memory 4 using CoTaskMemAlloc to allocate the memory 3 and copies the data. That memory location 2 can be accessed by process2.

COM library 1 automatically does the marshalling and unmarshalling.