Fast dynamic casting progress

Question

A little while ago, I found that very interesting paper on a very neat performance upgrade for dynamic_cast in C++: http://www2.research.att.com/~bs/fast_dynamic_casting.pdf.

Basically, it makes dynamic_cast in C++ way faster than the traditional research in inheritance tree. As stated in the paper, the method provides for a fast, constant-time dynamic casting algorithm.

This paper was published in 2005. Now, I am wondering if the technique was ever implemented somewhere or if there are plans to implement it anywhere?

I don't know if any compilers use it, but I have seen it used in a couple of library based RTTI solutions. — Peter Alexander, Aug 26 '11 at 20:02
Since the "allocation" of the "type ID" is done during link time (see paper), how does a library can achieve that? Do you have an example? — Philippe Cayouette, Aug 29 '11 at 16:02
It's not exactly the same; the ID's are assigned via some other method, but they still use modulo to determine a valid cast. — Peter Alexander, Aug 29 '11 at 18:01

score 8 · Answer 1 · answered Aug 26 '11 at 20:23

I do not know what implementations various compilers use beside GCC (which isn't linear). However, it is important to stress that the paper does not necessarily propose a method that is always faster than existing implementations for all (or even common) usage. It proposes a general solution that is asymptotically better as inheritance hierarchies grow.

However, it is rarely a good design to have large inheritance hierarchies, as they tend to force the application to become monolithic and inflexible to change. Programs with flexible design tend to only have hierarchies mostly with 2 levels, an abstract base and an implementation of runtime polymorphic roles to support the Open/Closed Principle. In these cases, walking the inheritance graph can be as simple as a single pointer dereference and compare, which can be faster than the index-sum-then-dereference-then-compare presented by Gibbs and Stroustrup.

Also, it is important to stress that it is never necessary to write a program that uses dynamic_cast unless your own business rules require it. The use of dynamic_cast is always an indication that polymorphism is not being properly used and reuse is being compromised. If you need a behavior based on casting up a hierarchy, adding a virtual method gives the clean solution. If you have a code section that does dynamic_cast-checks on types, that section of code will never "close" (in the meaning of the Open/Closed Principle), and will need to be updated for every new type added to the system. A virtual dispatch, on the other hand, is added only on new types, allowing you to remain open to expansion and yet closing the behaviors operating on the base type.

So this is really a rather academic suggestion (equating to changing a map to a hash_map algorithmically) that shouldn't have real world effects if good design is followed. If business rules forbid good design (some shops may have code barriers or code ownership issues where you cannot change existing architectures the way they need to be, nor do they allow adaptors to be built as would commonly be used for 3rd party libraries), then it is best not to make the decision on which compiler to use based on what algorithm is implemented. As always, if performance is key and you have to use a feature like dynamic_cast, profile your code. It is possible (and likely in many cases) that the tree-walking implementation is faster in practice.

See also the standards committee's review of implementations, including dynamic_cast and a well-known look at c++ in embedded environments and good use (which mentions Gibbs and Stroustrup in passing).

I am not a fan at all of dynamic_cast, but there are situations (usually due to 3rd party lib usage or language "hacks") where it is required. It is not the first time I read that dynamic_cast are sign of a bad design and that the same behavior could have been done otherwise, but I would very like to have a "proof" of that statement or at least some pointers... — Philippe Cayouette, Aug 29 '11 at 16:00
Dynamic cast provides access to a convertible type and a branch point for conditioned execution. The standard proof shows that a virtual dispatch provides the same features, so any "if (dynamic_cast<...>(...))" call may be converted to virtual dispatch by simply implementing the behavior in a virtual function. An extended proof usually points out that 3rd party libraries can be used similarly by providing wrapper classes for the hierarchy, with the intended behavior. That transformation shows that access to implementation is not required. — ex0du5, Sep 07 '11 at 23:20

Fast dynamic casting progress

1 Answers1