Pixelate:Issue 14/Knowing what a class is without RTTI

From Allegro Wiki

Jump to: navigation, search
Knowing what a class is without RTTI
Original author: Adrian Danis (aka RamboBones)
some mail
Website:
zip:

Knowing what a class is without RTTI

RTTI (Run Time Type Information) is basically a system which allows you to check if a base class is inherited into a subclass at run time. For instance consider the possible code:


class CBaseClass
{
public:
	virtual void SomeFunc();
};

class CSubClass1 : public CBaseClass
{
public:
	virtual void SomeFunc();
	void Another ();
};

class CSubClass2 : public CBaseClass
{
public:
	virtual void SomeFunc();
	void Func();
};


void Foo(CBaseClass * BaseClass)
{
	BaseClass->SomeFunc();
	/*enable pseudo code if statements here*/
	if BaseClass is base class for object of type CSubClass1
		((CSubClass1*)BaseClass)->Another();
	else if BaseClass is base class for object of type CSubClass2
		((CSubClass2*)BaseClass)->Func();
	else
		do nothing
}

Now whilest this example is extremely basic and totally stupid it does pose the interesting question of, what if I want to know just what class I’m using? Now incase you didn’t know the Foo function can be solved in two ways, you can use the C++ dynamic_cast operator or you can have a virtual function in CBaseClass which returns the object type.

However this is clearly a hack for a solution as it doesn’t allow for very nice Object Oriented programming, after all isn’t the whole point of using classes, inheritance and virtual functions to get around exactly what you’re now trying to do?

I experienced this problem not long ago whilst trying to make a clone of Heartlight, which is very similar to another game called Supaplex. Now the game is one of those 2D puzzle games made of grenades, boulders, walls, grass, hearts and exits. Boulder hits you on the head, you die, grenade lands on a hard surface it explodes. Quite naturally I whipped up a base class for all the game objects, created another base class for ‘heavy’ objects and went from there. Part way through doing this I noticed that I had a bit of a problem, I only wanted boulders to fall off certain actors but not others, and balloons had to effect some ‘heavy’ objects certain ways but not others and so on and so on.

The first answer to this question is of course RTTI, which surprisingly I see in some Object Oriented programming articles and not to mention beginners do this a fair bit. But my answer to this is a lot simpler, simply think about WHY you want to know what the derived class is. So I stopped and did this and so along came a value saying whether other objects would fall of it, and how hard the object was etc. So there I had it, I’d solved my problem of needing to know what the sub class was.

But wait a minute, isn’t that kind of obvious? Well yes it is. But this is still a rather simple example and I was able to just ‘slot’ these extra values in with no trouble. Sadly however a lot of people will simply take the shortcut and put just one dynamic_cast in as it’s ‘just a one of’.

Frequently doing a bit of RTTI may seem a lot easier than thinking over a more general solution but in the long run RTTI can make your code less expandable and can introduce some painful errors as well as bogging your code down if done to much.

Well that's it. Nice and simple. If you've got any questions, comments or just want to say something to me then send me an e-mail

Personal tools