🚀 go-pugleaf

In article <6334@transfer.stratus.com>, lee@bluefuzz.sw.stratus.com (Lee Cooprider) writes:
|> I am using C++ from gcc version 2.2.1 on a Sparc platform.
|> 
|> My problem is with virtual destructors.  Whenever my real destructor is
|> called, the program abort()'s after executing the destructor successfully.
|> 
|> This program illustrates the problem:
|> 
|> 	class aaa {
|> 	  public:
|> 	    virtual ~aaa() = 0;};
|> 	
|> 	class bbb : public aaa {
|> 	  public:
|> 	    bbb();
|> 	    ~bbb();};
|> 	
|> 	bbb::bbb() {}
|> 	bbb::~bbb() {}
|> 
|> The assembler for ~bbb() has an unconditional abort() call at the end.  Is
|> this the correct code?  Is there an additional requirement on virtual
|> destructors?  Is it not legal for a destructor to be pure-virtual?

This is a bug in g++. The way cfront works (which is apparently the correct
way, although I haven't found a convincing explanation of why) is that a
definition of aaa::~aaa(){} is needed even though it is pure, because derived
class destructors always produce an implicit call to their base class destructors.
cfront gives a warning during compilation saying that the definition must be
provided.

----------------------------------------------------------------------
  \\ !Vote Libertarian! \\ Peter McCluskey  \\ !Vote Libertarian! \\
  // Vote Marrou in `92 // pcm@cs.brown.edu // Vote Marrou in `92 //
----------------------------------------------------------------------