More rtti woes

[Jason Merrill]

>>>>> Jason Merrill <jason at cygnus.com> writes:

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

It was suggested in the meeting today that both _pti and _ptmti be derived
from a common base instead; this makes sense to me.

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

Never mind; this won't work, of course.  In the meeting we liked your
proposal B, and deferred a decision on A.  Thinking about it now, I'd
prefer to just go with B; splitting up the type_infos seems unnecessary.

Jason