Re: Delegation through pure virtual
On May 5, 7:28 am, aksinghdce <aksingh...@gmail.com> wrote:
On May 3, 5:49 pm, James Kanze <james.ka...@gmail.com> wrote:
On May 3, 8:35 am, Juha Nieminen <nos...@thanks.invalid> wrote:
aksinghdce <aksingh...@gmail.com> wrote:
The constructor of Join set the vptr of Der1 and Der2 to point
to vtable which are valid for Der1 and Der2 which are members of
Join.
Thats a real nice explanation. I would like to learn more about this;
please do me a favor and suggest me a book and/or an article or such
so as to let me dive deeper. Thanks a ton :)
Perhaps the confusion stems from not realizing that objects
instantiated from classes with virtual functions have a vtable
pointer inside them (in practice almost always at the very
beginning of the memory block occupied by the object). This
means that the the instantiations (ie objects) of the same
class can actually point to *different* vtables. (The
structure of these vtables is obviously always the same, but
their content can differ, ie. the function pointers inside
them can point to different functions.)
How virtual functions are handled (even in diamond inheritance
situations) is rather simple, relatively speaking.
Finding the actual address of the function to be called is
rather simple. Finding the value to pass as the this pointer
can be somewhat more complicated, at least when virtual
inheritance is involved (since the offset with respect to the
base pointer is no longer a constant).
Tried to correlate these concepts with GDB. Created a document. This
again lead me to a confusion zone.
There are two cases in case of virtual inheritance:
1. The tip-of-the-diamond class has data members
2. The tip-of-the-diamond class has no data members
At least in the past, most compilers didn't make this
distinction.
In the 2nd case I don't see any v-pointer corresponding to Der1 and
Der2. In place of Der1 v-pointer there is an invalid address. Should I
conclude that the _vptr$Base points to the v-table containing the
methods of all the intermediate derived classes, for instance, Der1
and Der2 in our example code?
In your example, the compiler has a lot of options with regards
to optimizing the use of vtables (and vptr). Adding data would
eliminate some of them. (With no data, I think that the
compiler could use empty base class optimization to put the
start of all four classes at the same address. With data,
practically speaking, only Der1 and Join could share an
address.)
The traditional layout would be something like:
+-----------------+
| vptr, Der1+Join | <--- address Der1, Join
+-----------------+
| Der1 data |
+-----------------+
| vptr, Der2 | <--- address Der2
+-----------------+
| Der2 data |
+-----------------+
| Join data |
+-----------------+
| vptr, Base | <--- address Base
+-----------------+
| Base data |
+-----------------+
The respective vtable would contain the addresses of the various
virtual functions, but also information for RTTI, the position
of Base relative to the position of the vptr, and for each
function, how to obtain a correct this pointer. Thus, if we
assume that the vptr has a size of 4, and that each class has 4
bytes of class specific data, and that there are no additional
alignment requirements (in other words, that each rectangle
above represents 4 byts), the vtable pointed to by the first
vptr might look like:
__vtable_Join:
&__rttiInfo_Join,
20,
&Der1::foo
0
&Der2::bar
8
&Join::junk
0
The second would be:
__vtable_Der2__in__Join:
&__rttiInfo_Join,
12,
&Der1::foo
-8
&Der2::bar
0
And the last:
__vtable_Base__in__Join:
&__rttiInfo_Join,
0,
&Der1::foo
-20
&Der2::bar
-12
This layout can handle all hierarchies (although it gets more
complicated when there are several virtual bases---quite likely,
the offset to find the virtual bases will be handled
differently, to provide for this: IIRC, CFront used a separate
pointer, in each class, for each virtual base). Given that
neither Der1 nor Der2 introduce any additional virtual
functions, if they had no data, it would be possible to merge
them, and only use a single vtable for Join for both of them.
It might even be possible to merge Base with both of them, and
use just a single vtable.
Which v-table points to the function defined only in the Join class,
for instance, Join::junk()?
None. As I've already said several times, at least one base
class will typically share the vtable with the derived class.
--
James Kanze