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?

Cauley

Answer 1

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.

Polyandrist

This event monitoring was a really very practical example i could imagine clearly what is the importance of dynamic cast. thanks alot!!! – Cauley

Did he build the arch after the ark? – Asthenic

Ooops. Sometimes being non-native hurts. ;) – Polyandrist

No biggie. I thought perhaps he went on to pursue a career in architecture. :) – Asthenic

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). – Ephraim

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? – Polyandrist

@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. – Ephraim

@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. – Ephraim

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. – Rotterdam

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. – Polyandrist

Answer 2

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.

Commodious

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). – Inactivate

@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. – Commodious

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. – Inactivate

+1 because it is less coupled design compared to one uses intermediate dispatch level inside Elements (as in Java example in the Wikipedia article 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. – Lip

@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. – Deduce

@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." – Inactivate

Answer 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
    }
  }
}

Dickie

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. – Cave

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! – Cauley

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. 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. – Inactivate

@aschepler: I know, but comparatively to basic function and method calls, it is much less efficient. – Dickie

@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. – Dickie

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? – Inactivate

What's wrong with element->render()? Let the derived classes figure out what they want to do. – Inactivate

@AndrewDurward: Because this prevents a class that by good design shouldn't even have a render() method from having one. <script> elements don't have a way to render, so why should they be forced to implement that method. It just doesn't make sense. Anyway, this is a case where dynamic_cast could be used, I do agree with you that just some virtual functions are easier in normal programing. – Dickie

Answer 4

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

Ephraim

Answer 5

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.

Rotterdam

Answer 6

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.

Amends

thanks stefaanv that was quite a different aspect you explained. – Cauley

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. – Dickie

@Linuxios: I disagree, it is still casting – Amends

@stefaanv: it's still casting, but it's not turning ints into chars and longs into struct {short i1; short i2;}s. It's more controlled. – Dickie

Answer 7

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.

Deduce

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. – Cauley

@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. – Dickie

Answer 8

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

Hernardo

Answer 9

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);
}

Rictus