global objects
Author
hi
When using vc++6 and I want to have objects as global variables eg some sprites
i dont know how many i will need until run-time.
How do I declare them, dynamic allocation with objects being declared as Pointer to Object with new keyword. Or just instances of Objects
do i store the object pointers in an array of some huge size in case I need it or in a container (even though a conatiner of object pointers is popular I understand)..........
whats the standard way you do this and be efficient with memory?
The standard way is to use either an std::list or std::vector, e.g. :
The way to do it with dynamic pointers, however, is like this :
However, perhaps you should consider encapsulate this array of Entities in a class of some sort.
Cheers.
// globalstd::vector<Object*> _objVec;// orstd::list<Object*> _objList;// ----// edit// ----// you don't need to declare the sizes, as// whenever you need to add an object, you// call_objList.push_back(obj);// and the list is automatically resizedThe way to do it with dynamic pointers, however, is like this :
// array of objects (1-D)Object* _mObj;// initialize;_mObj = new Object[size_of_array];// where size_of_array is obviously some non-negative numberHowever, perhaps you should consider encapsulate this array of Entities in a class of some sort.
Cheers.
Author
Quote:Original post by stormrunner
However, perhaps you should consider encapsulate this array of Entities in a class of some sort.
Cheers.
2 questions i have
1) I was confused because I thought having a container of object pointers is not the done thing but in the above situation what else can you do apart from not having global objects
2) my objects are not an array becuase I dont know the full size until run-time. I thought this is a common situation in game programming
Quote:Original post by jagguy
1) I was confused because I thought having a container of object pointers is not the done thing but in the above situation what else can you do apart from not having global objects
When people suggest that having a container of object pointers "is not the done thing", they are contrasting that to having a container of actual object instances. I.e., std::vector<FruitBat> versus std::vector<FruitBat *>. In certain situations it does not work right to use the vector of instances, and you are stuck with a vector of pointers instead. However, the containers are designed to be used with actual instances if possible. Also, if you have a vector of pointers, you become responsible for the memory management (in particular, since your container might be sharing the objects, you must know what the ownership semantics need to be). Thus it is sometimes justified to use a container of "smart pointers" (instances of objects which pretend to be pointers) instead. (There are a few standard classes that fit that description. Be warned: do not try to use std::auto_ptr for this purpose.)
Quote:2) my objects are not an array becuase I dont know the full size until run-time. I thought this is a common situation in game programming
It is.
Dynamically allocating an array is ok if you "don't know the full size until runtime", but you do know "the full size won't change over the course of the program's execution". If it might (and there are other reasons too), go with the container.
Author
I was also concerned about memory managemant.
A container of instances is great but I thought you cant do this for global variables as it could be to memory costly...correct me if i am wrong
what would be the difference of global pointer objects and local object instances is respect to memory......heap/stack and potential for blow out
A container of instances is great but I thought you cant do this for global variables as it could be to memory costly...correct me if i am wrong
what would be the difference of global pointer objects and local object instances is respect to memory......heap/stack and potential for blow out
Once you are talking about globals and/or containers, basically everything is on the heap. And when you have pointers to instances, the instances themselves have to exist as well. (Of course, it is possible for several pointers to refer to the same instance, but before you cause that to happen, you should be sure that it's the behaviour you want.)
Local instances generally fit on the stack; they disappear at the end of their scope - such is the nature of the stack, and of 'local-ness' of variables. This is a good thing; you should always be trying to contain data to the tightest "scope" in which it needs to exist (as long as you aren't making things more complicated by doing so). Use arguments to functions (and return values) instead of communicating between them via globals, unless the data really needs to persist. ("Knowing" how to do these things properly comes with experience. :/)
Local instances generally fit on the stack; they disappear at the end of their scope - such is the nature of the stack, and of 'local-ness' of variables. This is a good thing; you should always be trying to contain data to the tightest "scope" in which it needs to exist (as long as you aren't making things more complicated by doing so). Use arguments to functions (and return values) instead of communicating between them via globals, unless the data really needs to persist. ("Knowing" how to do these things properly comes with experience. :/)
Author
if you write a game with unlimited say enemy sprites, do you store them with object pointers in a container as global or local...whats the best?
If you have them as local isnt that better for memory but you pass them around to sacrifice speed?
If you have them as local isnt that better for memory but you pass them around to sacrifice speed?
Judging from your replies, it might be a good idea to focus more on writing clean, flexible code for a while before facing the many confusions that pre-mature optimization presents.
Local variables are generally preferred to global variables because designing your programs around them typically makes it easier to extend/modify your code to create more advanced features, while simultaneously simplifying the complexity of the debugging process (variables are only allowed to be modified in places that can be found by tracing function calls). Almost any performance difference between global and local variables is going to become negligible if references to variables are passed when the situation calls for them.
Local variables are generally preferred to global variables because designing your programs around them typically makes it easier to extend/modify your code to create more advanced features, while simultaneously simplifying the complexity of the debugging process (variables are only allowed to be modified in places that can be found by tracing function calls). Almost any performance difference between global and local variables is going to become negligible if references to variables are passed when the situation calls for them.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
