RTTI portability

[Jim Dehnert]

> From loewis at informatik.hu-berlin.de Tue Nov  7 01:19:58 2000
> 
> > I don't know.  Most of this thread arose because someone wanted the
> > RTTI member names to be normative, which only matters if they are to be
> > referenced outside the implementation's runtime library, i.e. by users.
> > Whoever it was, though, hasn't been standing up with examples.  Perhaps
> > that's not a real issue.
> 
> To access the fields of typeinfo objects, you don't have to derive
> from those objects. Instead, you can do
> 
>   type_info &foo = static_cast<class_type_info&>(typeid(bar));
>   cout<< foo.base_type->name() << endl; // prints name of base class
> 
> There may be applications of browsing through the base class list of
> an object: if you want to efficiently classify an object into a number
> of root classes, that approach may be faster than a series of
> dynamic_casts.
> 
> However, I can't foresee an application where the user would need to
> inherit from the RTTI classes.

OK, I think the current version is consistent with this.  The data
members must be as specified, and their names are specified without the
previous disclaimer that they are not normative, so they are.  OK with
everyone?

> > Again, my terminology at fault.  But the compiler will have problems.
> > Whether it uses its (different abi.h) or its different internal
> > assumptions about it, the difference could create problems.
> 
> Only if the number or order of fields is different. If it has
> different virtual functions in the header file, it won't be a problem:
> the compiler only emits a reference to the vtable, not the vtable
> itself - that one is in libcxa.so. Since the compiler will also need
> to use the ABI routines for processing typeinfo objects from
> libcxa.so, there will be no problem.

Ummm...  There are no ABI routines currently specified.  Those
specified in the base class (type_info) are Standard-specified.  So
this presents no problem as long as any necessary routines are
non-virtual and consistent between implementations, but I'm not sure
you're assuming that.  We haven't specified it.

Note that although the compiler doesn't emit a vtable, it could emit a
use of one of the vpointers in one.  So any user code referencing a
type_info virtual function (except the destructor specified now, and
presumably appearing first) presents the potential for a problem
crossing between implementations.  The current version as written
forbids this.  Is that OK with everyone?

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272