kuphryn, although I am not a extremely experienced programmer I dont''t think it really matters what you use to allocate memory for your program. Using the c/c++ memory allocation functions, however will make your program more portable than if you were to use windows memory allocation functions.

How about them apples?

you never know what you can dig out browsing members'' profiles!

here are some (hopefully) interesting facts regarding the various memory allocators:

VirtualAlloc: the heavylifter. use this if you need lots of memory, such as several megabytes; you''ll bypass lots of heap management code. keep in mind that allocation granulatiry is currently 64 KB, and your requests will be rounded up to that figure. works nicely with structured exception handling and VirtualProtect when you want to have a huge array of something, but are not likely to use many of its elements at any time.

HeapAlloc: suggested Win32 solution for small allocation requests. you can have multiple heaps in a single application to combat heap fragmentation and decrease lookup time for allocation requests.

GlobalAlloc: ms says you shouldn''t use it for performance reasons, however it''s still used by clipboard, dde, drag and drop, and other interprocess data exchange services.

LocalAlloc: its use is also discouraged, however some applications use it if they don''t want to deal with heap handles that HeapAlloc requires. Note that LocalAlloc and GlobalAlloc memory is generally not interchangeable; even though the docs say that there are no separate global and local heaps, that doesn''t mean you can give a LocalAlloc''d pointer to the clipboard.

new: the c++ way to do things. it throws bad_alloc on allocation failure, which is very useful if you''re using exceptions for error handling because you can forget about doing all the pAllocatedItem != 0 checks and handle bad_alloc along with other exceptions. Internally implemented on top of malloc.

malloc: the c way to do things. provides additional management code on top of HeapAlloc, but doesn''t require a heap handle as HeapAlloc does (it uses the default process heap for allocations). in msvc7 (not sure about 6), malloc can call your _set_new_handler routine (note leading underscore; it''s an ms feature, not c++ standard one), which allows you to make malloc throw exceptions. the actual usability of this feature in my view is, however, small because existing code doesn''t expect malloc to throw exceptions, and therefore will not clean up properly if it does. malloc is implemented on top of HeapAlloc. a nice feature of malloc is the ability to resize allocated blocks via realloc without manually copying data to new block, which new doesn''t support.

_DBG_MAP_ALLOC and <crtdbg.h> will give you the debug heap which provides additional error checking, such as overwrite/underwrite checks, delayed memory releases, checks for writes to freed blocks, memory leak checking, and so on. this is the most important reason for using either new or malloc over its win32 counterparts: you get free debug heap diagnostics in debug builds. win32 also provides some heap diagnostics, but it''s much less useful than msvc debug heap.

ATL_MIN_CRT will make new and malloc barebone wrappers on top of HeapAlloc.

well, some things requre GlobalAlloc-allocated memory, so naturally you''d use it for them. You would prefer HeapAlloc over new/malloc when you''re trying to avoid crt code to minimize your exe size.