vtable layout

[thomson at ca.ibm.com]

>OK, so you *were* proposing that we require something like the above?  I
>see.  That's why you talked about the worst case of 2N slots.  We'd
>need to pad out D's vtable with as many slots as there are slots between
>the B and C vptrs.  I agree that this wouldn't require special handling for
>virtual bases.

Jason, Christophe, I am not so quick.  I don't see how this solves my
diamond case

   struct V1 { virtual void f();  virtual void g(); };
   struct Other1 { virtual void ignore1(); }
   struct X : Other1, virtual V1 { virtual void f(); }

   struct Y : Other1, virtual V1 { virtual void g(); }

   struct ZZ: X, Y {}

You want the adjustment values allocated in the derived class vtable, so
aggregate vtables for X look something like this

               offset_X_to_V1            ; the adjustment value for X::f
_vft_X:        rtti/dyncast info?
               &X::f                          ; replicated, calls primary entry
_vft_Other1_X: rtti/dyncast
               &Other1::ignore1
_vft_V1_X:          rtti/dyncast
               &X::f__2                  ; calls secondary entry
               &V1::g

and for Y like this:

               offset_Y_to_V1            ; the adjustment value for Y::g
_vft_Y:        rtti/dyncast
               &Y::g                          ; replicated, calls primary entry
_vft_Other1_Y: rtti/dyncast
               &Other1::ignore1
_vft_V1_Y:          rtti/dyncast
               &V1::f
               &Y::g__2                  ; calls secondary entry


That means X::f__2 finds its adjustment offset at vptr-40, and the same goes for
Y::g__2.  Now how do you lay out the vtables for ZZ?



Brian Thomson
VisualAge C/C++ Chief Architect