RTTI queries

[Nathan Sidwell]

Jim Dehnert wrote:
> 
> Following are the resolutions to Nathan's questions/suggestions from
> last week's meeting.  I've also included them in the layout document.
Great!

> > 3.2) More useful for dynamic cast, (and possibly catch matching) would be
> > the following flags
> >       * Contains non-diamond shaped multiple base object
> >       * Is diamond shaped
> >       * has virtual base
> >       * has non-virtual base
> >       * has public base
> >       * has non-public base
> > Note that the virtual/non-virtual and public/non-public are not mutually
> > exclusive. Also note that I have not actually implemented anything with these
> > flags, so I could be wrong.
> 
> Discussion was positive in principle.  We need a more precise
> definition of "diamond shaped".  Can you provide that?
[class.mi] (clause 10.1) provides good examples.
Paragraph 4 gives a non-diamond shaped graph with multiple base object.
At least one of the multiply inherited base objects must be non-virtual.
	struct L {};
	struct A : L {};
	struct B : L {};
	struct C : A, B {};
There are two distinct L base objects in C. C would have the non-diamond
shaped multiple inheritance flag set. A, B and C would have the non-virtual
base flag and public base flag set.

Paragraph 5 gives a diamond shaped graph. Such a multiply inherited base
object must be virtual.
	struct V {};
	struct A : virtual V {};
	struct B : virtual V {};
	struct C : A, B {};
This time C would have the diamond shaped flag set. A, B & C would have
the virtual base flag set and the public base flag set. C would also have
the non-virtual base flag set.

Paragraph 6 gives a graph which contains both features. Here there is
one non-virtual base and one virtual base.
	struct B {};
	struct X : virtual B {};
	struct Y : virtual B {};
	struct Z : B {};
	struct AA : X, Y, Z {};
In that example, AA would have both diamond and non-diamond flags set.
all would have the public base flag set, AA & Z would have the non-virtual
base flag set, AA, X & Y would have the virtual base flag set.

The above is treating the non-virtual and virtual base flags differently,
they should have the following meaning
	has non-virtual direct base
	has virtual direct or indirect base
similarly the public and non-public flags mean
	has public direct base (to have an indirect public base,
				there must be a direct public base)
	has non-public direct or indirect base

My thinking is that for dynamic_cast, having such information will allow
pruning parts of the inheritance graph walk. For instance, there can only
be distinct multiple target base objects when the non-diamond shaped flag
is set in the complete object. When we find them, the base sub-object started
from can only be a common base for both of them, if the diamond shaped flag
is set in the complete object. Alternatively, there can only be (at most)
one instance of the target type when the non-diamond shaped flag is clear.
When we find it via a non-public path, there could only be an alternative
public path if the complete object has the diamond shaped flag set. Similar
pruning should be possible for catch matching. Without such information,
the graph walk has to be pessimistic, which I beleive will slow down the
common case.

nathan
-- 
Dr Nathan Sidwell :: sidwell at codesourcery.com
nathan at acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan at cs.bris.ac.uk