Practical use of dynamic_cast?

Question

I have a pretty simple question about the dynamic_cast operator. I know this is used for run time type identification, i.e., to know about the object type at run time. But from your programming experience, can you please give a real scenario where you had to use this operator? What were the difficulties without using it?

score 51 · Accepted Answer · edited Aug 01 '12 at 19:18

51

Toy example

Noah's ark shall function as a container for different types of animals. As the ark itself is not concerned about the difference between monkeys, penguins, and mosquitoes, you define a class Animal, derive the classes Monkey, Penguin, and Mosquito from it, and store each of them as an Animal in the ark.

Once the flood is over, Noah wants to distribute animals across earth to the places where they belong and hence needs additional knowledge about the generic animals stored in his ark. As one example, he can now try to dynamic_cast<> each animal to a Penguin in order to figure out which of the animals are penguins to be released in the Antarctic and which are not.

Real life example

We implemented an event monitoring framework, where an application would store runtime-generated events in a list. Event monitors would go through this list and examine those specific events they were interested in. Event types were OS-level things such as SYSCALL, FUNCTIONCALL, and INTERRUPT.

Here, we stored all our specific events in a generic list of Event instances. Monitors would then iterate over this list and dynamic_cast<> the events they saw to those types they were interested in. All others (those that raise an exception) are ignored.

Question: Why can't you have a separate list for each event type?

Answer: You can do this, but it makes extending the system with new events as well as new monitors (aggregating multiple event types) harder, because everyone needs to be aware of the respective lists to check for.

edited Aug 01 '12 at 19:18

jk.

13,817
5
37
50

answered Aug 01 '12 at 13:18

BjoernD

4,720
27
32

1

This event monitoring was a really very practical example i could imagine clearly what is the importance of dynamic cast. thanks alot!!! – cexplorer Aug 01 '12 at 13:30
9

Did he build the [arch](http://en.wikipedia.org/wiki/Arch) after the [ark](http://en.wikipedia.org/wiki/Noah%27s_Ark)? – Daniel Aug 01 '12 at 14:51
1

Ooops. Sometimes being non-native hurts. ;) – BjoernD Aug 01 '12 at 16:24
No biggie. I thought perhaps he went on to pursue a career in architecture. :) – Daniel Aug 01 '12 at 19:09
1

I strongly disagree with example 2: as soon as you add more complex monitors, you run the risk of writing strings of dynamic casts inside the monitor logic. This is best handled with the visitor pattern (this is best handled with pattern matching; and in OOP languages, pattern matching is achieved via the visitor pattern). There are ways to be able to add new events types with no pain (just write default implementations in the base visitor class which delegate to the base class). – Alexandre C. Aug 02 '12 at 10:23
But at some point during your call to the visit() function, you will still need to figure out what kind of object you are looking at? – BjoernD Aug 02 '12 at 10:24
@BjoernD: this is the job of the accept() function to dispatch to the right visit() of the visitor. In the visit(), you have an object of the right type. – Alexandre C. Aug 02 '12 at 10:26
@BjoernD: The accept function calls `visitor->visit(this)` and is reimplemented for each derived class of the hierarchy. Note that `this` has a different type each time, and thus calls a different overload of `visitor::visit`. – Alexandre C. Aug 03 '12 at 10:48
dynamic_cast is not meant as a replacement to virtual functions. You could easily define a base class virtual function GetAnimalType and have it return a GUID if you don't want to write an enum and be dynamically extensible with unknown event handlers. – Dimitrios Staikos Aug 08 '12 at 06:45
Dimitris Staikos: Sure. But then you have the issue of having to manage GUIDs across your program. Or even across modules that come from different sources where you only have the binary versions available. In these cases, dynamic_cast could be the nicer way. – BjoernD Aug 08 '12 at 06:56

score 11 · Answer 2 · answered Aug 01 '12 at 13:31

11

A typical use case is the visitor pattern:

struct Element
{
    virtual ~Element() { }

    void accept(Visitor & v)
    {
        v.visit(this);
    }
};

struct Visitor
{
    virtual void visit(Element * e) = 0;
    virtual ~Visitor() { }
};


struct RedElement : Element { };
struct BlueElement : Element { };
struct FifthElement : Element { };


struct MyVisitor : Visitor
{
    virtual void visit(Element * e)
    {
        if (RedElement * p = dynamic_cast<RedElement*>(e))
        {
             // do things specific to Red
        }
        else if (BlueElement * p = dynamic_cast<BlueElement*>(e))
        {
             // do things specific to Blue
        }
        else
        {
             // error: visitor doesn't know what to do with this element
        }
    }
};

