RTTI portability

[Jim Dehnert]

> From loewis at informatik.hu-berlin.de Mon Nov  6 10:57:26 2000
> 
> > The key observation is that user references generally start with a
> > fixed offset based on the compiler's view of the class declarations in
> > the header file, not on the actual runtime structure used by the
> > library.
> 
> Sure, but how would a user use a class derived from an RTTI class
> type? I.e. what is the application that makes it desirable to derive
> from these classes?

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.

Before continuing, I'll note that in my quoted comments below, I was
imprecise.  When I said things such as "user creates RTTI structures
for user types," I really meant "compiler instantiates RTTI objects for
user types" when compiling the user's code.  The key distinction is
between the compiler and headers in use when the user compiles his
modules, and the compiler and headers in use when the runtime
environment vendor creates the runtime libraries.  The problems all
arise if the RTTI definitions visible (in the headers) differ between
the two environments.

> > In fact, since the user creates RTTI structures for user types, this
> > may be an issue even if there are no explicit references to the members
> > in the user source, if any data members change.
> 
> What do you mean by "creates RTTI structures for user types"? Like

See above.

> With that code, the user certainly instantiates typeid objects - but
> those are of predefined classes, not user-defined classes
> (specifically, this is a __pointer_type_info instance).
> 
> > So it seems to me that we must at least require that the data
> > members not change between implementations, which allows their names
> > to be normative if we like.
> 
> Agreed, yes - since the compiler will allocate the typeinfo object.
> 
> > We need not make any requirements about virtual functions, unless we
> > allow users to call them, or to derive from the classes.  Does
> > anyone think we should not forbid this?
> 
> "this" being?

... allow users to call (RTTI virtual functions), or to derive from the
classes...

> > > Why is that a concern? If a user inherits from abi::pointer_type_info,
> > > what undesirable effects could come out of that?

If the user inherits from abi::pointer_type_info, assuming a different
layout than that used in the runtime, and ends up doing anything
that mixes such a beast with the runtime's version (or another
non-runtime version compiled with yet another compiler, he'll have
problems.  Perhaps this isn't a likely scenario, in which case ...
forbid it all?

> > If the definition doesn't match what's in the library at runtime, and
> > he creates a vtable that isn't correct that ends up being referenced by
> > the runtime library, he won't be a happy camper.
> 
> Maybe that's the core of the terminology problem. "Users" don't create
> virtual tables - or did you think that the compiler vendor is the
> user, here?

Above, yes.

> Otherwise, I can see that inheriting from pointer_type_info will cause
> problems if the user adds virtual functions, and then calls them
> himself. I just can't see why that is a problem - we could easily
> outrule inheritance from the typeinfo classes, without loss of
> usability.
> 
> > As noted above, the vendor libcxa.so is required to be a DSO.  If you
> > integrate a non-shared library into your program, there are no
> > portability guarantees.
> 
> Ok. If then the corresponding <abi.h> becomes a system header, then
> there won't be a problem with a mismatch - but maybe that is not
> desirable.
> 
> > > Used in the sense of being accessed - yes, why not? However, I would
> > > not expect users ever to create typeinfo objects.
> > 
> > They will certainly create typeinfo objects, for their user-defined
> > classes.
> 
> No, users won't - the compiler will, for them. The compiler doesn't
> even need to parse abi.h to do so.

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.

> > - Remove the statement that data member names are not normative.
> 
> Fine.
> 
> > - Add a statement that the data members must be exactly as specified.
> 
> Fine.
> 
> > - Leave the statement that the user may not reference the virtual
> >   functions.  (Since the destructor is virtual, does this effectively
> >   forbit deriving from the classes?)
> > 
> > Does this create problems for anyone?
> 
> No, sounds fine for me.
> 
> Regards,
> Martin
> 
-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272