Virtual destructors

#2649

Author: pj@hrc63.co.uk (
Date: Mon, 27 Feb 1989 16:24

51 lines
1312 bytes


   Stroustrup does not seem to deal with the question of destructing derived
classes when all the calling function has is a pointer to the base class.  By
default only the base class destructor gets called.

In Oregon C++ (for Suns) v 1.1, it is possible to declare the base destructor
as virtual.  This then ensures that the appropriate destructor is called for
any derived classes provided that the _derived_class_has_a_destructor_.  If
the derived class has no explicit destructor then any member destructors will
not be called (rather than being called implicitly as they would be normally).

Does anyone know how other compilers behave?

e.g.

class Base {
    int foo;
public:
    Base( );
    virtual ~Base( ); // This is legal.
};


class Derived_1: Base {
    Problem mung; // Destructor should be called implicitly
public:
    Derived_1( ); // Constructor but no destructor
};


class Derived_2: Base {
    Problem mung; // Destructor should be called implicitly
public:
    Derived_2( ); // Constructor
    ~Derived_2( ); // and Destructor
};

main( ) {

    Base *p1, *p2;

    p1 = new Derived_1;
    p2 = new Derived_2; // p1 & p2 both point to base classes of Derived_1/2.

    delete p1; // Will not call Problem::~Problem.
    delete p2; // Will call Problem::~Problem.
};


//  Paul Johnson.

Re: Virtual destructors

#2670

Author: mball@cod.NOSC.M
Date: Wed, 01 Mar 1989 05:20

22 lines
1026 bytes

In article <551@hrc63.co.uk> pj@hrc63.co.uk (Mr P Johnson "Baddow") writes:
>In Oregon C++ (for Suns) v 1.1, it is possible to declare the base destructor
>as virtual.  This then ensures that the appropriate destructor is called for
>any derived classes provided that the _derived_class_has_a_destructor_.  If
>the derived class has no explicit destructor then any member destructors will
>not be called (rather than being called implicitly as they would be normally).

I believe this is a bug.  I will check on it and see that it gets handled
if it is.  This is the first time it has been reported, and it's not a
well-defined area of the language.  On logical grounds, though, it seems that
if the base class destructor is virtual the one generated for the derived
class should be as well.

Thanks for pointing it out.  If it turns out that the derived class shouldn't
be virtual, I'll make another posting on the subject.

Mike Ball
TauMetric Corporation
1094 Cudahy Place., Ste 302
San Diego, CA 92110
mball@cod.nosc.mil

Re: Virtual destructors

#2677

Author: rfg@riunite.ACA.
Date: Wed, 01 Mar 1989 23:24

43 lines
2403 bytes

In article <1430@cod.NOSC.MIL> mball@cod.nosc.mil.UUCP (Michael S. Ball) writes:
>In article <551@hrc63.co.uk> pj@hrc63.co.uk (Mr P Johnson "Baddow") writes:
>>In Oregon C++ (for Suns) v 1.1, it is possible to declare the base destructor
>>as virtual.  This then ensures that the appropriate destructor is called for
>>any derived classes provided that the _derived_class_has_a_destructor_.  If
>>the derived class has no explicit destructor then any member destructors will
>>not be called (rather than being called implicitly as they would be normally).
>
>I believe this is a bug.

I'm not sure what the "correct" semantics are myself, but I don't think it
is a bug.

I say that only because I have just recently been looking into the handling
of "virtual" in GNU G++ (and in particular the handling of "virtual" for
destructors) and I can tell you that G++ seems to do pretty much the same
thing as described above.  That is to say, if you have a base class which
has an explicitly virtual destructor, then the destructor will get a entry
in the vtable for that class.  Also, any classes derived from such a class
also (apparently) have entries for *their* destructors put into *their*
vtables (in the same slot number).  This seems to be true regardless of
whether or not the destructors in the derived classes explicitly have the
keyword "virtual" in their declarations.  Thus, it seems that these
destructors (in the derived classes) in effect become "implicitly"
virtual.

I also assume (but I have not yet checked) that (in G++) the destruction
of an object which has either an explicitly or implicitly virtual destructor
will be forced to go "indirect" through the vtable for that object.  If that
is true, then that means that the "appropriate destructor" should get called
for all such objects regardless of whether or not the compiler can "statically"
determine the actual class of an object which is being destroyed.

// Ron Guilmette  -  MCC  -  Experimental (parallel) Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
--
// Ron Guilmette  -  MCC  -  Experimental (parallel) Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg

Re: Virtual destructors

#2682

Author: mball@cod.NOSC.M
Date: Thu, 02 Mar 1989 22:25

32 lines
1564 bytes

In article <101@riunite.ACA.MCC.COM> rfg@riunite.UUCP (Ron Guilmette) writes:
>In article <1430@cod.NOSC.MIL> mball@cod.nosc.mil.UUCP (Michael S. Ball) writes:
>>In article <551@hrc63.co.uk> pj@hrc63.co.uk (Mr P Johnson "Baddow") writes:
>>>In Oregon C++ (for Suns) v 1.1, it is possible to declare the base destructor
>>>as virtual.  This then ensures that the appropriate destructor is called for
>>>any derived classes provided that the _derived_class_has_a_destructor_.  If
>>>the derived class has no explicit destructor then any member destructors will
>>>not be called (rather than being called implicitly as they would be normally).
>>
>>I believe this is a bug.
>
>I'm not sure what the "correct" semantics are myself, but I don't think it
>is a bug.

It is not a question of whether virtual destructors are allowed.  They are,
and should behave like all other virtual functions, which is to say that
references to them will normally go through the virtual table.  The problem,
which is what I said was a bug, is that the destructors generated by the
compiler were NOT being treated as virtual even though the base class
destructor WAS virtual.  Since a user destructor for the derived class will be
virtual, it seems only logical that the compiler-generated one will be as
well.  It is not being so treated in the current version Oregon C++.  I
have no idea what G++ does in that situation, and the data you included
does not cover this case.

Mike Ball
TauMetric Corporation
1094 Cudahy Pl. Ste 302
San Diego, CA 92110
(619)275-6381
mball@cod.nosc.mil

Re: Virtual destructors

#2693

Author: ejbjr@ihlpm.ATT.
Date: Fri, 03 Mar 1989 21:36

47 lines
2604 bytes

> I'm not sure what the "correct" semantics are myself, but I don't think it
> is a bug.
>
> I say that only because I have just recently been looking into the handling
> of "virtual" in GNU G++ (and in particular the handling of "virtual" for
> destructors) and I can tell you that G++ seems to do pretty much the same
> thing as described above.  That is to say, if you have a base class which
> has an explicitly virtual destructor, then the destructor will get a entry
> in the vtable for that class.  Also, any classes derived from such a class
> also (apparently) have entries for *their* destructors put into *their*
> vtables (in the same slot number).  This seems to be true regardless of
> whether or not the destructors in the derived classes explicitly have the
> keyword "virtual" in their declarations.  Thus, it seems that these
> destructors (in the derived classes) in effect become "implicitly"
> virtual.

If a function (any function, including a destructor) is declared
virtual in a base class, it will be virtual in all classes derived
from that base class.  I have not been able to find an explicit
statement of this rule in Stroustrups's book (though it might be
there somewhere), but some the examples make this behavior clear -
for instance, check out the example in section 7.2.8 on virtual
functions.  Function `print' in class  `employee' is declared as
virtual; in class `manager', derived from `employee', `print' is not
explicitly declared virtual.  It certainly would not make sense
for a non-virtual function to hide virtual functions - things just
would not work right.  The only other alternative would seem to be to
generate an error message if a virtual function in a derived class
was not explicitly declared virtual - something which is now out
of the question for compatability reasons.