Now if you have some Element & e;, you can make MyVisitor v; and say e.accept(v).

The key design feature is that if you modify your Element hierarchy, you only have to edit your visitors. The pattern is still fairly complex, and only recommended if you have a very stable class hierarchy of Elements.

answered Aug 01 '12 at 13:31

Kerrek SB

464,522
92
875
1,084

8

Oops, by overloading the `visit` method to accept the various `Element` derivatives, you can avoid the need for `dynamic_cast` altogether. I think that's the main benefit of the Visitor pattern (`Element` objects reveal their concrete type to their visitors). – Andrew Durward Aug 01 '12 at 13:37
2

@AndrewDurward: Overload resolution happens statically. Dynamic cast happens dynamically. I don't think they solve the same problem. Your approach would need to add code to every class derived from `Element`, non? Anyway, there are certainly other ways of implementing a visitor, but it's a good example of where dynamic casts are useful. – Kerrek SB Aug 01 '12 at 13:39
4

Right, which is why `accept` is usually implemented in each derived `Element` class (or with CRTP). That way the type of `this` is known at compile-time. – Andrew Durward Aug 01 '12 at 13:40
1

+1 because it is less coupled design compared to one uses intermediate dispatch level inside Elements (as in Java example in the Wikipedia article http://en.wikipedia.org/wiki/Visitor_pattern). The pros: 1) Element doesn't need to know about visitors at all. 2) visitor dosn't need to know about elements that are out of interest of the given visitor. – user396672 Aug 01 '12 at 13:48
@AndrewDurward Would you really prefer the complexity of CRTP over this if you weren't on an embedded system with very little resources? I think the simplicity wins in that trade off. – John Humphreys Aug 01 '12 at 13:52
5

@w00te Maybe, maybe not. But I would definitely avoid repeating the `dynamic_cast` switch statement in each Visitor if at all possible (DRY). My main point here is that I disagree with the statement that "A typical use case [of dynamic cast] is the visitor pattern." – Andrew Durward Aug 01 '12 at 13:59

Linuxios · Answer 3 · 2012-08-01T14:08:36.253

3

Imagine this situation: You have a C++ program that reads and displays HTML. You have a base class HTMLElement which has a pure virtual method displayOnScreen. You also have a function called renderHTMLToBitmap, which draws the HTML to a bitmap. If each HTMLElement has a vector<HTMLElement*> children;, you can just pass the HTMLElement representing the element <html>. But what if a few of the subclasses need special treatment, like <link> for adding CSS. You need a way to know if an element is a LinkElement so you can give it to the CSS functions. To find that out, you'd use dynamic_cast.

The problem with dynamic_cast and polymorphism in general is that it's not terribly efficient. When you add vtables into the mix, it only get's worse.

When you add virtual functions to a base class, when they are called, you end up actually going through quite a few layers of function pointers and memory areas. That will never be more efficient than something like the ASM call instruction.

Edit: In response to Andrew's comment bellow, here's a new approach: Instead of dynamic casting to the specific element type (LinkElement), instead you have another abstract subclass of HTMLElement called ActionElement that overrides displayOnScreen with a function that displays nothing, and creates a new pure virtual function: virtual void doAction() const = 0. The dynamic_cast is changed to test for ActionElement and just calls doAction(). You'd have the same kind of subclass for GraphicalElement with a virtual method displayOnScreen().

Edit 2: Here's what a "rendering" method might look like:

void render(HTMLElement root) {
  for(vector<HTLMElement*>::iterator i = root.children.begin(); i != root.children.end(); i++) {
    if(dynamic_cast<ActionElement*>(*i) != NULL) //Is an ActionElement
    {
      ActionElement* ae = dynamic_cast<ActionElement*>(*i);
      ae->doAction();
      render(ae);
    }
    else if(dynamic_cast<GraphicalElement*>(*i) != NULL) //Is a GraphicalElement
    {
       GraphicalElement* ge = dynamic_cast<GraphicalElement*>(*i);
       ge->displayToScreen();
       render(ge);
    }
    else
    {
      //Error
    }
  }
}

edited Aug 01 '12 at 14:08

answered Aug 01 '12 at 13:16

Linuxios

34,849
13
91
116

3

C++ polymorphism and vtables is generally more efficient than other ways of solving similar problems. This is rarely a concern these days, unless you're targeting an embedded platform or something. – aschepler Aug 01 '12 at 13:22
Thank you so much Linuxios!! that was a really very nice example! I understand now whenever we need to use some generic class element/variable having various pointers to its derived ones and could be cases wherein we need to treat some derived ones specially then we use dynamic cast. Thanks alot! Kudos to both Linuxios and BjoernD! – cexplorer Aug 01 '12 at 13:29
1

In my opinion, the example you've presented is not a good use of `dynamic_cast`. A method that must test for the concrete type of an object doesn't adhere to the [Open-Closed Principle](http://www.objectmentor.com/resources/articles/ocp.pdf). What happens if you add a new sub-type to your hierarchy? You must then find all the places in your code where you want to apply special behaviour. – Andrew Durward Aug 01 '12 at 13:33
@aschepler: I know, but comparatively to basic function and method calls, it is much less efficient. – Linuxios Aug 01 '12 at 13:40
@AndrewDurward: True and agreed. But what other use does `dynamic_cast` have? It's purpose is to test a base class pointer for if it points to a child of the specified type. That implies needing to add more checks for new types. And yes, if I had to write an HTML parser, I would have used a data structure to map tags to rendering functions, but that doesn't stop this being valid. – Linuxios Aug 01 '12 at 13:42
I'd say that's an improvement but there's still a design problem in my opinion. If your container requires that the objects have an interface with a `doAction` method, then why is it possible to store objects without such a method? – Andrew Durward Aug 01 '12 at 13:52
What's wrong with `element->render()`? Let the derived classes figure out what they want to do. – Andrew Durward Aug 01 '12 at 14:26
@AndrewDurward: Because this prevents a class that by good design shouldn't even have a `render()` method from having one. ` – Linuxios Aug 01 '12 at 14:28

Alexandre C. · Answer 4 · 2012-08-02T10:43:44.910

Operator dynamic_cast solves the same problem as dynamic dispatch (virtual functions, visitor pattern, etc): it allows you to perform different actions based on the runtime type of an object.

However, you should always prefer dynamic dispatch, except perhaps when the number of dynamic_cast you'd need will never grow.

Eg. you should never do:

if (auto v = dynamic_cast<Dog*>(animal)) { ... }
else if (auto v = dynamic_cast<Cat*>(animal)) { ... }
...

for maintainability and performance reasons, but you can do eg.

for (MenuItem* item: items)
{
    if (auto submenu = dynamic_cast<Submenu*>(item))
    {
        auto items = submenu->items();
        draw(context, items, position); // Recursion
        ...
    }

    else
    {
        item->draw_icon();
        item->setup_accelerator();
        ...
    }
}

which I've found quite useful in this exact situation: you have one very particular subhierarchy that must be handled separately, this is where dynamic_cast shines. But real world examples are quite rare (the menu example is something I had to deal with).

score 1 · Answer 5 · answered Aug 08 '12 at 06:58

dynamic_cast is not intended as an alternative to virtual functions.
dynamic_cast has a non-trivial performance overhead (or so I think) since the whole class hierarchy has to be walked through.
dynamic_cast is similar to the 'is' operator of C# and the QueryInterface of good old COM.

So far I have found one real use of dynamic_cast:
(*) You have multiple inheritance and to locate the target of the cast the compiler has to walk the class hierarchy up and down to locate the target (or down and up if you prefer). This means that the target of the cast is in a parallel branch in relation to where the source of the cast is in the hierarchy. I think there is NO other way to do such a cast.

In all other cases, you just use some base class virtual to tell you what type of object you have and ONLY THEN you dynamic_cast it to the target class so you can use some of it's non-virtual functionality. Ideally there should be no non-virtual functionality, but what the heck, we live in the real world.

Doing things like:

    if (v = dynamic_cast(...)){} else if (v = dynamic_cast(...)){} else if ...

is a performance waste.

score 0 · Answer 6 · answered Aug 01 '12 at 13:21

0

Casting should be avoided when possible, because it is basically saying to the compiler that you know better and it is usually a sign of some weaker design decission.

However, you might come in situations where the abstraction level was a bit too high for 1 or 2 sub-classes, where you have the choice to change your design or solve it by checking the subclass with dynamic_cast and handle it in a seperate branch. The trade-of is between adding extra time and risk now against extra maintenance issues later.

answered Aug 01 '12 at 13:21

stefaanv

14,072
2
31
53

thanks stefaanv that was quite a different aspect you explained. – cexplorer Aug 01 '12 at 13:38
`dynamic_cast` is different than casting. It means that your asking the compiler for information you don't know that will let you do different things depending on specific subclasses in polymorphism. – Linuxios Aug 01 '12 at 13:44
1

@Linuxios: I disagree, it is still casting – stefaanv Aug 01 '12 at 13:58
@stefaanv: it's still casting, but it's not turning `int`s into `char`s and `long`s into `struct {short i1; short i2;}`s. It's more controlled. – Linuxios Aug 01 '12 at 14:11

John Humphreys · Answer 7 · 2012-08-01T13:28:01.463

In most situations where you are writing code in which you know the type of the entity you're working with, you just use static_cast as it's more efficient.

Situations where you need dynamic cast typically arrive (in my experience) from lack of foresight in design - typically where the designer fails to provide an enumeration or id that allows you to determine the type later in the code.

For example, I've seen this situation in more than one project already:

You may use a factory where the internal logic decides which derived class the user wants rather than the user explicitly selecting one. That factory, in a perfect world, returns an enumeration which will help you identify the type of returned object, but if it doesn't you may need to test what type of object it gave you with a dynamic_cast.

Your follow-up question would obviously be: Why would you need to know the type of object that you're using in code using a factory?

In a perfect world, you wouldn't - the interface provided by the base class would be sufficient for managing all of the factories' returned objects to all required extents. People don't design perfectly though. For example, if your factory creates abstract connection objects, you may suddenly realize that you need to access the UseSSL flag on your socket connection object, but the factory base doesn't support that and it's not relevant to any of the other classes using the interface. So, maybe you would check to see if you're using that type of derived class in your logic, and cast/set the flag directly if you are.

It's ugly, but it's not a perfect world, and sometimes you don't have time to refactor an imperfect design fully in the real world under work pressure.

Hi W00te, the point you are saying is interesting.. Can you please explain how could we use static cast operator in the event monitoring example given by BjoernD above. — cexplorer, Aug 01 '12 at 13:43
@cexplorer: It would require the use of some sort of `type` or `id` field of the base class that would be checked with `switch` and acted on with `dynamic_cast`. To me, it just seems like reimplementing what the compiler has already done: Make a type field and query it to know whether you can cast to a type. And the compiler probably does it a lot more efficiently than you could in code. — Linuxios, Aug 01 '12 at 14:26

Don Wakefield · Answer 8 · 2012-08-13T17:46:04.573

Contract Programming and RTTI shows how you can use dynamic_cast to allow objects to advertise what interfaces they implement. We used it in my shop to replace a rather opaque metaobject system. Now we can clearly describe the functionality of objects, even if the objects are introduced by a new module several weeks/months after the platform was 'baked' (though of course the contracts need to have been decided on up front).

score 0 · Answer 9 · answered Aug 08 '12 at 22:51

The dynamic_cast operator is very useful to me. I especially use it with the Observer pattern for event management:

#include <vector>
#include <iostream>
using namespace std;

class Subject; class Observer; class Event;

class Event { public: virtual ~Event() {}; };
class Observer { public: virtual void onEvent(Subject& s, const Event& e) = 0; };
class Subject {
    private:
        vector<Observer*> m_obs;
    public:
        void attach(Observer& obs) { m_obs.push_back(& obs); }
    public:
        void notifyEvent(const Event& evt) {
            for (vector<Observer*>::iterator it = m_obs.begin(); it != m_obs.end(); it++) {
                if (Observer* const obs = *it) {
                    obs->onEvent(*this, evt);
                }
            }
        }
};

// Define a model with events that contain data.
class MyModel : public Subject {
    public:
        class Evt1 : public Event { public: int a; string s; };
        class Evt2 : public Event { public: float f; };
};
// Define a first service that processes both events with their data.
class MyService1 : public Observer {
    public:
        virtual void onEvent(Subject& s, const Event& e) {
            if (const MyModel::Evt1* const e1 = dynamic_cast<const MyModel::Evt1*>(& e)) {
                cout << "Service1 - event Evt1 received: a = " << e1->a << ", s = " << e1->s << endl;
            }
            if (const MyModel::Evt2* const e2 = dynamic_cast<const MyModel::Evt2*>(& e)) {
                cout << "Service1 - event Evt2 received: f = " << e2->f << endl;
            }
        }
};
// Define a second service that only deals with the second event.
class MyService2 : public Observer {
    public:
        virtual void onEvent(Subject& s, const Event& e) {
            // Nothing to do with Evt1 in Service2
            if (const MyModel::Evt2* const e2 = dynamic_cast<const MyModel::Evt2*>(& e)) {
                cout << "Service2 - event Evt2 received: f = " << e2->f << endl;
            }
        }
};

int main(void) {
    MyModel m; MyService1 s1; MyService2 s2;
    m.attach(s1); m.attach(s2);

    MyModel::Evt1 e1; e1.a = 2; e1.s = "two"; m.notifyEvent(e1);
    MyModel::Evt2 e2; e2.f = .2f; m.notifyEvent(e2);
}

Practical use of dynamic_cast?

9 Answers9