Ok ive researched into this quite a bit and im not sure why u would want them. 1. Everything on the stack is dealt with when it goes out of scope. 2. Need to Delete anything that is 'new'ed. 3. I was told that a programmer should create objects on the stack wherever possible and i have certainly never found the need to do otherwise. 4. COM objects are taken care of already in terms of reference counting. 5. Linked Lists can be deleted with a simple algorythm. So why else would you want a memory manager? Ace

ok im with this, didnt realise the COMs were heaped, so they need to be deleted. If you dont know how many objects then you would link list them wouldnt you so you can create as many as you need. But u can still create these objects on the stack. obviously a linked list deletion algo would 'delete' the memory allocated.

ace

Actually you dont need to deallocate memory on the heap at process termination. The operating system will reclaim it when this happens; the concept of a memory leak applies during the runtime of a program.

Quote:Original post by ace_lovegrove
Ok ive researched into this quite a bit and im not sure why u would want them.

1. Everything on the stack is dealt with when it goes out of scope.
2. Need to Delete anything that is 'new'ed.
3. I was told that a programmer should create objects on the stack wherever possible and i have certainly never found the need to do otherwise.
4. COM objects are taken care of already in terms of reference counting.
5. Linked Lists can be deleted with a simple algorythm.

So why else would you want a memory manager?

Ace

One reason is to replace new and delete for small memory allocations. That way you don't have fragmented memory and are at peak performance.

new and delete are very inefficient when allocating small objects on the heap.

I allocate larger objects on the heap with a memory management class, and smaller objects I allocate in an already predefined block of memory that I have allocated.

surely the memory manager just calls new and delete for you

1. Everything on the stack is dealt with when it goes out of scope.

Sometimes this is not what you want. Say you have a function that creates an object from some complex calculations. You don't want to return it by value since it contains enough information that this is costly. And you certainly want to keep it around for awhile. But if you declare it on the stack, it goes out of scope when the function that created it does.

2. Need to Delete anything that is 'new'ed.

This can be dealt with easily. There are techniques to cope with this - garbage collection and RAII (Resource Aquisition Is Initialization) to name two of them.

3. I was told that a programmer should create objects on the stack wherever possible and i have certainly never found the need to do otherwise.

Your source oversimplified. Case in point: in many circumstances where you have an array of a size you don't know ahead of time, you could do something like:

char huge_waste_of_memory[1000000000];

with the variable named for one reason not to use that method.

The much better solution in this case would be:

char my_array = new char[number_of_chars_i_need];

4. COM objects are taken care of already in terms of reference counting.

Not everything's a COM object. Reference counting is one method of helping manage memory - they are most likely dynamically allocated.

5. Linked Lists can be deleted with a simple algorythm.

But need their data stored somewhere.

Q) So why else would you want a memory manager?

Whenever you use a varying amount of objects, you can either:

1) Create a huge array that will eat memory like crazy and quickly crash.
2) Use a container (which in turn does dynamic allocations, using the memory manager behind the scenes) such as std::deque or std::list. Implementing your own can, in some circumstances, provide speed benifits (not for the non-advanced who havn't profiled their code yet)
3) Use stack magic (not allways a viable option, there's only one stack to grow and shrink but there's 20 different uses for it, and if you have two objects on the stack, you can't delete the older one before deleting the younger one - cases in point where this is a problem:

Setting: Starcraft.
Player A builds a Zergling (he's rushing)
Player B builds Marine dude (he knows he should defend against rushes)
Player A attacks player B with his zergling
Player B's Marine kills Player A's Zergling.
PROBLEM: Player A's Zergling is older, but it can't be deleted since Player B's Marine is still alive.

Sure, you can mark Zergling A as "dead", but that dosn't free up the memory associated with him - this will lead to a memory leak, which is bad, because it can lead to a crash if your system consumes all the available system memory, for example.

Out of those 3, the only one that can allways be used is #2 - use a container of some sort. This is either a built in one such as those found in the std:: namespace, which use a memory manager behind the scenes, or those made yourself (even if it's not assembled into a single class, it's there on some level conceptually) which you have to program.