incomplete rtti

[Nathan Sidwell]

Jim Dehnert wrote:

> It does NOT say that no other type_info structures are accessible, only
> that there's only one with the ABI-defined name.  This is true for all
Doh!

> types, including pointers.  Your problem is that some "complete"
> pointers may reference other type_info structures.  Anyway, I've fixed
> this paragraph and the next one you mention -- see what you think.
Looks good. I'd add `direct or indirect' into
  Therefore, except for _direct or indirect_ pointers to incomplete types, the
  equality and inequality operators ...
just like you've got for the before() description.
 
> >  When abi::__pointer_type_info objects are compared for equality, if either has the
> >  incomplete flag set the NTBS of the std::type_info bases must be compared. When
> >  neither incomplete flag is set, the addresses of the abi::__pointer_type_info objects
> >  can be compared as with the other types. The implementation of before() behaves
> >  similarly.
> 
> I think the reason you can't just check the NTBS of the pointer is
> precisely because of intervening CV-qualifiers.  Or do they always have
> to match?  Anyway, I haven't changed this paragraph, pending better
> understanding.
When you're testing for equality, all the cv qualifiers must match. Think about
how `typeid (A *) == random_type_info' would behave. Assume random_type_info
doesn't involve incomplete types.

If A is complete, we'll do a pointer comparison on the type_info objects themselves.
If A is incomplete, we just need to compare the top level NTBS's.

It's in catch matching that we have to follow the pointer chain, and then it is
permissible for the cv qualifiers to differ (but only such that it is a
qualification conversion). In those cases we have to follow the chain regardless
of the completeness of the final non-pointer type.

BTW. I've realised there is another scheme which would allow type_info equality
to be pointer equality in all cases. The scheme we have at the moment essentially
forces operator== to involve a virtual function call. If we have separate objects
for the result of typeid to that used by dynamic_cast and catch matching then this
problem goes away. The cost is an extra vtable entry and the inability to provide
`augmented' type information via typeid (which we don't do at the moment anyway).
I know it's a little late in the day, but I've only just realized that we had lost
this address equivalence property. If there's interest I can write that up in
short order.

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