views:

1287

answers:

8

I'd like to know which method is recommended on Windows C programming: using malloc or the Win32 HeapAlloc (maybe VirtualAlloc?) function.

I've read the MSDN Memory Management Functions article and the MSDN articles regarding malloc and HeapAlloc, but they do not say which one should be used and in what situations.

+16  A: 

Stick with malloc unless you have a compelling reason to use something different. It will be implemented underneath in terms of the OS memory allocation primitives, but there is no real advantage in diving down to that layer yourself.

A few API calls I believe need a memory block allocated from a Windows heap, but you will know when you come across them.

Or if you want to do something more advanced, like use shared memory, or need to control the permissions on the memory pages directly then you will need to look at the Windows API calls like VirtualAlloc.

Rob Walker
+3  A: 

One more thing: malloc() is guaranteed to be portable (at least to any ANSI-C implementation) and more elegant.

aib
A: 

Unlike Rob, I go the other way... Since I chose to code against the WinAPI, I use the native functions instead of C run-time ones, which are just a thin wrapper around them anyway.

PhiLho
One downside of this is that if you try to incorporate some other C library into your app it will likely expect to work with malloc, and now you have to be extra careful about which allocator to use.
Rob Walker
Ah, but in any case, you must always use the routine to free memory provided by the library itself (hoping the author was wise enough to provide it!), because you can have a DLL statically linked with a runtime and your application depending of another runtime, a sure way to crash!
PhiLho
+1  A: 

In some situations using functions such as HeapAlloc, HeapFree will make your life easier. One example would be: a big application where you need to allocate memory in one module (say in library1.dll) and free that memory in the main module (say program.exe). This can be done safely if you are using HeapAlloc, HeapResize and HeapFree functions, but cannot be done using C runtime library (eg malloc, free, resize).

BUT: If you don't have a good reason, you should stick with malloc/free/resize functions. Also, if you need to change permisions of the allocated memory (eg: to make if executable, etc), you should use functions such as VirtualAlloc, VirtualFree.

botismarius
Can you explain why memory allocated with malloc() - regardless of location - cannot be released by free()? It sounds most odd!
Jonathan Leffler
Because the C standard has nothing to say about the build process, which allows implementations to stipulate conditions about what you can and can't do across dlls. For instance, if malloc/free uses static variables and is statically linked, then each dll would have its own copy. Nasty, but legal.
Steve Jessop
Statement is wrong: you can malloc in DLL, free in EXE, as long as you use MSVCRT*.DLL. Should be "Cannot be done using _static_ C runtime library"
MSalters
Yes, if you link dinamically with msvcrtX.dll it should work.
botismarius
+1  A: 

You could make a wrapper and leave the option to change the implementation details. You could even compare both options with your code and then decide.

Null303
+1  A: 

VirtualAlloc and friends can give you a bit of an edge if you do have heaps of data to process or if you need to go to the trouble of creating your own memory manager anyway.

Otherwise it's easier and of course more portable to just use malloc().

VirtualAlloc has this nifty feature called MEM_RESET, which invalidates the data in a block of memory, but keeps it allocated. This means if it's paged to disk, Windows won't bother to page it back in next time you access it. It's nice if you have many megs of data that can suddenly become unnecessary, but you'll soon have something else to fill the buffer up.

It also differentiates between reserving address space and actually requesting memory. There's some nice stuff there if you have a good reason to go to all that trouble.

Artelius
A: 

With HeapAlloc you can have separate heaps for different tasks/subsystems. This may simplify dump analysis of large applications.

With malloc you can only use one heap, but you get some allocation optimizations that CRT authors may have implemented on top of OS HeapAlloc.

Going down to VirtualAlloc doesn't buy you much, unless you want to implement custom heap manager (your own set of Heap* functions).

Constantin
A: 

Comparing Memory Allocation Methods from msdn.

Comptrol