Jump to content
  • Advertisement
Sign in to follow this  
stupid_programmer

Problem overriding functions

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

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();
}

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
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?


Nope, that is how it is commonly done, and you don't even need to use smart pointers (although it's good you are).

Share this post


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





Quote:

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> >.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
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> >.


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'.

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer

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'.


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?

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
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'.


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?

Share this post


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!