[comp.lang.c++] Wrong delta in virtual table

chang@osc.COM (Lai-Chang Woo) (02/05/91)

Hello all

I am having a nightmarish time with Glockenspiel C++ on DEC/Ultrix 4.0 and
just wonder if anyone out there has some hints/suggestions/sympathies to
offer.  Here's the problem:

A simple program fails with segmentation fault.  I run it under dbx, examine
argument values and find one of the methods "compare" is passed a wrong "this"
pointer.  I go up one frame and discover the apparent cause of it: the delta
value used to compute "this" for this particular virtual function is wrong.
I then changed the delta value, and bingo!  Case verified.  Now the headache:
is the Glockenspiel translator to be blamed, or am I doing something to cause
this wrong computation?

I have a class hierachy which goes like this:

class A
{
    // definitions
}

class B : virtual public A
{
    // some definitions preceeding
    // first definition of compare method
    virtual int compare(const B&) const = 0;
}

class Person : virtual public B
{
    // some definitions preceeding
    // overriding definition of compare
    virtual int compare(const B&) const;
}

class Employee : public Person
{
    // some method definitions
    // no definition for compare here
}

The translated C code has virtual tables like these:

struct __mptr __vtbl__6B__8Employee[] = {0,0,0,
-20,0,(__vptp)methA__8EmployeeCFv,
-20,0,(__vptp)methB__8EmployeeCFv,
0,0,(__vptp)methC__6BCFv,
-4,0,(__vptp)compare__6PersonCFRC6B,	<-- offensive line, works when -4 is
...					    changed to -20 !!
0,0,0);

struct __mptr __vtbl__6B__6Person[] = {0,0,0,
-16,0,(__vptp)methA__6PersonCFv,
-16,0,(__vptp)methB__6PersonCFv,
0,0,(__vptp)methC__6BCFv,
-16,0,(__vptp)compare__6PersonCFRC6B,
...
0,0,0);

I am rather new to C++ and don't fully understand the intricacies of the
virtual tables, but it appears the translator has either omitted to add -16
to -4, or done an extra subtraction of -16 from -20.  Either way, the value
calculated by the translator is always the difference; I have verified this
point by altering the class definitions such that a whole different set of
offsets are computed.

Has anybody come across this before?  Email replies to "chang%osc.osc.com@
uunet.uu.net" would be appreciated.  Thanks in advance.