I think we could use some better documentation about virtual
destructors though - its not obvious from the documentation that a
destructor can be declared virtual - BUT when should a destructor
not be virtual?  Can anyone give a reasonable example when the
destructor for a derived class should not be called when an object
from a base class is to be destroyed?  Perhaps either all destructors
should be automatically virtual (which has minor performance
implications for classes with no derived classes), or the documentation
should strongly advise making destructors virtual (or at least discuss
virtual destructors and when/why they should be used).
--
Jim Branagan
(312) 416-7408 (work)
(312) 810-0969 (home)
Remember - Good planets are hard to find - Be kind to Mom.

Re: Virtual destructors

#2697

Author: ark@alice.UUCP (
Date: Sat, 04 Mar 1989 04:15

37 lines
1700 bytes

In article <3130@ihlpm.ATT.COM>, ejbjr@ihlpm.ATT.COM (Branagan) writes:

> I think we could use some better documentation about virtual
> destructors though - its not obvious from the documentation that a
> destructor can be declared virtual - BUT when should a destructor
> not be virtual?  Can anyone give a reasonable example when the
> destructor for a derived class should not be called when an object
> from a base class is to be destroyed?

If you ever say `delete' to a pointer to a base class that
actually points to an object of a derived class, the base
class must have a virtual destructor.

This rule is actually a slight oversimplification, but it's
probably the right one to follow rather than trying to figure
out the obscure (and possibly nonportable) exceptions.

Why not make all destructors virtual?  Performance.  If there
are no other virtual functions in the base class, making the
destructor virtual adds a word of overhead per object.  This
can be substantial if you're defining little tiny objects.
Moreover, C++ tries to impose overhead in only the cases that
need it.

In principle, once you've declared a virtual destructor in a
base class, you do not need to redeclare it in any derived
classes unless you need to say something there.  However,
some versions of C++ have a bug that causes incorrect code to
be generated if there's a virtual destructor in the base class
and no destructor at all in the derived class.  Thus if you
have a virtual destructor in a base class, define a destructor
explicitly in all defined classes even if the destructor is empty.
You don't have to say it's virtual in the derived classes.
--
				--Andrew Koenig
				  ark@europa.att.com

🚀 go-pugleaf

Thread View: comp.lang.c++

Virtual destructors

Re: Virtual destructors

Re: Virtual destructors

Re: Virtual destructors

Re: Virtual destructors

Re: Virtual destructors

Thread Navigation