Re: Doubt regarding Virtual Inheritance
On Jul 6, 12:16 pm, Anarki <Deepchan...@gmail.com> wrote:
#include <iostream>
using namespace std;
class A
{};
class B:virtual public A
{};
class C:virtual public A
{};
class D:public B, public C
{
};
int main()
{
cout << "Sizeof(A) " << sizeof(A) << endl;
cout << "Sizeof(B) " << sizeof(B) << endl;
cout << "Sizeof(C) " << sizeof(C) << endl;
cout << "Sizeof(D) " << sizeof(D) << endl;
return 0;}
usually virtual inheritance comes into action to resolve the ambiguty
of data access of grandparent class when there exist more than 1 path
between grandparent and grandchild.
Ok i take it as granted VI resolves data access ambiguity.
I don't seem much relationship between resolving ambiguity and
virtual inheritance. Virtual inheritance affects the form of
the inheritance lattice. Design determines which form you want.
If the resulting form results in ambiguities, you use scope
resolution operators to resolve them, possibly introducing
additional intermediate classes. You do not change the
inheritance lattice without modifying the overall design.
But please take look at the output of the program i gave
1
4 //Any virtual pointer to a virtual function table? Note i havent
specified and virtual functions
4 //Any virtual pointer to a virtual function table? Note i havent
specified and virtual functions
8 //Two vptrs of B and C??
if there are vptrs what is their role in avoiding the data access
ambiguity?
I'm afraid I don't even understand the question. Most
implementations today use a single vptr to a table with all RTTI
information. What the vtbl actually contains will vary a lot
from one implementation to the next, however.
One effect that virtual inhertance does have is that it means
that the compiler cannot staticly know where the base class is
situated compared to the derived class, so the compiler must use
dynamic RTTI to convert derived to base. Thus, in your example
above, if the complete object has type B, in a typical
implementation, the A subobject will immediately follow the B
specific data in the object. In a complete object of type D,
however, the A subobject of the B subobject will generally
follow both the B and the C subobjects, as well as any data
specific to D. Given a B*, the compiler doesn't know which case
holds, so it will use RTTI to determine where the A subobject
is, relative to the address it has. And in order to do this, it
will probably need a vptr in the object.
Note that such analysis is much simpler if you insert a
ptruint_t in each object, initializing it with a different value
each time. You can then dump the object as an array of
ptruint_t (undefined behavior, but in practice, it will work),
and see where each sub-object is situated. Also, cast a pointer
to the object to each of the sub-object types, and output that
(as a void*). Then create objects of all the types involved,
and see how the layout of a B as most derived class is different
from that of a B sub-object in a D.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34