Ripunjay Tripathi
12/17/2008 4:00:00 AM
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