I''ve read several articles and books that have sections about memory management, but they all seem to have a different purpose. One implementation overrides the new and delete operator to add header information, one keeps track of all the objects currently allocated and deletes those that aren''t in use, etc. I haven''t really figured out what a good memory manager will do/be good for. So I was wondering, do you use a memory management class/method and what what does it do (besides manage memory )?

Probably the most commom use of memory managers (though it''s not really a manager) is to trace and check for memory leaks. By tracking allocation and free''s (or new/deletes) you can obtain a list of all the memory leaks generated, and you can also record very helpfull info at alloc time like the file and line number of the alloc/new call. Flipcode has a pretty good article on doing just that.

I could be wrong but i think most full blow managers are created out of necesity, where heavy use of memory allocation is killing performance, although some projects may use their own managers to add ''nice'' features like garbage collection. If your doing any sort of console dev then you''ll probably want one.

I''ve got a memory wrapper to track new/delete but nothing beyond that. It just dumps anything its still holding out to a log file before the application exits giving me a full rundown of any memory leaks.

Ours does the following:

overrides new, new[], delete, and delete[] 3 ways
1. std new
2. placement new (no tracking or leak detection needed here)
3. new with info (file and line)

We also override malloc, calloc, realloc, and free to act like the 3rd version of new.

In my own personal tracking system, I override not just the global new for these, but form 1 and 3 of new in a base class that everything can derive from. This way is you use MFC and it forces it''s global new on you, you can still track all your own objects.

What do we use this for? To put a special header on the memory, which is used for the following:

1. We can detect leaks overall.
2. We can detect leaks between a begin and end tracking call. This can help narrow down leaks that are using new version 1. 3. We can tell exactly which objects were leaked, and where they were allocated if they use version 3 of new.
4. We can attach "comments" to an allocation. This can help track down which allocation wasn''t freed.
5. We can attach GPU resources to an allocation. Say we have a texture object. We can attach how much GPU texture memory is used too. When the class is freed, the comment is freed with it. Assuming the destructor is not buggy, and does actually free the GPU resource, this accurately reflects our GPU usage... for textures, vertex buffers, render targets, etc...
6. We can determine what percentages of memory are used for what. For either Heap or GPU.
7. We can sort a memory dump listing by file and line. We can give per file summaries.
8. We verify that the appropriate destruction method is used. If you delete rather than delete[], we catch it... This is something that usually goes unnoticed.

I''m implementing something along the lines of the flipCode manager. It just tells me how much memory was left allocated at the end of the program. Is there a real need for anything more than that?

IMHO, regarding terminology,

1. Memory Managers are for performance, reducing framgmentation.
2. Garbage Collectors are for leaks.

Another reason: so that things like this wouldn''t happen.

I used one mainly for making sure there were no memory leaks.

---
shurcooL`