The motivation for my question was that I have read that using RTTI is inherently slow. I haven't done actual runtine comparisons, though; runtime may be compiler dependent anyway. The alternate solution I came up with was to make each derived class have a static member containing an enum, and then comparing derived classes just boils down to (this->type == derived->type). Rather non-OOP.
The application is that I am parsing a grammar into a tree, where the nodes represent various types of operations and atoms. The nodes are equal only if they are the same type and have the same value.
isn't better to first write your program as nicely and simply as you can (with RTTI) and then if it is not fast enough to do optimization.
I bet that in the end you will have plenty of bottle necks and slow code to optimize that will give you a much more significate performance boost then the RTTI impact
and at a much less cost on readability.
And in addition, the key question is if your design makes sense. It's good that you are thinking about the casting operation, but I get the feeling someone wrote that just to get people to stop relying on RTTI. The easiest way to do that is to tell the audience that it has "poor performance properties." Rather than choosing to educate them about the implications it has on design, I think the author was probably lazy, fanatical, or not talking about your situation. Don't jump on the bandwagon of everything you read about performance.
The need for RTTI implies that you don't know what objects you are using at some point, and if that happens, you usually have to make it into something else.
Up-casting is bad because it slices up objects, and you will lose data temporarily. Down-casting is not this bad, but you are making an apple into an orange still. The big idea is that this isn't type strict behavior (which is not desirable from a language that tries to be type strict) but at times it is necessary and, at least in C++, you can verify that it is correct.
The horse's mouth.
My ultimate motivation for asking is less performance than learning C++. I just read "Design Patterns" by Gamma et al., and I found most of the patterns incomprehensible, except for the few I had come up with on my own. The Visitor pattern looks interesting and incomprehensible, but my classes are almost completely defined by the virtual functions now, so am not sure I gain anything by trying it. I may give the Visitor a shot just to see how it works out.
Thanks to everyone who responded to the thread.
Skewray: If you want to get a better grasp on the GoF book, check out Design Patterns Explained, until I read that, I couldn't seem to figure out how the patterns would fit it, and then how they would fit together, and even when I did see all of that, I tried to implement every pattern I could... which was a wrong move too lol.
I am now reading Modern C++ Design, which is really interesting, it takes the patterns and marries it together with templates in a way that makes sense (at least after reading the GoF book and Design Patterns Explained) And I have never been good with templates and it is helping me understand the awesome ways they can be used, aside from, gee, I want to use a generic type.
Great recommendations! I was looking for more leads into good books.
Reminds me of a tool I discovered in the desert once. I think it is some kind of firefighter's tool.
Originally Posted by Wraithan
It is an axe, hammer, pliers, screwdriver, knife, wire cutter and wrench all in one. And it weighs about 10 pounds.
That is true. The main objective argument against RTTI, however, is not performance. It is that if code needs to know the actual type of an object, then that probably means some other deficiencies in design of key interfaces supplied by your classes and the functions which use instances of those classes. For example, a function that is expecting to receive a horse will need to use RTTI if a caller can unintentionally supply it with an apple.
Originally Posted by citizen
Instances where RTTI is genuinely needed include class hierarchies that are all derived from a common base class, and the hierarchy is design with the concept that derived classes may have extended interfaces. These characteristics occur in some GUI frameworks (eg base class is an Object, derived classes include Window, Button, etc, classes can be derived from Window and Button, and generic functions for event handling are passed an Object).
The big issue is that RTTI is a big hammer to crack a small nut. There are often better alternatives (eg defining a complete interface for a base class and then using polymorphism) but RTTI is useful if those alternatives aren't practical.
Well, yeah. However, RTTI does often come with a performance implication -- dynamic_cast in C++ certainly does. Which means that unnecessary usage (which can result from sloppy design) imposes a performance hit.
Originally Posted by citizen
A good design will make an objective decision to use RTTI, or not, based on trade-off of the implications.
I disagree with this.
Originally Posted by citizen
Up-casting (casting from derived to base) is actually implicitly supported in several OO languages, in circumstances where it makes sense. However, a need do do explicit upcasting is usually a danger sign that indicates a serious design problem.
Downcasting can also be a indication of a very serious design problem, as it can mean treating an object as something it isn't. However, there are cases where it is necessary, and RTTI can provide additional checks and balances to prevent inappropriate downcasting.