Thread: Eliminating dynamic_cast<>

  1. #16
    Optics with a Twist skewray's Avatar
    Join Date
    Dec 2006
    Location
    South Pasadena, CA
    Posts
    36
    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.

  2. #17
    Registered User kroiz's Avatar
    Join Date
    Jun 2007
    Posts
    116
    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.

  3. #18
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    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.
    Last edited by whiteflags; 09-10-2007 at 03:01 AM.

  4. #19
    Optics with a Twist skewray's Avatar
    Join Date
    Dec 2006
    Location
    South Pasadena, CA
    Posts
    36
    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.

  5. #20
    pwns nooblars
    Join Date
    Oct 2005
    Location
    Portland, Or
    Posts
    1,094
    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.

  6. #21
    Optics with a Twist skewray's Avatar
    Join Date
    Dec 2006
    Location
    South Pasadena, CA
    Posts
    36
    Great recommendations! I was looking for more leads into good books.

  7. #22
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Wraithan View Post
    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.
    Reminds me of a tool I discovered in the desert once. I think it is some kind of firefighter's tool.

    It is an axe, hammer, pliers, screwdriver, knife, wire cutter and wrench all in one. And it weighs about 10 pounds.

  8. #23
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by citizen View Post
    And in addition, the key question is if your design makes sense.
    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.

    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.
    Quote Originally Posted by citizen View Post
    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.
    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.

    A good design will make an objective decision to use RTTI, or not, based on trade-off of the implications.

    Quote Originally Posted by citizen View Post
    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.
    I disagree with this.

    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 15
    Last Post: 05-06-2008, 05:02 AM
  2. Eliminating a window border
    By Night_Blade in forum Windows Programming
    Replies: 2
    Last Post: 08-26-2007, 09:15 AM
  3. Eliminating lighting "over-bright"
    By psychopath in forum Game Programming
    Replies: 1
    Last Post: 05-31-2006, 06:52 PM
  4. Eliminating duplicates
    By C-Struggler in forum C Programming
    Replies: 3
    Last Post: 03-23-2003, 11:12 PM
  5. eliminating dup values in array
    By Unregistered in forum C Programming
    Replies: 2
    Last Post: 04-19-2002, 06:05 PM