• Advertisement
Sign in to follow this  

Why Would You Want A Memory Manager?

This topic is 4834 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
Quote:
Original post by ace_lovegrove
surely the memory manager just calls new and delete for you


no its not that simple, new & delete operators are very general purpose, they add information that is usually not worth it for very small instances, besides not only do the new operators allocate memory they invoke constructors there are times you don't wont to invoke constructors as soon as the memory is allocated generally the case for memory managers.

The reason why you would want to write your own your use a pre-written memory manager is not to just be conservative with memory but to also prevent memory fragmentation that can kill the performance of your app. When you allocate small instances on the heap at random/arbitrary periods of time this is the most likely case you will fragment the heap. Also you might wont to use a different memory model.

This is the reason why STL containers are parameterized by Allocator type, you don't have to use the default allocator type which usually wrap up new & delete operators which can be inefficent for small objects such as pointers.

This is also the reason why you can overload the operators new & delete for a particular type or type hierarchy or every type.

Share this post


Link to post
Share on other sites
I'm confused. What do you think a "memory manager is"?
Quote:
Original post by ace_lovegrove
2. Need to Delete anything that is 'new'ed.

Is this a reason you don't want to use a memory manager, or is it just a random observation on how manual memory management works? Typically, an automatic memory manager deletes objects for you, so you don't need to 'delete' anything that is 'new'ed.
Quote:

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.

That's an overgeneralisation.

Not all languages have the concept of memory partitioned into the stack and the heap. Even C/C++ doesn't explicitly state that local variables are stored on a stack -- the standards are written to allow for architectures that don't have stacks.

What all languages provide is a class of storage where the lifetime of the object is known. For many scripting languages, all allocations are 'heap-like'. In C/C++, auto variables die when their containing block dies.

Every programmer should know the lifetime of an object. More specifically, every programmer should know that an object will die when it is no longer needed. Because all mainstream implementations of C/C++ lack automatic memory managment for heap-allocated objects, a C/C++ programmer is therefore encouraged to allocate objects in 'the stack', because their lifetime is known.

The point to note is the reason people are encouraged to allocate objects on the stack. As mentioned above, stacks are usually much smaller than heaps, so you don't want to allocate very large objects on them. To keep the benefit of stack allocation, use autoptr or something similar to allocate objects on the heap but give them auto storage duration.
Quote:

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

Obviously, COM objects are stored on the heap. Also note that you are responsible for maintaining the reference count of COM objects you have pointers to, which is additional hassle that a memory manager would avoid.
Quote:

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

Linked lists may also contain pointers to objects that are referenced outside the linked list. If linked lists delete what they point at, you may have dangling pointers elsewhere in your program. If they don't, you may have a memory leak.
Quote:
Original post by ace_lovegrove
surely the memory manager just calls new and delete for you

I don't understand. A memory manager would usually call delete for you, yes. But I would expect, in most cases, to call new myself.

Share this post


Link to post
Share on other sites
Quote:
Original post by ace_lovegrove
surely the memory manager just calls new and delete for you

The new/delete pair *is* a memory manager.

Share this post


Link to post
Share on other sites
So now im pretty sure that i need a memory manager but the syntax of ones described, such as the Enginuity one, is far to
complicated for me. So i guess i'll have to do without for now.

ace

Share this post


Link to post
Share on other sites
Quote:
Original post by 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.
I'm sick of people saying this. Don't go suggesting stupid bad habits like this. You MUST ensure that you match EVERY new with a delete or EVERY malloc with a free etc.

Otherwise when you want to find a memory leak using helpful tools such as bounds-checker, then you still wont be able to tell which bit of memory that wasn't freed, was the bit that was leaking. Hence you wont know where the leaked memory was alocated. You're also not going to ever spot the leak when the program closes in the debugger, but only after seeing a decent unexplained increase in memory in the taskmanager.

GC is not a silver-bulet!

Share this post


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

  • Advertisement