From -645982794224054168
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,226361da392113b1,start
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1990-09-12 19:08:27 PST
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.std.c++
Subject: Pure virtual destructors: good or bad idea?
Message-ID: <77210003@hpclscu.HP.COM>
Date: 13 Sep 90 02:08:27 GMT
Organization: Hewlett-Packard Calif. Language Lab
Lines: 46
Posted: Thu Sep 13 03:08:27 1990

PURE VIRTUAL DESTRUCTORS:

One of our users came up with an interesting construct:

   class Base {
     virtual ~Base() = 0;	// pure virtual destructor
   };
   
   class Derived { /*...*/ };
   
   // ...
   Derived *p = new Derived();
   delete p;
   // ...

The problem is, cfront does not like pure virtual destructors. In fact, my
reading of the 2.1 ARM (section 12.4) seems to imply that since
"destructors cannot be inherited", such code should not make sense, because
making a function pure virtual means that you are forcing it to be
redefined in each of its derived classes, and since a destructor cannot be
redefined in a base class, this should be meaningless for destructors.

Indeed, it doesn't work: cfront emits a call to "Base::~Base()" when
deleting "p", which leads to a link-time unresolved).

The key point seems to be: the language insists that every class have a
destructor. There is *no way* for a user to say: "I don't want a destructor
function for this class. Just return the object to memory when "delete" is
called on this object".  Every destruction of an object unconditionally
generates a call to the destructor of each of its base classes, whether or
not they are "pure virtual".

How good (or bad) an idea is it to support such an extension to the meaning
of "= 0" on a virtual member function declaration? I mean, if the user
specifies a destructor as "pure virtual", then:

   (a) don't check for redefinitions in inherited classes (cfront doesn't
       do this now, anyway), *and*,
   (b) don't emit any calls to that destructor, when an object of a class
       inherited from it is destroyed.

Seems easy enough to do - is there any major semantic problem with this?
-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar