Interoperability of RTTI information

[Nathan Sidwell]

Martin von Loewis wrote:
> 
> 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.
there must be a vtable in type_info as [18.5.1] specifies that the
dtor is virtual. (i.e. your alternative b's type_info definition
is already mandated by the std) -- I see the ABI spec 2.9.5/3 is
different though

> 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.
IIR You can implement dynamic_cast without touching type_info itself, but
you do need to add vfuncs to the __class_type_info heirarchy. Catch
matching requires either vfuncs in type_info, or dynamic_casts
to the pointer_type_info and class_type_info classes during the
matching algorithm (an obvious performance penalty)


> 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. 
correct.

> 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.
The intent of the info note at the end of 2.9.5 is to exclude this
example, though looking at the wording it is insufficiently proscriptive.
To guarantee only one copy of the vtables (and associated vfuncs) in the
executable image requires that shared libraries cannot be statically
linked with the runtime -- is that a problem?

> I see two solutions:
	a) would make it harder for implementations to differentiate
themselves with faster algorithms.
	b) is adding another, ad-hoc, typing mechanism
I prefer a third solution
	c) tighten the wording about place of emission of the type_info
classes' vtables. tighten the wording about type_info's definition
indicating the abi definition is in addition to that of the standard.
Prohibit user derivation of those classes (that could be enforced by
making the final dtor's private).

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan at codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan at acm.org