next up previous index
Next: The Type_info Class Up: Implementation of the Previous: Implementation of the

Interface and Implementations of Typeids

 

The user's perspective on a typeid is of a class which encodes 'all type information' about an application C++ class. The definition of a C++ class is unique in a program. However, we can have more typeid objects representing the type of the same class. This fact, added to the fact that the interface of the typeid and its implementation should be separated, leads to the idea that a typeid should only be a 'handle' to the real type information representation. In this way, we a) insulate the typeid interface from its implementation and b) can easily create and destroy typeids but keep only one copy of the type information per C++ class (the same idea is used by [Stroustrup, 1991]).

We shall introduce here a new class Type_info which represents the real implementation of the type information for a C++ class. In other words, each C++ class will have a unique Type_info object which will encode its type information, but there can be any number of typeids which refer to this Type_info. In terms of object-oriented design patterns, the typeid is a Handle and the Type_info is a Body. typeid delegates all its requests to its Type_info object. typeid can be also seen as a Proxy for a Type_info (it acts as a Type_info, but is lighter and simpler). Type_info can be seen as a (sort of) Singleton, since there is only one instance per C++ class. See Section 5.2 for a complete description of the Type_info implementation.

One design problem is related to the fact that for each C++ class which desires to use RTTI there has to be exactly one Type_info object. Since this object is however related to the C++ class rather than to its instances, the best way is to implement it as a static class member. Besides unicity, this will also ensure that any C++ class will automatically create its (static) Type_info instance. The relationship between typeids, C++ classes and their Type_infos is as depicted in Figure 1:

  
Figure 1: Relationship between typeids, C++ classes and their Type_infos. A C++ class A, its Type_info static member and three typeid objects which refer to it are shown

The second main design point relates to type information retrieval: how do we retrieve a typeid from a C++ class or pointer ? The first question is trivial, since we can retrieve the static Type_info C++ class member having a C++ class (this is exactly what the macro STATIC_TYPE_INFO does). The second question however needs some additional work, since we do not want to relate the information with the pointer type but to the pointed object actual type. Basically, we can do this in C++ by inserting the information in the class object and adding a virtual method to this object.

This is exactly the way we implemented the PTR_CAST, TYPE_NAME and TYPE_NEW macros: they use some virtual functions of the pointed object (one of them, for example, returns the static Type_info of its class).

To summarize, we implemented the RTTI mechanism by two basic constructions: virtual functions and a static Type_info object added to each C++ class. This leads us to the important observation that we need to be able to add virtuals to a C++ type which wishes to support RTTI. This explains why this approach can work only for classes but not for basic C++ types (e.g. integers). This is however not a limitation since anyway one can't derive types from, say, integers, so run-time casting and other similar operations are actually meaningless for integer pointers, for example.



next up previous index
Next: The Type_info Class Up: Implementation of the Previous: Implementation of the



Alexandru Telea