[Non leadwerks C++] Cons of using dynamic_cast?

[Guppy]

(this is a bit long winded - you can just skip to the Question bit if you like)

 

I'm currently writing an even system to wrap around ( among other things ) the Leadwerks input, this dispatches events that follows this design

 

 

 

Now the event manger dispatches them as Event* but some listeners may want to make use of the more specialized version so it needs to know if it is capable of that before attempting a downcast as the true type is not known at compile time.

 

There are several approaches to solve this;

 

1) give event a "virtual std::string getEventClass()=0;" and compare to that

The drawback here are string comparison ( which you could solve with hashing ) and inheritance ( a mouseEvent is still UI event but will fail the check )

 

2) A variation of the above where each class must push a hash of their class name onto a stack, and the stack is then checked.

This works but is somewhat cumbersome as anyone creating a new event class must remember to push the class name onto the stack or risk breaking the chain.

 

3) use dynamic_cast

this was my first idea, using the code below;

 

 template <class cmpType>
 bool isType(const cmpType* src){
	 return dynamic_cast<const cmpType*>(this) != 0;
 }

 

It works but leaves a lot to be desired for readability and anoyingly you need to pass an instance of what your trying to compare to rather than just a class. So I took to the web trying to see if anyone had solved the contract ( / acyclic visitor / reflective visitor ) pattern in C++. What I found was a lot of people saying the sky would fall if one were to use dynamic_cast - but nobody offered an opinion as to why.

 

 

Question:

 

Why is dynamic_cast evil?

[Rick]

Not sure why it's evil (if there is no real answer then it's probably just purists being purists in some fashion).

 

On events in C++ have you seen the way I handle events (it's not my method, I learned it a long time ago and just use it often)

 

http://www.leadwerks.com/werkspace/files/file/367-c-event/

 

It allows easy hookup to C++ methods to be called when the event is raised. You can chain them as well (more than 1 class method called when the event is raised). What I normally do then is take a .NET approach to events and make them have 2 parameters. A "sender" the UI element, and an EventArg. Different events would have different EventArg like MouseEventArgs (that has x, y, button state, etc) and you would use that for mouse events like MouseUp, MouseDown, MouseMove, etc.

 

I find this very handy as I can sort of just mimic the .NET framework in terms of UI events.

 

Just a thought.

[shadmar]

It's just theoretical nerd babble of the end of days with casting, if works, just cast it

[Josh]

The Leadwerks Object class has a GetClass() function that returns an integer identifying a constant for the class. These are equal to static constants in the Object class like Object::ModelClass, Object::TextureClass, etc. That might be a good approach for you.

 

You might also consider just making an even class that has everything:

class Event
{
int id;
int x,y;
int data; //keycode, mouse button, etc.
};