That portion of the standard is simply telling you that when you are constructing some "large" object J whose base class hierarchy includes multiple inheritance, and you are currently sitting inside the constructor of some base subobject H, then you are only allowed to use polymorphism of H and its direct and indirect base subobjects. You are not allowed to use any polymorphism outside that subhierarchy.
For example, consider this inheritance diagram (arrows point from derived classes to base classes)
![enter image description here]()
Let's say we are constructing a "large" object of type J. And we are currently executing the constructor of class H. Inside the constructor of H you are allowed to enjoy typical constructor-restricted polymorphism of the subhierarchy inside the red oval. For example, you can call virtual functions of base subobject of type B, and the polymorphic behavior will work as expected inside the circled subhierarchy ("as expected" means that the polymorphic behavior will go as low as H in the hierarchy, but no lower). You can also call virtual functions of A, E, X and other subobjects that fall inside the red oval.
However, if you somehow gain access to the hierarchy outside the oval and attempt to use polymorphism there, the behavior becomes undefined. For example, if you somehow gain access to G subobject from the constructor of H and attempt to call a virtual function of G - the behavior is undefined. The same can be said about calling virtual functions of D and I from the constructor of H.
The only way to obtain such access to the "outside" subhierarchy is if someone somehow passed a pointer/reference to G subobject into the constructor of H. Hence the reference to "explicit class member access" in the standard text (although it seems to be excessive).
The standard includes virtual inheritance into the example to demonstrate how inclusive this rule is. In the above diagram base subobject X is shared by both the subhierarchy inside the oval and subhierarchy outside the oval. The standard says that it is OK to call virtual functions of X subobject from the constructor of H.
Note that this restriction applies even if the construction of D, G and I subobjects has been finished before the construction of H began.
The roots of this specification lead to practical consideration of implementing polymorphic mechanism. In practical implementations the VMT pointer is introduced as a data field into the object layout of the most basic polymorphic classes in the hierarchy. Derived classes don't introduce their own VMT pointers, they simply provide their own specific values for the pointers introduced by the base classes (and, possibly, longer VMTs).
Take a look at the example from the standard. The class A is derived from class V. This means that the VMT pointer of A physically belongs to V subobject. All calls to virtual functions introduced by V are dispatched through VMT pointer introduced by V. I.e. whenever you call
pointer_to_A->f();
it is actually translated into
V *v_subobject = (V *) pointer_to_A; // go to V
vmt = v_subobject->vmt_ptr; // retrieve the table
vmt[index_for_f](); // call through the table
However, in the example from the standard the very same V subobject is also embedded into B. In order to make the constructor-restricted polymorphism work correctly, the compiler will place a pointer to B's VMT into VMT pointer stored in V (because while B's constructor is active V subobject has to act as part of B).
If at this moment you somehow attempt to call
a->f(); // as in the example
the above algorithm will find B's VMT pointer stored in its V subobject and will attempt to call f() through that VMT. This obviously makes no sense at all. I.e. having virtual methods of A dispatched through B's VMT makes no sense. The behavior is undefined.
This is rather simple to verify with practical experiment. Let's add its own version of f to B and do this
#include <iostream>
struct V {
virtual void f() { std::cout << "V" << std::endl; }
};
struct A : virtual V {
virtual void f() { std::cout << "A" << std::endl; }
};
struct B : virtual V {
virtual void f() { std::cout << "B" << std::endl; }
B(V*, A*);
};
struct D : A, B {
virtual void f() {}
D() : B((A*)this, this) { }
};
B::B(V* v, A* a) {
a->f(); // What `f()` is called here???
}
int main() {
D d;
}
You expect A::f to be called here? I tried several compilers, an all of them actually call B::f! Meanwhile, the this pointer value B::f receives in such call is completely bogus.
http://ideone.com/Ua332
This happens exactly for the reasons I described above (most compilers implement polymorphism the way I described above). This is the reason the language describes such calls as undefined.
One might note that in this specific example it is actually the virtual inheritance that leads to this unusual behavior. Yes, it happens exactly because the V subobject is shared between A and B subobjects. It is quite possible that without virtual inheritance the behavior would be much more predictable. However, the language specification apparently decided to just draw line the the way it is drawn in my diagram: when you are constructing H you are not allowed to step out of the "sandbox" of H's subhierarchy regardless of what inheritance type is used.
