virtual inheritance

[Ripunjay Tripathi]

Hi All,

I was referring to "Inside The C++ Object Model" where in while
discussing about copy constructors and virtual base classes, author
says that ....
=========================
class X { public: int i; };
class A : public virtual X { public: int j; };
class B : public virtual X { public: double d; };
class C : public A, public B { public: int k; };
// cannot resolve location of pa->X::i at compile-time
void foo( const A* pa ) { pa->i = 1024; }

main() {
foo( new A );
foo( new C );
// ...
}

......the compiler cannot fix the physical offset of X::i accessed
through pa within foo(), since the actual type of pa can vary with
each of foo()'s invocations. Rather, the compiler must transform the
code doing the access so that the resolution of X::i can be delayed
until runtime. In the original cfront implementation, for example,
this is accomplished by inserting a pointer to each of the virtual
base classes within the derived class object. All reference and
pointer access of a virtual base class is achieved through the
associated pointer. In our example, foo() might be rewritten as
follows under this implementation strategy:

// possible compiler transformation
void foo( const A* pa ) { pa->__vbcX->i = 1024; }
=============================

Now my problem is why does he says that physical offset of X::i cannot
be fixed ? Compiler knows that X::i is a part of sub-object of class
X in its all derived class hirerarchy. Why this offset identification
is is being untill runtime. If I am a virtually inherited class in
some hierarchy, while compilation and after all other subobject frames
sit in their respective places my place can also be defined as a last
step though.

However I understand his pointer to vtable concept, that seems simpler
approach....but what I dont understand is the inability to find
offset....

Regards,
Ripunjay Tripathi

 

[Andrey Tarasevich]

// possible compiler transformation
void foo( const A* pa ) { pa->__vbcX->i = 1024; }
=============================

Now my problem is why does he says that physical offset of X::i cannot
be fixed ? Compiler knows that X::i is a part of sub-object of class
X in its all derived class hirerarchy. Why this offset identification
is is being untill runtime. If I am a virtually inherited class in
some hierarchy, while compilation and after all other subobject frames
sit in their respective places my place can also be defined as a last
step though.

You do realize that base subobjects 'A' and 'B' inside object 'C' are
supposed to _share_ their base subobject 'X'? I.e. there's only one 'X'
in 'C', even though it is included through two different inheritance
paths X->A->C and X->B->C. Having only one instance of base class
subobject 'X' shared by all inheriting subobjects is the very point of
virtual inheritance.

Now, how are you proposing to fix the position of 'X' at compile time?
Remember, that 'X' is a subobject of 'A', so its position inside 'A'
should be fixed in this case. 'X' is also a subobject inside 'B' so its
position inside 'B' should also be fixed. This would be easy if both 'A'
and 'B' had their own instances of 'X' (and that's what would take place
in case of ordinary inheritance). But because of virtual inheritance
both 'A' and 'B' are supposed to _share_ their base class subobject 'X'.
For this reason, there's no way to fix it in both 'A' and 'B' anymore.
If you fix the position of 'X' inside 'A', it will become a run-time
value in 'B'. And vice versa.

Try drawing a memory layouts for standalone 'A' and 'B' and for 'A' and
'B' inside 'C' - it should become clear that there's no way to assign a
fixed compile-time position for 'X' in all these cases.