custom rtti system

[tomtetlaw]

Is there any reason you would want to write your own RTTI system for use in your code, when there already is one in C++?

[vijayan121]

Native support for rtti in C++ is minimal; type-safe down and cross casts and a run-time type identifier (which apply to only polymorphic types). This is woefully inadequate to implement an architecture using the reflection pattern.
http://www.vico.org/pages/PatronsDisseny/Pattern%20Reflection/index.html

Since the language is statically typed, programs are not run under an interpreter (they run on real machines, not virtual machines), and often performance is important, the preferred mechanism in C++ is to use reflection at compile-time rather than run-time (template metaprogramming). The standard library has <typetraits>, and it is possible to extend the reflection facility - for example, the Type Traits Introspection library (boost sandbox) http://svn.boost.org/svn/boost/sandbox/tti/libs/tti/doc/html/index.html

If run-time reflection is what is required, there are two canonical approaches:

1. A meta Compiler that parses normal C++ code and generates code and meta information needed for reflection.
Qt's Meta-Object Compiler: http://developer.qt.nokia.com/doc/qt-4.8/moc.html
Cern rellex: http://root.cern.ch/drupal/content/reflex
XCppRefl library: http://www.extreme.indiana.edu/reflcpp/

2. A purely programmatic approch with library support to make meta information for
reflection available. For example, Helium (C++ game engine toolkit) uses this technique.
See http://www.gamasutra.com/view/feature/6379/sponsored_feature_behind_the_.php

[tomtetlaw]

Thanks for your helpful reply. :)

[mike_2000_17]

>>Is there any reason you would want to write your own RTTI system for use in your code, when there already is one in C++?

Empirically, there most by since there are a number of libraries that rely on some form of a custom RTTI (some build upon the C++ RTTI and others are built from scratch). My library (link below) has a custom RTTI, whose original motivation was to allow for casts on objects from a different module (dll, exe, etc.) which C++'s RTTI is not capable of doing (nominally), also to remove compiler-dependence on the identifiers used for the types to allow for more portable serialization code.

Another possible reason is just to tweek the feature-set, the C++'s RTTI is a vanilla solution (i.e. a "one-size-fits-all" solution). As with most such solutions, they rarely fit perfectly for anyone, and when the fit is too bad, people create their own solution. For example, some find the C++ RTTI to be too heavy-weight for light micro-processor applications and they only require dynamic casting, in this case, you don't need the RTTI, you just need a simple virtual casting function. On the other hand, some find the C++ RTTI lacks features (e.g. for reflection, for serialization), and end up creating their own RTTI for the purpose of adding those features.

Then, you have compatibility and portability issues that come from the fact that the details of how compiler-vendors should implement the C++ RTTI is left unspecified, and thus, if your system is based on RTTI functionalities, then you better make your own if you need strong portability.

As for how to implement it, well that depends on the cases and the feature-set. As vijayan121 has mentioned, some applications rely on some custom preprocessor and in-code custom keywords or macros. Others rely on MACROs and the C++ preprocessor instead. And others make use of careful template meta-programming code (and some MACROs) to achieve it. The point is that an RTTI implementation is by definition going to be intrusive and will require this type of MACRO / preprocessing with a small dose of additional programming effort by the programmers of the classes within the library.