[gnu.g++.bug] bug with virtual destructors

salzman%iris@RAND.ORG (Isaac) (09/19/89)

i think i've found a bug in the implementation of virtual destructors for
g++ 1.35.0 and 1.36.0- (late august version?). i've tested the following
code with both versions of g++, and with Oasys (basically cfront 1.2):

/* test virtual destructor bug in g++ */


#include <stdio.h>

class A
{
  private:
    int i;
  public:
    A(int);
#ifdef VDEST
    virtual ~A();
#else
    ~A();
#endif
    virtual void showval();
};

class B : public A
{
  private:
    int ii;
  public:
    B(int, int);
#ifdef VDEST
    virtual ~B();
#else
    ~B();
#endif

    void showval();
};

A::A(int pi)
{
    i = pi;
}

A::~A()
{
    printf("destructor for A\n");
    showval();
}

void A::showval()
{
    printf("A::i = %d\n",i);
}

B::B(int pi, int pii) : (pi)
{
    ii=pii;
}


B::~B()
{
    printf("destructor for B\n");
    showval();
}

void B::showval()
{
    printf("B::ii = %d\n",ii);
}

main()
{
    A *ap;

    ap = new B(10,20);

    delete ap;
}

    
    
    
----------------------

the destructors for both class A and class B call the showval() method.
ap is holding a pointer to a B. if virtual destructors are NOT used,
the output will be (in both cases):

	destructor for A
	B::ii = 20

which is correct; ap is really a B, so the showval for B should be called.

if the example is compiled with -DVDEST and uses virtual destructors,
the following is output from cfront:

	destructor for B
	B::ii = 20
	destructor for A
	B::ii = 20

it calls the B destructor, then the A destructor, and B::showval() in both
cases because ap is a B.

but, this is what we get with g++:

	destructor for B
	B::ii = 20
	destructor for A
	A::i = 10

it calls the correct destructors in the correct order, but all of a sudden
ap has become an A instead of a B, which I don't think is correct behavior,
unless this has changed in cfront 2.0.... this actually makes some logical
sense, since coming out of the destructor for B, ap is no longer a B
anymore, right?? so either g++ is extremely smart and cfront 1.2 is bugged,
or cfront 1.2 is correct and g++ is slightly bugged.... any comments??

--
* Isaac J. Salzman                                            ----     
* The RAND Corporation - Information Sciences Dept.          /o o/  /  
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138    | v |  |  
* AT&T      : +1 213-393-0411 x6421 or x7923 (ISL lab)      _|   |_/   
* Internet  : salzman@rand.org                             / |   |
* UUCP      : !uunet!rand.org!salzman                      | |   |     
* CompuServe: 76167,1046

tiemann@SUN.COM (Michael Tiemann) (09/19/89)

    it calls the correct destructors in the correct order, but all of a sudden
    ap has become an A instead of a B, which I don't think is correct behavior,
    unless this has changed in cfront 2.0.... this actually makes some logical
    sense, since coming out of the destructor for B, ap is no longer a B
    anymore, right?? so either g++ is extremely smart and cfront 1.2 is bugged,
    or cfront 1.2 is correct and g++ is slightly bugged.... any comments??
cfront 1.2 is bugged.

Michael