Interoperability of RTTI information

[Martin von Loewis]

I have concerns that the current RTTI spec does not allow
implementations to interoperate. The core of the issue is whether
there should be a vtable pointer in class type_info.

The current (modified) draft specifies no virtual functions. I believe
it is not possible to implement this specification: Inside
__dynamic_cast, you need to know whether the __class_type_info is a
__si_class_type_info or a __vmi_class_type_info. Likewise, in
exception handling, you need to know whether the types are
__pointer_type_info or not, and whether the __pointee field is a
__class_type_info.

In extension of what is specified, the current GCC adds a number of
virtual functions to the derived type_info classes, such as
__is_function_p, __do_catch, __pointer_catch, and so on. However,
unless specified in the ABI, other compilers won't fill the vtable
pointers of the derived classes to point to gcc's vtables. With the
current spec, the other compilers won't even allocate a vtable field.

Furthermore, there is currently no guarantee that there is only a
single vtable per type_info class if objects from multiple compilers
are mixed. For example, in gcc, these vtables live in libgcc.a, which
is incorporated into any shared library. If a different compiler uses
the same strategy, you'd end up with two definitions for, say, the
__vmi_class_type_info vtable - and they would have a different layout.

I see two solutions:
a) specify exactly which virtual functions must be provided to
   implement the routines mandated by the ABI (i.e. dynamic cast
   and EH matching)
b) provide some basic identification mechanism on top of which
   these ABI routines can be implemented. 

I favour alternative b), and propose the following definitions

  namespace std{
     class type_info {
      private:
        const char *__type_name;
        virtual ~type_info(); /* to give it a vtable */
     };
  }

   namespace abi{
     enum ti_kind{ /* in the order of exposition in 2.9.5.3 */
       /* type_info is abstract */
       fundamental_type_kind = 0,
       array_type_kind = 1,
       function_type_kind = 2, 
       enum_type_kind = 3,
       /* __class_type_info is abstract */
       si_class_type_kind = 4,
       vmi_class_type_kind = 5,
       /* __pbase_type_info is abstract */
       pointer_type_kind = 6,
       pointer_to_member_type_kind = 7,
     }

     class type_info: std::type_info {
       virtual ti_kind kind();
     };
   }

All other type info classes inherit from abi::type_info. The leaf
types override the kind() function, so the implementation must provide
a suitable vtable for them.

Disclaimer: I haven't actually verified that __dynamic_cast can be
implement on top of these informations. If required, I'll try to
produce a sample implementation in gcc.

Regards,
Martin