   dyanamic type checking in C++
  Every time I think I have an instance of "clean" polymorphism I always seem to end up needing to down cast at some point. For example I have a class which is configured through user input, and later we need a type is fundamentally different in some of it's internal procesing, but otherwise similiar, it's drawn the same way, written the same way etc. So I think, hurrah, I'll make a derived class and overload some virtual methods, and the owning class can sit blissfully unaware.But then later it'll turn out than the user wants to be able to configure an extra property of the new type, that has to be mutable after construction.  It doesn't make sense for the parent class to have this method. So I need to downcast to get at it.I get the impression that this is not considered to be good practice, and that perhaps newer OO languages have better support for it, but in C++ a downcast is considered to be a "code smell". But I don't see why this is, the idea of asking a class to tell me what type it is, and saying something equivalent to:if( isDerivedClass( myClassPtr ) )    myClassPtr->DerivedClassOnlymethod();seems reasonable, and on the face of it C++ has the dynamic_cast operation to do just this. I don't know if I'm imagining things but is dynamic_cast considered a bit of an embarassing uncle in the C++ family? For example I notice that the MFC library implements it's own runtime type checking system through some macros which I think convert the classname into a member variable identifier of some kind. Why would they want to do this instead of just using dynamic_cast?EDIT: Oh damnit, meant to put this in general. Perhaps it could be moved? I don't suppose it really matters.   
  There is a time and a place for dynamic_cast. I suspect you are not actually at that time nor that place. Based purely on your opening paragraph, in particular:Quote:For example I have a class which is configured through user input, and later we need a type is fundamentally different in some of it's internal procesing, but otherwise similiar, it's drawn the same way, written the same way etc.I am given the impression that you simply have a deeper-rooted design flaw (mostly that your objects do too much, violating the Single Responsibility Principle).Can you provide an example of where you've actually ran into the apparent need or desire to downcast based on some of your actual code (and include that actual code and/or classes involved)?;  Can you give a concrete example of where you need to downcast? Most of the time with a bit of a rethink a suitable alternative can be found.   ;  Sorry I don't have access to the code just now, and in any case the example that actually prompted this is quite complicated. To give a rough explanation, consider a program for manipulating some geometrical objects in 2D that are of quite particular design. You have a top level object which defines an outline or border shape which can be configured by the user, call this the Shape class. Optionally this shape can be composed of sub shapes which overlap and cover the region defined by the border. These shapes are not editable directly by the user but are "fitted" to the shape area in a specific manner that depends on the outline and the number of subshapes requested. So the shape class owns a SubShapeCollection class for managing this process.SubShapeCollection is itself composed of 2D entities, which it rebuilds when necessary. It also has methods to draw it's sub objects and write them to a file and some other things.  Now later it turned out that the user wanted an option to build the subobjects according to a different procedure, so we made a child class with a method to handle this. Later still it turns out that this new rebuilding process has a parameter that needs to be user specified, so the call to rebuild has to take a new argument.Looking at what I've just written I suppose what your going to tell me that the object which composed of the sub objects should be distinct from the class which builds the sub-objects. Although it's probably too late for that with this design, is this the kind of flaw you refer to?   ;Quote:Original post by jpetrieThere is a time and a place for dynamic_cast. I suspect you are not actually at that time nor that place. Based purely on your opening paragraph, in particular:Quote:For example I have a class which is configured through user input, and later we need a type is fundamentally different in some of it's internal procesing, but otherwise similiar, it's drawn the same way, written the same way etc.I am given the impression that you simply have a deeper-rooted design flaw (mostly that your objects do too much, violating the Single Responsibility Principle).Can you provide an example of where you've actually ran into the apparent need or desire to downcast based on some of your actual code (and include that actual code and/or classes involved)?i completely agree, needing to know type is a common symptom of  the problem is actually somewhere else and that problem is that you need a factory to create objects :);  Downcasting is always a proof of bad design.Move the code that needs to know the actual type elsewhere, where you actually statically know it.   ;  I agree that this is a General Programming topic. Moved.   