Jump to content
  • Advertisement
Sign in to follow this  
dave

Why Would You Want A Memory Manager?

This topic is 5163 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by ace_lovegrove
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.

What do you do when you don't know how many objects you need at compile time?
Quote:

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

COM objects are allocated on a heap.
Quote:

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

Where does the memory for the nodes(and the data they contain) come from?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Arild Fines
Quote:
Original post by ace_lovegrove
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.

What do you do when you don't know how many objects you need at compile time?


You make sure your program will always delete all the objects it dynamically creates at program termination. It isn't that hard.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by owl
Quote:
Original post by Arild Fines
Quote:
Original post by ace_lovegrove
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.

What do you do when you don't know how many objects you need at compile time?


You make sure your program will always delete all the objects it dynamically creates at program termination. It isn't that hard.

T'was a rhetorical question.

Share this post


Link to post
Share on other sites
Quote:
Original post by ace_lovegrove
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.

That doesn't explain where the memory for the linked list comes from. Either you preallocate alot of static memory to ensure you can fit all the nodes, or you dynamically allocate the nodes. Guess which one is most common?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!