A-23 RTTI class structures (was RTTI updates)

[Jim Dehnert]

I've fixed all of Nathan's concerns except that of indicating whether
the vmi_flags refer to direct and indirect bases.  That one's because I
wasn't sure of the right answer.  It seems useful to include both
direct and indirect properties except for:

 1) has non-virtual bases (would anyone ever care about indirect ones?)
 2) maybe publicly inherited bases (same reason)

Opinions on these (and the others)?

I also made the fix for his more significant concern.  I had left out
the multiple inheritance flag because of the exchange with Jason at the
meeting indicating agreement that it wasn't necessary.  But one or both
of us may have misunderstood what we were discussing.  Does anyone have
a problem with including it?

> From nathan at acm.org  Fri Feb  4 02:12:00 2000
> 
> Some pedant points.
> * (7b) The description of __si_type_info still does not say the base must
> be public and at offset zero.
> * (7c) The description of __class_type_info still says `containing (directly
> or indirectly)', Jason's mail indicates the intention is `containing directly'
> * (7c) The vmi_flags should probably indicate they refer to direct and
> indirect bases.
> 
> And a more significant one.
> * (7c) I see the diamond shaped flag has been added, what about the non-diamond
> shaped multiple sub-object? That too is important for dynamic cast and base
> class catching.
> 
> For instance, in dynamic cast, when we locate an instance of the target class
> the following cases can be considered
> 1) The complete class has no multiple sub-objects. There cannot be another
> instance of the target class in the heirarchy, so we're done.
> 2) The complete class is diamond-shaped, but has no non-diamond shaped multiple
> base object. There will be no other instance of the target class, but the target
> may be reachable via another path. That other path could be publicly accessible,
> so if we've found a private access to the target keep looking, otherwise we're
> done.
> 3) The complete class has non-diamond shaped multiple base object, but is not
> diamond shaped. There may be other instances of the target class, which could
> ambiguate the dynamic cast. The other instances cannot share base objects. If the
> src sub object is within the located target, this is unambiguous, so we're done.
> Otherwise keep looking.
> 4) The complete class has non-diamond shaped multiple base object, and is
> diamond shaped too. There may be other instances of the target class, which
> could share base objects. Keep looking.
> 
> Similar cases arise in catch matching on casting derived to base.
> 
> Without the non-diamond shaped multiple subobject flag, both dynamic cast
> and catch matching must take paths 3 or 4, which are more work and I'd hazard
> less common.
> 
> Maybe there was insufficient time to discus this at the meeting. Just want to
> make sure it's not forgotten.
> 
> nathan
> -- 
> Dr Nathan Sidwell :: Computer Science Department :: Bristol University
> Never hand someone a gun unless you are sure where they will point it
> nathan at acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan at cs.bris.ac.uk
> 
-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272