Sign in to follow this  
dave

Why Do You Need A Memory Manager

Recommended Posts

The Enginuity article suggests a smartpointer, which i fuly agree on, but im not entirely sure on why one would need a memory manager. Could some take the time to explain it please. In the mean time i'm going to give it a read again. Thanx ace

Share this post


Link to post
Share on other sites
as long as by memory manager you mean resource manager(i may be confused on terms) but a resource manager makes sure you dont load the same thing twice, and makes sure you dont keep things around that you dont need, IE: dont load the same texture twice, and say, you KNOW that a certain enemy will never come back, you can get the model and texture data for that enemy out of memory

hope that helps
-Dan

Share this post


Link to post
Share on other sites
Usually memory management is most useful when you need to allocate and release assets very frequently with a relatively unpredictable pattern, for example in a scripting engine or a graphics system that loads and unloads large amounts of data in certain situations. Instead of allocating, preparing, using, and then releasing memory, you can allocate a few huge blocks, fill them as needed, and then release the entire block when you're done. This gets rid of lots of room for memory leaks because you don't have thousands of tiny chunks of allocated memory to free.

There are also some marginal performance benefits in certain specialized cases. Allocating and releasing memory, especially in lots of small pieces, can be slow if done in the wrong places. The OS does a lot of bookkeeping (and more is done by the standard libraries in debug builds) so it can often be useful to avoid some of that and just track the usage yourself when you need to.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You can use a memroy manager to find memory leaks in your program. . .

Share this post


Link to post
Share on other sites
Ok, so ive just re-read it and i actually am getting it now.

One thing though. Why does the code have:

//a 'static initialiser' is needed in one of the source
//files to give the std::list a definitive presence
std::list<IMMObject *> IMMObject::liveObjects;

Why does there need to be a definitive presenmce. Is this so the object can act upon itself?

ace

Share this post


Link to post
Share on other sites
I'm going to have a go at answering this, then see how many corrections I get (see if I've learnt anything yet!).

I assume that in the IMMObject class definition, there is something like:

static std::list<IMMObject *> liveObjects;

A static data member exists as a single entity over all realisations of that object-type - that is, if you have:


// includes

struct ob{
static int x;
};
int ob::x = 0;

int main()
{
ob ob1, ob2;
ob1.x = 1;
// Note could also use ob.x, as it's a static member
std::cout << ob2.x;
}




What you'd see is that ob2.x also now equals 1 - there is only one element ob.x that co-exists in every ob objects.

Because it only exists in one place (and not one place per object), the data is actually stored off to one side, and not in the memory local to the object. This memory needs initialising at some point, on an object-wise level - this is what the int ob::x in this case, or the std::list<IMMObject *> IMMObject::liveObjects; in your example does - it initialises the memory for the static object.

Hope this is (mostly) correct!
Jim.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this