Let’s say we’re designing a video game. We have some sprites on the map and we want to call some method of the particular sprite at some particular position.
We are using one broadly-known C++ framework. It has an GraphicsItem class, and ALL our sprites are derived from it. Now, framework has a method to get a pointer of the GraphicsItem at any position on the map.
We’ve got two options now:
-
Cast from
GraphicsItem*to ourSprite*and callSprite‘s method. (We know for sure that all the graphics items on the map are instances ofSprite) -
Make some crazy things like Store pointers to
Spritein some container, iterate through them, compare address vales and get straightSprite*without casting.
The question is: what is the best practice in this case? I was always told to avoid typecasting because it means you’ve got design issues. But how can I change design to avoid typecasting here? And extra iteration over a container with a comparison is just… crazy…
3
If you know that everything in the scene is an instance of Sprite, then there should be no problem with typecasting. You can enable RTTI and use dynamic_cast<Sprite *> to be extra certain.
If there may be other GraphicsItem elements that are not instances of Sprite, then you could keep a set (perhaps QSet<GraphicsItem *>) which holds pointers to instances of Sprite that should appear in the scene. When you get a pointer from the scene, check to make sure it is in the set of sprites. This has the disadvantage of requiring that you maintain the set alongside maintenance of the scene itself.
It certainly would not be necessary to create a mapping container that maps a GraphicsItem * to a Sprite *.
3
An implicit cast to first base type and the reverse static cast to derived type when you are certain it is that type are exactly zero operations at runtime. You can’t beat that.
An implicit cast to non-first base type and the reverse static cast to derived type which has the base as non-first is a simple increment/decrement with a null pointer check. It has a cost, but it’s trivial and you won’t beat it with any lookup.
A dynamic cast reads the virtual method table pointer from the object, compares it to the one for the target class and if you are casting to what is still base of the actual type, follows some chain of pointers to check it. A bit higher cost, but it’s still unlikely you could beat it with any kind of lookup.
So, by all means cast. Use dynamic cast if you need to check the type (the base type has to have at least one virtual member for it to work, but it’s certainly the case here).
Yes, if you need to type-cast, it indeed usually means you have design issues. But in this case it is not your design issues. If the library provided a means to specify your own base class derived from the interface the library needs and returned that to you (via templating), you could do with virtual methods, possibly utilizing visitor patter from there. Alas it does not, so you have to cast. If you want, you could wrap the canvas in your own class that will do the casting and will also wrap the insertion to ensure that all items are indeed sprites.