In C++, is a "public unsigned int type" in base class, a faster alternative to dynamic_cast?

Question

In C++, "dynamic_cast" being slow is a known fact. I thought of following simple way of knowing the type of an object in a hierarchy. Could someone please explain if this could be slower than dynamic_cast? And if not, then why isn't it a common practice, given that speed is the worst drawback of C++ over C?

struct Base {
  unsigned m_type;
  Base(unsigned type): m_type(type) {}
  Base(): m_type(0) {}
};
struct Derived1: Base {
  Derived1(): Base(1) {}
  Derived1(int type): Base(type) {}
};
struct Derived2: Base {
  Derived2(): Base(2) {}
};
struct Derived3: Derived1 {
  Derived3(): Derived1(3) {}
};
void my_func(Base * p) {
  if (p - > m_type == 0) {} 
  else if (p - > m_type == 1) {} 
  else if (p - > m_type == 2) {} 
  else if (p - > m_type == 3) {}
}

Answer 1

Could someone please explain if this could be slower than dynamic_cast?

It might well be slower than dynamic_cast'ing, when ...

• the compiler can figure out what you're dynamic_cast'ing from and thus avoid doing anything for the dynamic cast.
• the Base-derived objects are immutable, allowing for all sorts of optimization, while your classes contain a mutable type variable.
• you have a large and complex hierarchy of types, so you have lots of comparisons.

plus, have you actually checked to see how slow dynamic_cast is relative to other things you might be doing?

Why isn't it a common practice [?]

1. Because it makes the code more complicated, adds unintended potential semantics and features, and goes against the grain of the language's abstraction mechanisms.
2. Because it necessitates the base class knowing about all of its derived classes (or otherwise you essentially end up reimplementing dynamic casting).
3. Because it makes some parts of the class-specific code local to the class definition, and other parts of the class-specific code local to the base class.

... given that speed is the worst drawback of C++ over C?

It isn't. It is quite possible (and common) these days to write better-performing code in C++ than the semantic equivalent in C.

But that should not matter anyway, since you have no business doing dynamic-cast'ing in performance-critical code; that's a design flaw, as @NathanOliver suggests in a comment.

Answer 2

In C++, "dynamic_cast" being slow is a known fact.

It was a known fact back thirty years ago (when I first started using C++ compilers) 1989/1990 (back then I used whatever compiler was installed by default on the sun workstations). BUT that is no longer true for modern compilers.

I remember downloading g++ (2.4 I think; approx 1996-1998) to look at what was happening (see below). The compiler (g++) would traverse the class hierarchy and at each level do a class name string comparison as it searched for the correct type record. This was done as each compilation unit potentially had its own unique set of type record (so you could not simply compare pointers).

And if not, then why isn't it a common practice

As a result a lot of people actually did write their own versions of dynamic cast to improve speed (but then again people were still trying to work out how to write good C++ in those days and most code was written like C so performance was probably not the fault of dynamic_cast). But the couple of implementations I saw were exceedingly brittle and subject to a lot of bugs. Which is why I was looked at how g++ worked. By this time (1998) the self written dynamic cast my company used was showing its age and I ripped it out to use the compiler version (no measurable performance change, but lots of mysterious bugs disappeared).

Thankfully this was fixed a long time ago. Before the end of the last century (I can not give you an exact date). But definitely prior to g++ 3.0.

I thought of following simple way of knowing the type of an object in a hierarchy.

You have identified the class by a number. This is not the same as a cast. You still need to convert the pointer to the correct location.

Could someone please explain if this could be slower than dynamic_cast?

I would suspect that you would have a hard time writing a version faster than the current implementation. Especially taking into account all the special corner cases with virtual inheritance and such. To be honest I doubt you could do a faster one for even a simple hierarchy like you show. The compiler has 30 years of optimization tricks applied to it. These tricks are applied at compile time your result is run time.

given that speed is the worst drawback of C++ over C?

I find this hard to believe. Do you have a citation?