The previous sections have presented the facilities offered by the RTTI mechanism to the application programmer but haven't described the implementation of this mechanism. In fact, the user of the RTTI system should not be concerned about the way the features he uses are implemented.
The design of the RTTI system tried to face a set of requirements including the palette of operations offered to its user (described in Section 4) and shielding the user from the RTTI implementation. This means that there could be several possible implementations of the RTTI mechanism which should ultimately offer the same API, basically the one introduced in Section 4.
However, some RTTI implementations would not have been able to support all the operations presented in the RTTI system API. Moreover, there exist several similar RTTI systems which provide a very similar API but with different semantics. Although not obvious, such differences can be essential once RTTI is used for larger, more complex C++ class hierarchies.
The intent of this section is to present our implementation for the RTTI mechanism. The important constraints which arose during the systems' design will be outlined and the advantages and drawbacks of the chosen solutions will be commented, often by comparison to other possible solutions.