Polymorphism

[dandymcgee]

I always forget you can treat derived class objects as if they were their parent's type

Haha, isn't that the basis of polymorphism?

Like I said, I've never used it.

[vargonian]

I can relate to what dandy was saying. One of the problems when you're waist-deep in programming books is that you learn all the concepts (the "what", if you will) but you don't really learn the "why" aside from contrived examples. I knew all about inheritance and polymorphism years before I ever really understand why it was useful. It's useless without context.

Here's a really simple, common example from a game development perspective. Let's say that at every frame, you iterate over all your objects in the game and update them (which is very common). Here's some code in pseudo-C# for an example:

Code: Select all

Game.Update()
{
  for (int i = 0; i < gameObjects.Count; i++)
  {
     gameObjects[i].Update();
  }
}

Let's say each game object is of a base type GameObject. Well, clearly you'll want to update a "building" in a different way than a "player" or an "enemy". In the player's Update function, you might check for user input. In the enemy's update, you might check to see if they're close to a Player, in which case they should attack. It's a simple example, but it's relevant. This is much easier than having separate classes for each type of object in the game, which don't relate to each other in any way. The alternative would be something like:

Code: Select all

for (int i = 0; i < players.Count; i++)
{
  players[i].Update();
}

for (int i = 0; i < enemies.Count; i++)
{
  enemies[i].Update();
}

for (int i = 0; i < buildings.Count; i++)
{
  buildings[i].Update();
}

But I should mention, the more you work with inheritance, the more value you'll see in using interfaces (in the case of C#) instead of inheritance whenever possible. Instead of deep inheritance hierarchies (e.g. GameObject<-MoveableObject<-Enemy<-Spider), you'll want objects that have "attached" behaviors via interfaces (or abstract base classes in C++ I would presume). Otherwise you get into situations in which you have trouble classifying objects because they could fit into two distinct branches of the inheritance tree. So instead you could have:

class Spider : IMoveable, ICollidable
{
...
}

class Player : IInputReceiver, IMoveable, ICollidable
{
...
}

class Building : ICollidable
{
...
}

This is a pretty "flat" hierarchy; the alternative would require a lot of repeated code and much more headache. Anyway, that's it for now. :P

[dandymcgee]

Thanks for that excellent (and to-the-point) example vargonian.
I've read about many similar concepts, but again haven't yet had the chance to implement anything.
I'm sure your post will help many newbies looking into polymorphism in the future.

[eatcomics]

You know... I must be getting better at this programming stuff, cause I actually understand everything you guys say now...
I remember back in the day when I had to google every other word when you guys were talkin abou this stuff

but anyways good topic, quite informative

[Bakkon]

Let's say that at every frame, you iterate over all your objects in the game and update them (which is very common).

We had a thread a little while back discussing why using an actual iterator is faster than using the vector/list index.

Code: Select all

for(vector<Object*>::iterator Iter = ObjectList.begin(); Iter != ObjectList.end(); ++Iter)
{
	(*Iter)->OnUpdate(deltaTime);
}

Also, make sure you're not pushing anything onto that list while iterating through it. That caused me a lot of headaches a few months ago.

[programmerinprogress]

Also make sure you're incrementing the iterator too, I implemented a form of linear search (soon to be replaced with a more efficient binary search once I figure it out) and I missed off the final part of the for statement out of pure ignorance, thinking that the iterator might somehow increment itself, like it was some magical data type which ignores all of the laws of programming

It crashed very badly as it clearly wasn't working for fairly obvious reasons now.

[MarauderIIC]

On the topic of vectors, you don't want to have a pointer that points to a solid object that is contained in a vector (vector<Object> a; Object* b = &a[0]), as when a vector is modified, it is allowed to move around in memory, thus making your pointer invalid. But you can always store pointers to objects in your vector, and then just copy those (vector<Object*> a; Object* b = a[0]). The pointers themselves might move, but the things they point to never will. I'm not sure if an iterator will "keep up" when the vector moves, or not -- I've never bothered to check.