🚀 go-pugleaf

John Max Skaller <maxtal@suphys.physics.su.oz.au> says:
>
>Chris Parker <parker@owl.WPI.EDU> wrote:
>>
>>I did mean superclass when I said it.  Based on what I've learned by thinking
>>about these things, I'm pretty convinced that all destructors should be
>>virtual all the time (implied).  I can't find a single case where it would 
>>make sense to destroy an object and not have all proper cleanup happen.
>
>Yes, but "safe cleanup" != "virtual destructor".
>In particular, a single stand alone class such 
>as "complex" doesn't need a virtual destructor
>because it is neither derived from nor is intended
>to be a base of, another class.
>
>Since on many systems virtual destructors
>greatly increase the costs associated
>with an object (size, dispatch efficiency, etc),
>there's a performance reason (as well as the
>obvious layout control reason) for not
>coding a virtual destructor in a class.
>
>{But I'm not disagreeing that in principle
>all destructors should act as if virtual}

Hmmm, this really sounds like a case of "do I plan for reuse now, or
wait until I need to reuse and then double check all of my parent
classes" -- both approaches have their merits.

What you can do if the cost of virtual destructors on standalone
classes concerns you, yet you or someone else *may* derive from them
at some point in time, is to wrap the virtual keyword like so:

class A
  {
  A();
  ...
#if defined(STRICT_VIRTUAL)
  virtual
#endif
  ~A();
  ...
  };

As ugly as using proprecessor symbols can be at least this gets around
around the problem.  Define STRICT_VIRTUAL in your header file before
including A.h and deriving from it.  Then #undef STRICT_VIRTUAL when
you're done to implement on a case-by-case basis.  Otherwise, put a 
-DSTRICT_VIRTUAL on the compiler command line for all cases.

Bill
=============================================================================
William D. Mooney       | email: wmooney@shl.com or 74353.1325@compuserve.com
                        | phone: 407.888.1829
SHL Systemhouse, Inc.   | fax:   407.888.2259
=============================================================================

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]