Why Do You Need A Memory Manager
Author
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
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
hope that helps
-Dan
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.
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.
Author
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
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
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:
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.
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:
// includesstruct 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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement