🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2517

Re: Virtual functions and destructors

#2517
From: Chris Parker
Date: Fri, 10 Nov 1995 01:08
58 lines
3849 bytes
> > Is it acceptable according to the standard for the destructor to be the onl
y
> > virtual member in the class?
> 
> Sure, but it's kind of pointless.  You only need a virtual destructor 
> when you will be handling objects of a derived class through a pointer or 
> reference whose static type is some base class, and in that case you will 
> (nearly?) always need other virtual functions to provide the polymorphic 
> interface that you'll use.  The only exception I can imagine offhand 
> would be if you were doing nothing but holding a bunch of them, as in a 
> collection of some sort; but how could you ever do anything to the 
> collected objects without virtual functions?  Seems to me that the only 
> thing you could do if they have no virtual function except the destructor 
> is delete them, and if that's all you're doing... well, I suppose there 
> could be some reason for deferring deletion for a bunch of mixed 
> objects.  It just doesn't seem real likely to me that that woudl be the 
> ONLY action you'd want to take on them in a polymorphic fashion.
> 
> But it's certainly legal to have only the destructor virtual.

You can do polymorphic things without any virtual functions.  Casting a child
to a parent which has no virtual functions makes the class behave like it was
a class of that parent.  You might want to delete it while it has been the
parent in a polymorphic sense.  Thus, the destructor is the only virtual 
function.  

> > Is virtualness inherited by destructors?  Does C++ automatically make all 
> > applicable superclasses also have virtual destructor if they don't already?

> 
> Is there any inheritance of anything from subclass to superclass?  Or did 
> you mean to write "subclass" there?  Inheritance goes in only one 
> direction: a class derived from a base class with a virtual destructor 
> will have a virtual destructor.  Deriving a class whose destructor is 
> declared virtual from a base class with a non-virtual destructor doesn't 
> magically change the base class in this respect (nor any other).

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.

> dispatch.  No magic, an object's actual type cannot affect anything done 
> to it through a pointer or reference of a base type unless the operation 
> is through a function that is virtual in that base type.

	The thing that doesn't work for me is that the pointer type is 
different, but it still has the same pointer value.  At the low-level, you
are freeing the same block of memory either way.  In order to 
call a destructor, the system needs to convert the pointer to a class type
instance anyway.

							Chris Parker
                                                        parker@cs.wpi.edu
---
[ 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. ]
Technical Details
Message-ID: <199511091835.NAA11661@starling.WPI.EDU>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
Date: 10 Nov 95 01:08:31 GMT
Approved: fjh@cs.mu.oz.au
Organization: -
Newsgroups: comp.std.c++
From: Chris Parker <parker@owl.WPI.EDU>
Message-ID: <199511091835.NAA11661@starling.WPI.EDU>
Subject: Re: Virtual functions and destructors
X-Original-Date: Thu, 9 Nov 1995 13:35:41 -0500 (EST)
In-Reply-To: <m0tDb84-000IDUC@venus.mcs.com> from "Martin J. Maney" at Nov 9, 95 11:51:00 am
X-Mailer: ELM [version 2.4 PL22]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMKKmNeEDnX0m9pzZAQHqGQF9HreNuQwlr1jPvMUz4zldMOcJKDbiDu0l
 Zf87I7eoUE9Bhbvm9vPF+LGQngvEUcZc
 =UGSi