More rtti woes

[Jason Merrill]

>>>>> Nathan Sidwell <nathan at codesourcery.com> writes:

 > Issue 1)

 > It is permissible in a pointer to member of X, for X to be an incomplete
 > type [8.3.3]/2. This means that we need more that a single incomplete
 > flag.

Yup.

 > The presence of such a ptr to member, will mean that it, and all
 > pointers to it will have their incomplete flag set, but its target
 > might not be an incomplete chain. In implementing G++'s rtti runtime I
 > found the following three flags useful, (this is with
 > __pointer_to_member_type_info derived from __pointer_type_info)

I don't think it's proper to make that derivation; a pointer to member is
not a pointer.  This matters to the EH type matching code, which does a
dynamic_cast to _pti*.

 > Issue 2)

 > The algorithm for collation order of type_infos, cannot simply compare
 > addresses for non-pointer types, and complete pointer types.  Using
 > string collation only when one of the types is a pointer with the
 > incomplete_mask set. There are two difficulties. Firstly, we might be
 > comparing a non-pointer type_info with a pointer type_info. We need to
 > determine this and DTRT WRT the incomplete flag of the pointer
 > type_info. to do that will require dynamic_cast or typeid'ing the
 > type_infos. Secondly, assume we are just comparing pointer type_info's.
 > We have two pointers to complete, Aptr and Bptr, and a third pointer to
 > incomplete, Cptr.

 > 1) Aptr.before (Bptr) can just compare addresses.
 > 2) Bptr.before (Cptr) will compare names.
 > 3) Cptr.before (Aptr) will compare names.

 > There is nothing maintaining the consistency of the results of these
 > three tests -- result 1 is uncorrelated with results 2 & 3....
 > Therefore type_info::before must be implemented as string compare on the
 > type's names. We lose any advantage of commonizing the type_infos.

What if we put the incomplete flag in type_info and decide that all
incomplete type_infos are "before" all the complete type_infos?

 > Issue 3)

 > 17.4.4.4 prevents an implementation adding member functions to one
 > of the std classes, except in particular circumstance. About the only
 > leeway given is whether a particular non-virtual function is inline or
 > not. So I presume we're not permitted to add virtual member functions
 > to std::type_info (18.5.1). The rules given in 17.4.4.4 specifying what
 > member functions can be added look like applications of the as-if rule,
 > but there must be something deeper going on, as if that was all, it
 > wouldn't be mentioned. I'm not sure how a conforming program could tell
 > whether additional functions had been added.

17.4.4.4 specifies that you can add overloads to member functions in
certain ways that *can* be detected by a conforming program.  There are no
restrictions on adding member functions with other names, by the as-if rule.

 > Issue 4)

 > 5.2.8 talks about typeid returning something derived from type_info,
 > but the footnote mentioning extended_type_info implies to me that
 > typeid always returns objects of the same type. Again, I'm not sure
 > how a conforming program could tell.

I disagree with your interpretation.

Jason