Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. Cast from GraphicsItem* to our Sprite* and call Sprite's method. (We know for sure that all the graphics items on the map are instances of Sprite)

  2. Make some crazy things like Store pointers to Sprite in some container, iterate through them, compare address vales and get straight Sprite* 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...

share|improve this question
Do you mean QGraphicsItem *QGraphicsScene::itemAt()? If so, it helps to be specific when you can. –  Greg Hewgill Feb 26 '13 at 2:29
Yes, that's what I mean. I've tried to make the question more general. –  Kolyunya Feb 26 '13 at 2:31
add comment

2 Answers

up vote 4 down vote accepted

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

share|improve this answer
I don't think set is ever going to do anything faster than dynamic_cast, let alone a static_cast. –  Jan Hudec Feb 26 '13 at 9:44
unordered_set may well beat dynamic_cast, or a similar structure with a solid implementation. –  DeadMG Feb 26 '13 at 10:48
My suggestion to use a set was merely to provide an alternative to relying entirely on a dynamic_cast, in case the OP has some objection to using RTTI. –  Greg Hewgill Feb 26 '13 at 17:46
add comment

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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.