More rtti woes

[Nathan Sidwell]

Jason Merrill wrote:
[I've combined stuff from both your emails]

>  > 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*.
I presume you're refering to g++'s runtime. The only dynamic_casts of
this kind are in g++'s old-abi catch matcher. The new-abi doesn't need
any, using virtual functions. Or were you thinking of somewhere else?
Where the old-abi has dynamic casts, the new abi code has.
   catch_type->do_catch (...)
&
   thrown_type->is_pointer_p ()

> It was suggested in the meeting today that both _pti and _ptmti be derived
> from a common base instead; this makes sense to me.
I do not think this is necessary, but I've no strong feeling about it.
Having a common base adds complexity (bad), but not having it constrains
implementations to use vfuncs rather than dynamic_cast (possibly bad).

> 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.
Doh! you're right a conforming program could tell by (attempting to)
take the function's address.

> 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.
I have come to this conclusion too.

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