More rtti woes

[Nathan Sidwell]

Hi,
More rtti woes I'm afraid.

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

incomplete_mask       = 0x8
incomplete_chain_mask = 0x10
incomplete_klass_mask = 0x20

incomplete_mask is an inclusive or of the other two flags.
incomplete_klass_mask is only used by __pointer_to_member_type_info,
and __pointer_type_info knows nothing about it (it simply examines the
other two).

A __pointer_type_info or __pointer_to_member_type_info sets the
incomplete_mask and incomplete_chain_mask, if the target is an incomplete
type, or has its incomplete_mask set.

A __pointer_to_member_type_info sets the incomplete_mask and the
incomplete_klass_mask, if the class of the member is incomplete.

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.

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.

The abi requires us to add virtual functions to type_info. 
For instance the implementation of operator== will require it to
deal with pointers to incomplete. G++ needs several for catch matching.

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.

The two proposals I made last week (`Alternative rtti proposals') resolve
these issues. Proposal A resolves issues 2,3 &4, whilst proposal B
resolves issue 2 only, and will leave us (slightly) non-conformant.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan at codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan at acm.org