16

When is it appropriate to use CoTaskMemAlloc? Can someone give an example?

mmcdole
  • 91,488
  • 60
  • 186
  • 222
atVelu
  • 815
  • 1
  • 12
  • 24
  • I've posted some information below on when you might need to use CoTaskMemAlloc, but it might be helpful for you to provide some context for your question... – reuben Dec 26 '08 at 05:54
  • fixed up the question and it's title a bit. – mmcdole Dec 26 '08 at 06:09

5 Answers5

21

Use CoTaskMemAlloc when returning a char* from 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 have to allocate the string like this, you can't allocate it on the stack or the heap using malloc / new.

Maurice Flanagan
  • 5,179
  • 3
  • 30
  • 37
  • When is the resource returned by `Foo()` freed? Or should that be done manually? – chtenb Feb 08 '17 at 12:35
  • @ChieltenBrinke CLR will follow the same GC rules for the resource as for all other managed resources. – zz3599 Feb 10 '17 at 19:04
  • @zz3599 what does that mean? The CLR needs to know all references to that memory. But at the point of calling CoTaskMemAlloc we are still in unmanaged code, so as far as the CLR knows there are no references to that memory. But that would mean that that memory could be collected right after allocating it, which is not the case I suppose, as it would render this example invalid. Question is: how does it work then? – chtenb Feb 11 '17 at 08:36
  • Assuming that you keep a managed reference to the returned value of Foo(), the memory will not be collected. It no longer is your responsibility to free it. – zz3599 Feb 12 '17 at 20:49
13

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

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

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

Jason S
  • 184,598
  • 164
  • 608
  • 970
8

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

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

reuben
  • 3,360
  • 23
  • 28
  • Thanks Reuben, My requirement is to allocate memory from the comserver in process -> do a realloc on the same from the comclient side which is again a different process and then free it from the comserver side ... I hope I can use cotaskmemxxx fns for achieving the same - – atVelu Dec 26 '08 at 06:27
3

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

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

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

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

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

GDP
  • 8,109
  • 6
  • 45
  • 82
  • This logic looks to be wrong already - it's sufficient that both `GlobalAlloc` and `CoTaskMemAlloc` use the same heap, i.e. `GetProcessHeap`. These wrapper functions could add different functionality on top without breaking `STGMEDIUM`. – MSalters Oct 06 '22 at 13:40
2

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

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

COM library automatically does the marshalling and unmarshalling.

Vinay
  • 4,743
  • 7
  • 33
  • 43