   Game Design
  I am running into a problem with how I designed GameObjects:http://pastebin.com/adiMwTTeMy C++ error is:rabbit.cpp: In member function `virtual void Rabbit::update()':rabbit.cpp:23: error: 'class GameObject' has no member named 'age'I understand the problem (I believe) but I am not sure if I should cast the GameObject and specifically grab the age, or if the cast is a warning that my design is flawed.- - As an aside, if I keep this design I have to (in each Rabbit's update method) cycle through the GameObject vector and find the location of that object.  You can see I do it in the commented code where (*i) == this.  Is this correct?- -Any help would be appreciated!   
  I guess you just need to ask yourself what your vector really contains. Its not really clear what your design intention is such that every GameObject contains a vector of more GameObjects.If every GameObject has an age, then put the age value inside of the GameObject class.If every item in your vector is guaranteed to be a Rabbit (or derivative), then you can either cast the iterator, or change it to a vector of Rabbits instead of a vector of GameObjectsIf GameObjects don't necessarily have an age, and your vector does not necessarily only contain rabbits, then why are you asking for the age of a gameobject?These are the kinds of things you need to think about.   ;  Nevermind, I understand now.  I will store the pointers to GameObjects and their children in the vector instead.   ;Sorry, I understand (specifically the third one).  I realized I don't require the age (unless from the class I'm currently inside, which I know has it).My question then is if I have the iterator to a GameObject, how do I cast that to a Rabbit or a Rabbit* in C++?OR... how do I check the type of the object in the GameObject vector, or are they all cast upwards to a GameObject when I place them inside?use reinterpret_cast<>(), just be careful, if you can avoid having to cast things, it's safer to do so.   ;  Thanks, I used static_cast and it seems to work.On a similar note, is it incorrect for me to think that each GameObject requires a pointer to the GameObject* vector?Will the address of this vector change as I add GameObject*'s to it in the main loop?Will problems occur if I create a GameObject inside another GameObject's update call and push_back the address of the new GameObject to the vector?   ;Thanks, I used static_cast and it seems to work.On a similar note, is it incorrect for me to think that each GameObject requires a pointer to the GameObject* vector?Will the address of this vector change as I add GameObject*'s to it in the main loop?Will problems occur if I create a GameObject inside another GameObject's update call and push_back the address of the new GameObject to the vector?storing pointers in a vector is usually a bad idea, as the vector can rearranged memory when it re sizes it's self. std::list would be a better/safer solution to store pointers.   ;  Agh, thank you! ;  Another follow up question!I have my main loop iterating through my list calling update on each GameObject.  However, sometimes a GameObject (in its update function) will be forced to erase itself from the list.  When that happens it invalidates the main loop's iterator, forcing a segmentation fault.  What's the best way to recalculate or notify my main loop's iterator that the list has changed?EDIT: I could return the iterator that erase returns, but are there other ways?   ;Another follow up question!I have my main loop iterating through my list calling update on each GameObject.  However, sometimes a GameObject (in its update function) will be forced to erase itself from the list.  When that happens it invalidates the main loop's iterator, forcing a segmentation fault.  What's the best way to recalculate or notify my main loop's iterator that the list has changed?EDIT: I could return the iterator that erase returns, but are there other ways?don't let objects erase themselves... it doesn't make sense. The code that manages the objects should erase the object. Either by returning a code from the update or by specifically sking the object if it should be erased. Then the manager should erase it. Atleast that's how I've always thought of it. I mean if an object can erase it self, it should be able to manage itself aswell.   ;Another follow up question!I have my main loop iterating through my list calling update on each GameObject.  However, sometimes a GameObject (in its update function) will be forced to erase itself from the list.  When that happens it invalidates the main loop's iterator, forcing a segmentation fault.  What's the best way to recalculate or notify my main loop's iterator that the list has changed?EDIT: I could return the iterator that erase returns, but are there other ways?I'd suggest something like an object manager class.  If an object needs to be deleted, you could fire a callback to the gameloop to drop a pointer to the current object into, say, a list withing the manager.  At the end of the loop, have the object manager process the list of garbage.   