Why is 'pure polymorphism' preferable over using RTTI?

An interface describes what one needs to know in order to interact in a given situation in code. Once you extend the interface with "your entire type hierarchy", your interface "surface area" becomes huge, which makes reasoning about it harder.

As an example, your "poke adjacent oranges" means that I, as a 3rd party, cannot emulate being an orange! You privately declared an orange type, then use RTTI to make your code behave special when interacting with that type. If I want to "be orange", I must be within your private garden.

Now everyone who couples with "orangeness" couples with your entire orange type, and implicitly with your entire private garden, instead of with a defined interface.

While at first glance this looks like a great way to extend the limited interface without having to change all clients (adding am_I_orange), what tends to happen instead is it ossifies the code base, and prevents further extension. The special orangeness becomes inherent to the functioning of the system, and prevents you from creating a "tangerine" replacement for orange that is implemented differently and maybe removes a dependency or solves some other problem elegantly.

This does mean your interface has to be sufficient to solve your problem. From that perspective, why do you need to only poke oranges, and if so why was orangeness unavailable in the interface? If you need some fuzzy set of tags that can be added ad-hoc, you could add that to your type:

class node_base {
  public:
    bool has_tag(tag_name);

This provides a similar massive broadening of your interface from narrowly specified to broad tag-based. Except instead of doing it through RTTI and implementation details (aka, "how are you implemented? With the orange type? Ok you pass."), it does so with something easily emulated through a completely different implementation.

This can even be extended to dynamic methods, if you need that. "Do you support being Foo'd with arguments Baz, Tom and Alice? Ok, Fooing you." In a big sense, this is less intrusive than a dynamic cast to get at the fact the other object is a type you know.

Now tangerine objects can have the orange tag and play along, while being implementation-decoupled.

It can still lead to a huge mess, but it is at least a mess of messages and data, not implementation hierarchies.

Abstraction is a game of decoupling and hiding irrelevancies. It makes code easier to reason about locally. RTTI is boring a hole straight through the abstraction into implementation details. This can make solving a problem easier, but it has the cost of locking you into one specific implementation really easily.

The most of the moral suasion against this or that feature are typicality originated from the observation that there are a umber of misconceived uses of that feature.

Where moralists fail is that they presume ALL the usages are misconceived, while in fact features exist for a reason.

They have what I used to call the "plumber complex": they think all taps are malfunctioning because all the taps they are called to repair are. The reality is that most taps work well: you simply don't call a plumber for them!

A crazy thing that can happen is when, to avoid using a given feature, programmers write a lot of boilerplate code actually privately re-implementing exactly that feature. (Have you ever met classes that don't use RTTI nor virtual calls, but have a value to track which actual derived type are they? That's no more than RTTI reinvention in disguise.)

There is a general way to think about polymorphism: IF(selection) CALL(something) WITH(parameters). (Sorry, but programming, when disregarding abstraction, is all about that)

The use of design-time (concepts) compile-time (template-deduction based), run-time (inheritance and virtual function-based) or data-driven (RTTI and switching) polymorphism, depends on how much of the decisions are known at each of the stages of the production and how variable they are at every context.

The idea is that:

the more you can anticipate, the better the chance of catching errors and avoid bugs affecting the end-user.

If everything is constant (including the data) you can do everything with template meta-programming. After compilation occurred on actualized constants, the entire program boils down to just a return statement that spits out the result.

If there are a number of cases that are all known at compile time, but you don't know about the actual data they have to act on, then compile-time polymorphism (mainly CRTP or similar) can be a solution.

If the selection of the cases depends on the data (not compile-time known values) and the switching is mono-dimensional (what to do can be reduced to one value only) then virtual function based dispatch (or in general "function pointer tables") is needed.

If the switching is multidimensional, since no native multiple runtime dispatch exist in C++, then you have to either:

• Reduce to one dimension by Goedelization: that's where virtual bases and multiple inheritance, with diamonds and stacked parallelograms are, but this requires the number of possible combination to be known and to be relatively small.
• Chain the dimensions one into the other (like in the composite-visitors pattern, but this requires all classes to be aware of their other siblings, thus it cannot "scale" out from the place it has been conceived)
• Dispatch calls based on multiple values. That's exactly what RTTI is for.

If not just the switching, but even the actions are not compile time known, then scripting & parsing is required: the data themselves must describe the action to be taken on them.

Now, since each of the cases I enumerated can be seen as a particular case of what follows it, you can solve every problem by abusing the bottom-most solution also for problems affordable with the top-most.

That's what moralization actually pushes to avoid. But that does not means that problems living in the bottom-most domains don't exist!

Bashing RTTI just to bash it, is like bashing goto just to bash it. Things for parrots, not programmers.

It looks kind of neat in a small example, but in real life you will soon end up with a long set of types that can poke each other, some of them perhaps only in one direction.

What about dark_orange_node, or black_and_orange_striped_node, or dotted_node? Can it have dots of different colors? What if most dots are orange, can it be poked then?

And each time you have to add a new rule, you will have to revisit all the poke_adjacent functions and add more if-statements.

As always, it is hard to create generic examples, I'll give you that.

But if I were to do this specific example, I would add a poke() member to all the classes and let some of them ignore the call (void poke() {}) if they are not interested.

Surely that would be even less expensive than comparing the typeids.

Some compilers don't use it / RTTI is not always enabled

I believe you have misunderstood such arguments.

There are a number of C++ coding places where RTTI is not to be used. Where compiler switches are used to forcibly disable RTTI. If you are coding within such a paradigm... then you almost certainly have already been informed of this restriction.

The problem therefore is with libraries. That is, if you're writing a library that depends on RTTI, then your library cannot be used by users who turn off RTTI. If you want your library to be used by those people, then it cannot use RTTI, even if your library also gets used by people who can use RTTI. Equally importantly, if you can't use RTTI, you have to shop around a little harder for libraries, since RTTI use is a deal-breaker for you.

It costs extra memory / Can be slow

There are many things you don't do in hot loops. You don't allocate memory. You don't go iterating through linked lists. And so forth. RTTI certainly can be another one of those "don't do this here" things.

However, consider all of your RTTI examples. In all cases, you have one or more objects of an indeterminate type, and you want to perform some operation on them which may not be possible for some of them.

That's something you have to work around at a design level. You can write containers that don't allocate memory which fit into the "STL" paradigm. You can avoid linked list data structures, or limit their use. You can reorganize arrays of structs into structs of arrays or whatever. It changes some things, but you can keep it compartmentalized.

Changing a complex RTTI operation into a regular virtual function call? That's a design issue. If you have to change that, then it's something that requires changes to every derived class. It changes how lots of code interacts with various classes. The scope of such a change extends far beyond the performance-critical sections of code.

So... why did you write it the wrong way to begin with?

I don't have to define attributes or methods where I don't need them, the base node class can stay lean and mean.

To what end?

You say that the base class is "lean and mean". But really... it's nonexistent. It doesn't actually do anything.

Just look at your example: node_base. What is it? It seems to be a thing which has adjacent other things. This is a Java interface (pre-generics Java at that): a class that exists solely to be something that users can cast to the real type. Maybe you add some basic feature like adjacency (Java adds ToString), but that's it.

There's a difference between "lean and mean" and "transparent".

As Yakk said, such programming styles limit themselves in interoperability, because if all of the functionality is in a derived class, then users outside of that system, with no access to that derived class, cannot interoperate with the system. They can't override virtual functions and add new behaviors. They can't even call those functions.

But what they also do is make it a major pain to actually do new stuff, even within the system. Consider your poke_adjacent_oranges function. What happens if someone wants a lime_node type which can be poked just like orange_nodes? Well, we can't derive lime_node from orange_node; that makes no sense.

Instead, we have to add a new lime_node derived from node_base. Then change the name of poke_adjacent_oranges to poke_adjacent_pokables. And then, try casting to orange_node and lime_node; whichever cast works is the one we poke.

However, lime_node needs it's own poke_adjacent_pokables. And this function needs to do the same casting checks.

And if we add a third type, we have to not only add its own function, but we must change the functions in the other two classes.

Obviously, now you make poke_adjacent_pokables a free function, so that it works for all of them. But what do you suppose happens if someone adds a fourth type and forgets to add it to that function?

Hello, silent breakage. The program appears to work more or less OK, but it isn't. Had poke been an actual virtual function, the compiler would have failed when you didn't override the pure virtual function from node_base.

With your way, you have no such compiler checks. Oh sure, the compiler won't check for non-pure virtuals, but at least you have protection in cases where protection is possible (ie: there is no default operation).

The use of transparent base classes with RTTI leads to a maintenance nightmare. Indeed, most uses of RTTI leads to maintenance headaches. That doesn't mean that RTTI isn't useful (it's vital for making boost::any work, for example). But it is a very specialized tool for very specialized needs.

In that way, it is "harmful" in the same way as goto. It's a useful tool that shouldn't be done away with. But it's use should be rare within your code.

So, if you can't use transparent base classes and dynamic casting, how do you avoid fat interfaces? How do you keep from bubbling every function you might want to call on a type from bubbling up to the base class?

The answer depends on what the base class is for.

Transparent base classes like node_base are just using the wrong tool for the problem. Linked lists are best handled by templates. The node type and adjacency would be provided by a template type. If you want to put a polymorphic type in the list, you can. Just use BaseClass* as T in the template argument. Or your preferred smart pointer.

But there are other scenarios. One is a type that does a lot of things, but has some optional parts. A particular instance might implement certain functions, while another wouldn't. However, the design of such types usually offers a proper answer.

The "entity" class is a perfect example of this. This class has long since plagued game developers. Conceptually, it has a gigantic interface, living at the intersection of nearly a dozen, entirely disparate systems. And different entities have different properties. Some entities don't have any visual representation, so their rendering functions do nothing. And this is all determined at runtime.

The modern solution for this is a component-style system. Entity is merely a container of a set of components, with some glue between them. Some components are optional; an entity that has no visual representation does not have the "graphics" component. An entity with no AI has no "controller" component. And so forth.

Entities in such a system are just pointers to components, with most of their interface being provided by accessing the components directly.

Developing such a component system requires recognizing, at the design stage, that certain functions are conceptually grouped together, such that all types that implement one will implement them all. This allows you to extract the class from the prospective base class and make it a separate component.

This also helps follow the Single Responsibility Principle. Such a componentized class only has the responsibility of being a holder of components.

From Matthew Walton:

I note lots of answers don't note the idea that your example suggests node_base is part of a library and users will make their own node types. Then they can't modify node_base to allow another solution, so maybe RTTI becomes their best option then.

OK, let's explore that.

For this to make sense, what you would have to have is a situation where some library L provides a container or other structured holder of data. The user gets to add data to this container, iterate over its contents, etc. However, the library doesn't really do anything with this data; it simply manages its existence.

But it doesn't even manage its existence so much as its destruction. The reason being that, if you're expected to use RTTI for such purposes, then you are creating classes that L is ignorant of. This means that your code allocates the object and hands it off to L for management.

Now, there are cases where something like this is a legitimate design. Event signaling/message passing, thread-safe work queues, etc. The general pattern here is this: someone is performing a service between two pieces of code that is appropriate for any type, but the service need not be aware of the specific types involved.

In C, this pattern is spelled void*, and its use requires a great deal of care to avoid being broken. In C++, this pattern is spelled std::experimental::any (soon to be spelled std::any).

The way this ought to work is that L provides a node_base class that takes an any that represents your actual data. When you receive the message, thread queue work item, or whatever you're doing, you then cast that any to its appropriate type, which both the sender and the receiver know.

So instead of deriving orange_node from node_data, you simply stick an orange inside of node_data's any member field. The end-user extracts it and uses any_cast to convert it to orange. If the cast fails, then it wasn't orange.

Now, if you're at all familiar with the implementation of any, you'll likely say, "hey wait a minute: any internally uses RTTI to make any_cast work." To which I answer, "... yes".

That's the point of an abstraction. Deep down in the details, someone is using RTTI. But at the level you ought to be operating at, direct RTTI is not something you should be doing.

You should be using types that provide you the functionality you want. After all, you don't really want RTTI. What you want is a data structure that can store a value of a given type, hide it from everyone except the desired destination, then be converted back into that type, with verification that the stored value actually is of that type.

That's called any. It uses RTTI, but using any is far superior to using RTTI directly, since it fits the desired semantics more correctly.