On Memory Allocation and C++

Question

And I quote from MSDN http://msdn.microsoft.com/en-us/library/aa366533(VS.85).aspx:

The malloc function has the disadvantage of being run-time dependent. The new operator has the disadvantage of being compiler dependent and language dependent.

Now the questions folks:

a) What do we mean that malloc is run-time dependent? What kind of dynamic memory allocation functions can be independent of run-time? This statement sounds real strange.

b) new is language dependent? Of course it should be right? Are HeapAlloc, LocalAlloc etc language independent?

c) From a pure performance perspective are the MSVC provided routines preferable?

Arpan

Answer 1

a) It means that the behaviour of malloc depends on the version of the C-runtime you compile against.

b) HeapAlloc and LocalAlloc are Win32 API functions. They are indeed both runtime and language independant.

c) That's impossible to answer without knowing how the runtime routines are implemented. I suspect that their performance is comprable. In any case, if you go with the new operator, then you always have the option of overriding it later if necessary. Remember, premature optimization is the root of all evil. ;)

One final note: LocalAlloc and GlobalAlloc are slow. You shouldn't use them unless forced to by a crufty old Win32 API.

Answer 2

a) In this case I think they're eliding "run-time library" to "run-time". In other words it depends on the implementation in your C library.

b) Indeed new is C++ specific. HeapAlloc, etc are technically usable in C and C++.

c) They can't be used to create C++ objects because they won't call constructors so the point is pretty moot. In C++ you should use new and delete.

Answer 3

The problems with malloc and new arise when you use DLLs. Depending on build options, a DLL may have its own copy of the CRT. That makes it use its own heap to allocate memory from, a different heap than the one used by the EXE. This causes failure when memory is allocated by one module and released by another. Very common when you use STL.

One way to solve it is by compiling code with the /MD option. That forces use of a shared copy of the CRT, stored in its own DLL. Problem solved, there's now only one allocator, using a single heap.

This issue also arises with COM, it allows different languages to interop. They would of course never share an allocator since those language have different runtime support libraries. By contract, COM code must use a single allocator provided by the COM runtime support, CoTaskMemAlloc().

Note that HeapAlloc() cannot solve this problem. It requires a handle to a heap, returned by HeapCreate(). Different modules would have to share that handle to avoid trouble.

Answer 4

Wow, that is a curious statement to appear in documentation without an accompanying explanation. Could it be a hold over from when C++ was introduced? I can only guess as to the answers to your questions:

a) Perhaps they mean to contrast it with link/load time allocation, such as for globals, constants, and static data. Or perhaps they mean to contrast it with stack allocation, such as the alloca family.

b) They may be drawing attention to the fact that you shouldn't allocate memory with C++ new, then pass ownership of that memory to library routine which may free() it. So in that sense, the result of the allocation is language-specific.

c) Use C++ new and delete. You have to assume that the underlying C++ allocator in the MSVC runtime is as fast as, if not identical to, the C-style system calls. Just remember that new and delete do more than allocate and free memory. They are not purely substitutable with malloc and free or with other C-style allocators.