RTTI portability

[Martin von Loewis]

> 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?

> 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

class X:virtual something{
  fields;
} *xptr;

...
if(typeid(x)<typeid(int)){...}

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?

> > Why is that a concern? If a user inherits from abi::pointer_type_info,
> > what undesirable effects could come out of that?
> 
> 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?

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.

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