Sign in to follow this  

global objects

This topic is 4688 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

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?

Share this post


Link to post
Share on other sites
The standard way is to use either an std::list or std::vector, e.g. :

// global
std::vector<Object*> _objVec;
// or
std::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 resized

The 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 number

However, perhaps you should consider encapsulate this array of Entities in a class of some sort.

Cheers.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

This topic is 4688 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.

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