RunTimeTypeInformation (RTTI) refers to data on the types of program constructs being placed in the runtime environment.  This can be useful largely for purposes of reflection and multiple type polymorphic dispatch.  Type safety is typically assumed to be static: one doesn't usually discuss RTTI as though it's an optional ''feature'' in the context of dynamically typesafe languages!  However, RTTI can also be utilized by the RuntimeEnvironment to provide the limited 'I crash gracefully' form of type-safety found in DynamicLanguages.

RTTI was controversial within the C++ community.  Many OO languages have provided similar capabilities from their start.  Many non-OO-languages don't provide it and never will.  Given the memory footprint cost of RTTI (especially when working with large typenames seen when using TemplateMetaprogramming), RTTI actually continues to be of some controversy among those who care about space optimizations.  Fortunately, most compilers of the C++ language provide switches to enable or disable this controversial feature.  

----

Is RTTI really at all 'useful'? (for statically type-safe languages)

Those (like myself) who possess considerable experience with variant types (e.g. tagged unions as seen in Haskell or OCaml) would probably more appreciate real support for variant-typed-objects in an OO language than we do RTTI and Reflection.  Currently we commonly possess structs and records and multiple-inheritance for 'AND' types (one of these AND one of those), but we are stuck using a truly awful inheritance approach for 'OR' types - e.g. C++ unions can only be applied to simple types (though Boost does provide some help in this arena).   

There is rarely ever a need to know the exact implementation for an object - even when you do 'cast downwards', there will always be some finite set of statically determined interfaces to which you attempt to 'cast' the object, and this set can be made explicit via a variant type.  This works in the majority of useful cases; it fails to translate multiple inheritance well, but that is accompanied by the fact that multiple inheritance also fails to translate well when working with operation dispatch.

The one thing of real potential value I see for RTTI is in serialization of objects for persistence or mobile code.  One needs all the information it takes to restore this object into working order.  However, even here, I'm not convinced one shouldn't just use a common language structure that can be evaluated back into the proper construct via more explicit mechanisms.

----

''There is much meta-discussion below:''

The interesting thing is the lack of discussion of RunTimeTypeInformation on wiki.  I found only four references to typeid in the whole of wiki.


One is in AreClassesObjects and discusses the problems of relying on the C++ typeid(something).name() as it may not be unique.

Another is in DoubleDispatch and discusses a possible use of typeid().

I started a discussion on TemplatesAndRunTimeTypeInformation and have found I can do most of what I want using TraitsTemplates instead, which implies that the information is available at compile time anyway.

Finally there is SingleFunctionExitPoint where typeid is used in a debug example at the end of the page.

-- JohnFletcher

dynamic_cast is also a form of RTTI; search for dynamic AND cast. (See DynamicCast)


----

Java is popular here.
See http://www.c2.com/cgi/wiki?search=Reflection
including CategoryReflection.
----
See also: AdvantagesOfExposingRunTimeEngine
----
CategoryCpp CategoryCppTemplates CategoryPolymorphism