rtti data structures (again)

[Daveed Vandevoorde]

Nathan Sidwell wrote:
[...]
> > We also decided that the flags should move from __class_type_info into
> > __vmi_class_type_info, and that the polymorphic flag should be removed.
> I think this moving of the flags is a mistake. If I understood correctly,
> they indicated information about direct and indirect bases (whether there
> was virtuality anywhere in the heirarchy for instance). Such information
> can speed up dynamic cast. When walking the inheritance graph, we can
> take some early outs, if we know there are no multiple sub object types
> within the complete graph. With the flags in every class's type_info, it
> becomes easier to get hold of that info. With it only for vmi classes,
> we have to remember `unknown' when presented with a complete object of
> si type, and fill the information in when/if we find a vmi base. Another
> case is in a potential cross-cast case, which I had in the previous email.
> Suppose we've found the target base, which we know is unique, but not
> found the source base (because we early outed, maybe). To be a valid
> cross-cast both the source and target base objects must be public in the
> complete object. If we know the complete heirarchy has no non-public bases,
> there's no need to search for the source base in this case.

Yes, I think that was indeed the original purpose of the flags.

> Now, these might both seem small optimizations, but they're the two
> most evident uses (to me) of the flags. It would be rash to remove such
> information from si_class_type_info.

I'll second Nathan on this.

	Daveed