   Problem overriding functions
  Here is the base class:class CEntity{public:CEntity(void);~CEntity(void) {};virtual void Create(...);virtual void Render(...);virtual void Update(...);And child class:class CParticle : public CEntity{public:CParticle(void);~CParticle(void) {};void Create(...);void Update(...);void Render(...);To keep a list of game objects I'm using a vector of CEntity.  I create a particle to push_back into the CEntity vector and then loop through the vector to render.  But instead of calling the particle render its calling the base render.  Is there something special that I have to do to be able to use the child function?Some of the other code:std::vector<CEntity> entities;CParticle particle;particle.Create();entities.push_back(particle);Then to render:for (size_t i=0; i<entities.size(); i++){entities.Update();entities.Render();}
  Your container contains instances of CEntity, so calling their virtual functions has no reason to call anything else than the CEntity version of the functions.Also, entities.push_back(particle); is actually a misstatement. This does not push particle at the end of the container, it instead creates a new instance of CEntity at the end of your container by using its copy constructor and the object you provided. This is known as slicing and should be avoided.If you wish to have a polymorphic vector, use a vector of smart pointers or a boost::ptr_vector instead.;  Doing a quick Google on smart pointers I seen a way that I can do my vector like this:  std::vector<CEntity *> entities;.  Now when I call render its actually calling the particle render function.  Is there anything bad about doing it this way?   ;Quote:Original post by stupid_programmerDoing a quick Google on smart pointers I seen a way that I can do my vector like this:  std::vector<CEntity *> entities;.  Now when I call render its actually calling the particle render function.  Is there anything bad about doing it this way?Nope, that is how it is commonly done, and you don't even need to use smart pointers (although it's good you are).;  In general, polymorphic base classes should have:Private copy constructor and operator= to avoid object slicing (this is often accomplished by privately inheriting from boost::noncopyable). This would have caught your error at compile time.A virtual destructorQuote:Doing a quick Google on smart pointers I seen a way that I can do my vector like this: std::vector<CEntity *>. Is there anything bad about doing it this way?Yes - you are responsible for memory management of the instances in the vector, which is a non-trivial task. Prefer boost::ptr_vector<CEntity> or std::vector<boost::shared_ptr<CEntity> >.   ;Quote:Original post by NitageYes - you are responsible for memory management of the instances in the vector, which is a non-trivial task. Prefer boost::ptr_vector<CEntity> or std::vector<boost::shared_ptr<CEntity> >.Maybe I'm missing something but I thought all I had to do was 'delete' the object in the vector when I was done with it.  At the end of my game loop the entity manager loops through the object list and removes any entities that aren't 'alive'.;Quote:Original post by stupid_programmerMaybe I'm missing something but I thought all I had to do was 'delete' the object in the vector when I was done with it.  At the end of my game loop the entity manager loops through the object list and removes any entities that aren't 'alive'.You need to do this in destructor, and you need to delete *all* instances, not just dead ones.You also need to handle the case of entity manager being copied. Who retains the ownership? Do you clone the objects? Who will delete which one?   ;Quote:Original post by stupid_programmerMaybe I'm missing something but I thought all I had to do was 'delete' the object in the vector when I was done with it.  At the end of my game loop the entity manager loops through the object list and removes any entities that aren't 'alive'.Imagine: There are a bunch of gophers in your garden, and you need to protect your precious vegetable patch, so you'd like to just shoot them all so that you don't "leak" (er, ok...) gophers. But any given gopher will explode - for massive damage to the vegetable patch - if you shoot it more than once. Also, you don't see very well, so you have a bunch of spotters pointing out the gophers to you, but in some cases, several spotters are watching the same gopher.No problem, right?   ;  As of now I'm still using std::vector <CEntity *> as for my project I'm not concerned with maybe passing the vector to somebody else and I'm fairly sure I can delete everything when needed.  But I found something weird today, declaring a new CEntity in the push_back brackets doesn't seem to make it render in the loop when running the program regularly.  But if I run the program through F5 all four display.std::vector <CEntity *>objects;for (int i=0; i<4; i++)    objects.push_back(new CEntity(p_D3DDevice, model));Only one of the four will render yet .size() says there are four in the vector.  But like I said running it with F5 shows all but building either debug or release only the bottom shows.I'll download Boost tomorrow and give it a try but in the meantime in anybody had an idea on that one I'd like to hear it.   