When to use virtual destructors?
Asked Answered
O

21

1896

I have a solid understanding of most OOP theory but the one thing that confuses me a lot is virtual destructors.

I thought that the destructor always gets called no matter what and for every object in the chain.

When are you meant to make them virtual and why?

Oldfangled answered 20/1, 2009 at 12:58 Comment(10)
See this: Virtual DestructorPeridot
Every destructor down gets called no matter what. virtual makes sure it starts at the top instead of the middle.Hyoscyamine
related question: When should you not use virtual destructors?Frye
@MooingDuck that's somewhat misleading comment.Outman
@EuriPinhollow Mind elaborating?Saliva
@FranklinYu it's good that you asked because now I can't see any issue with that comment (except trying to give answer in comments).Outman
@FranklinYu I probably thought about that there should be more specific claim (i.e. when destruction can start in the middle of inheritance tree instead of top) but that's what answers already elaborate.Outman
I'm also confused by @MooingDuck 's answer. Shouldn't it be up instead of down, if you use the notion of subclass (under) and superclass (above)?Penniepenniless
@Nibor: Yes, if you use that notion. About half the people I talk to view superclasses as "above", and half view superclasses as "below", so both are conflicting standards, which makes everything confusing. I think superclass as "above" is slightly more common, but that's not the way I was taught :(Hyoscyamine
@betteroutthanin Why did you add the [shared-ptr] tag? This question isn't directly related to smart pointers.Smut
D
1930

Virtual destructors are useful when you might potentially delete an instance of a derived class through a pointer to base class:

class Base 
{
    // some virtual methods
};

class Derived : public Base
{
    ~Derived()
    {
        // Do some important cleanup
    }
};

Here, you'll notice that I didn't declare Base's destructor to be virtual. Now, let's have a look at the following snippet:

Base *b = new Derived();
// use b
delete b; // Here's the problem!

Since Base's destructor is not virtual and b is a Base* pointing to a Derived object, delete b has undefined behaviour:

[In delete b], if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

In most implementations, the call to the destructor will be resolved like any non-virtual code, meaning that the destructor of the base class will be called but not the one of the derived class, resulting in a resources leak.

To sum up, always make base classes' destructors virtual when they're meant to be manipulated polymorphically.

If you want to prevent the deletion of an instance through a base class pointer, you can make the base class destructor protected and nonvirtual; by doing so, the compiler won't let you call delete on a base class pointer.

You can learn more about virtuality and virtual base class destructor in this article from Herb Sutter.

Diffractometer answered 20/1, 2009 at 13:4 Comment(16)
This would explain why i had massive leaks using a factory i made before. All makes sense now. ThanksOldfangled
Well, this is a bad example as there are no data members. What if Base and Derived have all automatic storage variables? ie there is no "special" or additional custom code to execute in the destructor. Is it ok then to leave off writing any destructors at all? Or will the derived class still have a memory leak?Crashland
Wait, it will be undefined behaviorCrashland
@workmad3 non-virtual is not necessary for that, is it? Useless maybe, but not required to be absent.Blunge
when there are only simple data types (no pointers for example), do we still expect to have memory leak if not using virtual destructors ?Grower
@ransh: as @Crashland already said in a previous comment, even if the classes have no member variables, calling delete on a Base* that points to a Derived object is undefined behavior. This means that the program can do anything, including leaking memory.Diffractometer
From the Herb Sutter's article: "Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual."Toomer
Also from the article - 'if you delete polymorphically without a virtual destructor, you summon the dreaded specter of "undefined behavior," a specter I personally would rather not meet in even a moderately well-lit alley, thank you very much.' lolPractice
@Toomer Kindly explain the protected and non-virtual part.Plasm
@Jos: From the article: "In brief, then, you're left with one of two situations. Either: a) you want to allow polymorphic deletion through a base pointer, in which case the destructor must be virtual and public; or b) you don't, in which case the destructor should be nonvirtual and protected, the latter to prevent the unwanted usage."Toomer
To clarify, it sounds like a virtual destructor is needed if the type will be passed to delete when it was allocated as a derived type. The derived type does not need a virtual destructor, unless the same applies to it. So a final class never needs a virtual destructor, even if it derives from a class that has one.Adminicle
@Adminicle If a class D derives from a class B with a virtual destructor, then D has a virtual destructor as well, even if it doesn't declare one explicitly. Most of the time only the class at the top of the hierarchy needs to declare a virtual destructor, not the rest of the hierarchy.Diffractometer
@Luc Touraille: yes, your conclusion solves my confusion. Any non-abstract class can always be instantiated. So to prevent this 'undefined behavior', any non-abstract class should always be defined with virtual destructor. But most of the classes I worked with do not have a virtual destructor at all. So maybe, one of their base classes have one already!Nester
Strange, why in all discussions about "virtual ~" mentioned only heap objects. For example: If we are planning to use objects only in the stack, the base class can omit virtualization. BderiveA objB;// For class 'A' no need virtual ~.Valery
@LucTouraille If there is no virtual member function in the said code snippet. Do I still need to mark the destructor of the base class as virtual function? Looking forward for your reply.Dangle
@Dangle yes you do, the presence or absence of other virtual members doesn't change the requirement: you would still have undefined behavior if you deleted a Derived object from a Base pointer.Diffractometer
C
319

A virtual constructor is not possible but virtual destructor is possible. Let us experiment.......

#include <iostream>

using namespace std;

class Base
{
public:
    Base(){
        cout << "Base Constructor Called\n";
    }
    ~Base(){
        cout << "Base Destructor called\n";
    }
};

class Derived1: public Base
{
public:
    Derived1(){
        cout << "Derived constructor called\n";
    }
    ~Derived1(){
        cout << "Derived destructor called\n";
    }
};

int main()
{
    Base *b = new Derived1();
    delete b;
}

The above code output the following:

Base Constructor Called
Derived constructor called
Base Destructor called

The construction of derived object follow the construction rule but when we delete the "b" pointer(base pointer) we have found that only the base destructor is called. But this must not happen. To do the appropriate thing, we have to make the base destructor virtual. Now let see what happens in the following:

#include <iostream>

using namespace std;

class Base
{ 
public:
    Base(){
        cout << "Base Constructor Called\n";
    }
    virtual ~Base(){
        cout << "Base Destructor called\n";
    }
};

class Derived1: public Base
{
public:
    Derived1(){
        cout << "Derived constructor called\n";
    }
    ~Derived1(){
        cout << "Derived destructor called\n";
    }
};

int main()
{
    Base *b = new Derived1();
    delete b;
}

The output changed as following:

Base Constructor Called
Derived Constructor called
Derived destructor called
Base destructor called

So the destruction of the base pointer (which takes an allocation on derived object!) follows the destruction rule, i.e first the Derived, then the Base. On the other hand, there is nothing like a virtual constructor.

Cristophercristy answered 9/4, 2013 at 13:39 Comment(6)
" virtual constructor is not possible" means you need not write virtual constructor by your own. Construction of derived object must follow the chain of construction from derived to base. So you need not write the virtual keyword for your constructor. ThanksCristophercristy
@Murkantilism, "virtual constructors cannot be done" is true indeed. A constructor cannot be marked virtual.Mcnutt
@cmeub, But there is an idiom to achieve what you would want from a virtual constructor. See parashift.com/c++-faq-lite/virtual-ctors.htmlInsphere
@TunvirRahmanTusher could you please explain why the Base Destructor is called??Beef
@rimiro Its automatic by c++.you can follow the link #678120Cristophercristy
the first example that has no virtual destructor in the base UB no?Olympias
H
223

Declare destructors virtual in polymorphic base classes. This is Item 7 in Scott Meyers' Effective C++. Meyers goes on to summarize that if a class has any virtual function, it should have a virtual destructor, and that classes not designed to be base classes or not designed to be used polymorphically should not declare virtual destructors.

Hereditament answered 20/1, 2009 at 13:11 Comment(7)
+"If a class has any virtual function, it should have a virtual destructor, and that classes not designed to be base classes or not designed to be used polymorphically should not declare virtual destructors.": Are there cases in which it makes sense to break this rule? If not, would it make sense to have the compiler check this condition and issue an error is it is not satisfied?Stoffel
@Stoffel I don't know of any exceptions to the rule. But I wouldn't rate myself as a C++ expert, so you may want to post this as a separate question. A compiler warning (or a warning from a static analysis tool) makes sense to me.Hereditament
Classes can be designed not to be deleted through a certain type's pointer, yet still have virtual functions - typical example is a callback interface. One does not delete his implementation through a callback interface pointer as that's only for subscribing, but it does have virtual functions.Bathetic
@Bathetic Exactly - that or all the many other situations where we use polymorphic behaviour but don't perform storage management via pointers - e.g. maintaining automatic or static-duration objects, with pointers only used as observation routes. No need/purpose in implementing a virtual destructor in any such cases. Since we're just quoting people here, I prefer Sutter from above: "Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual." The latter ensures anyone accidentally trying to delete via a base pointer is shown the error of their waysLaddie
@Stoffel There is actually a trick one can use and avoid a virtual call to a destructor: bind via a const reference a derived object to a base, like const Base& = make_Derived();. In this case, the destructor of the Derived prvalue will be called, even if it's not virtual, so one saves the overhead introduced by vtables/vpointers. Of course the scope is quite limited. Andrei Alexandrescu mentioned this in his book Modern C++ Design.Thole
@Stoffel there is a warning in gcc for just this situation. dascandy they initially failed to consider your point as documented here.Alt
Why do things work if there is no virtual method without a polymorphic destructor? EDIT answer: they don't, but in that case, you would never need to write Base *b = new Derived1, which is the source of all problems, but rather Derived1 *b = new Derived1. Also, without new, there can be no problems, as the compiler always knows the real type of whatever goes out of scope.Gibberish
L
49

Make the destructor virtual whenever your class is polymorphic.

Lintwhite answered 20/1, 2009 at 13:1 Comment(1)
As the accepted answer says, you actually need to make your destructor virtual whenever you inherit from the class and will call delete from a base class pointer to it. (ie you should almost always make your dtor virtual)Crashland
B
49

Also be aware that deleting a base class pointer when there is no virtual destructor will result in undefined behavior. Something that I learned just recently:

How should overriding delete in C++ behave?

I've been using C++ for years and I still manage to hang myself.

Bree answered 21/1, 2009 at 1:9 Comment(3)
I had a look at that question of yours and saw that you had declared the base destructor as virtual. So does "deleting a base class pointer when there is no virtual destructor will result in undefined behavior" stay valid with respect to that question of yours? Since, in that question, when you called delete, the derived class (created by its new operator) is checked for a compatible version first. Since it found one there, it was called. So, don't you think it would be better to say as "deleting a base class pointer when there is no destructor will result in undefined behavior"?Dennett
Thats pretty much the same thing. The default constructor is not virtual.Bree
@Bree "hang myself"? You mean memory leaking?Dangle
A
18

Calling destructor via a pointer to a base class

struct Base {
  virtual void f() {}
  virtual ~Base() {}
};

struct Derived : Base {
  void f() override {}
  ~Derived() override {}
};

Base* base = new Derived;
base->f(); // calls Derived::f
base->~Base(); // calls Derived::~Derived

Virtual destructor call is no different from any other virtual function call.

For base->f(), the call will be dispatched to Derived::f(), and it's the same for base->~Base() - its overriding function - the Derived::~Derived() will be called.

Same happens when destructor is being called indirectly, e.g. delete base;. The delete statement will call base->~Base() which will be dispatched to Derived::~Derived().

Abstract class with non-virtual destructor

If you are not going to delete object through a pointer to its base class - then there is no need to have a virtual destructor. Just make it protected so that it won't be called accidentally:

// library.hpp

struct Base {
  virtual void f() = 0;

protected:
  ~Base() = default;
};

void CallsF(Base& base);
// CallsF is not going to own "base" (i.e. call "delete &base;").
// It will only call Base::f() so it doesn't need to access Base::~Base.

//-------------------
// application.cpp

struct Derived : Base {
  void f() override { ... }
};

int main() {
  Derived derived;
  CallsF(derived);
  // No need for virtual destructor here as well.
}
Anglo answered 18/5, 2015 at 13:38 Comment(3)
Is it necessary to explicitly declare ~Derived() in all derived classes, even if it's just ~Derived() = default? Or is that implied by the language (making it safe to omit)?Illyria
@Wallacoloo no, only declare it when it's necessary. E.g. to put in protected section, or to ensure that it's virtual by using override.Anglo
@Anglo Is it sutiable to call base->~Base()? As per what you said, the Base::~Base() would not be invoked, then there would be memory leaking. Am I right?Dangle
E
16

Virtual keyword for destructor is necessary when you want different destructors should follow proper order while objects is being deleted through base class pointer. for example:

Base *myObj = new Derived();
// Some code which is using myObj object
myObj->fun();
//Now delete the object
delete myObj ; 

If your base class destructor is virtual then objects will be destructed in a order(firstly derived object then base ). If your base class destructor is NOT virtual then only base class object will get deleted(because pointer is of base class "Base *myObj"). So there will be memory leak for derived object.

Epps answered 29/1, 2015 at 7:11 Comment(0)
Z
13

To be simple, Virtual destructor is to destruct the resources in a proper order, when you delete a base class pointer pointing to derived class object.

 #include<iostream>
 using namespace std;
 class B{
    public:
       B(){
          cout<<"B()\n";
       }
       virtual ~B(){ 
          cout<<"~B()\n";
       }
 };
 class D: public B{
    public:
       D(){
          cout<<"D()\n";
       }
       ~D(){
          cout<<"~D()\n";
       }
 };
 int main(){
    B *b = new D();
    delete b;
    return 0;
 }

OUTPUT:
B()
D()
~D()
~B()

==============
If you don't give ~B()  as virtual. then output would be 
B()
D()
~B()
where destruction of ~D() is not done which leads to leak

Zinkenite answered 26/8, 2016 at 5:33 Comment(4)
Not have the base virtual destructor and calling delete on a base pointer leads to undefined behavior.Liggins
@JamesAdkison why does it lead to undefined behaviour??Beef
@rimiro It's what the standard says. I don't have a copy but the link takes you to a comment where someone references the location within the standard.Liggins
@rimiro "If deletion, therefore, can be performed polymorphically through the base class interface, then it must behave virtually and must be virtual. Indeed, the language requires it - if you delete polymorphically without a virtual destructor, you summon the dreaded specter of "undefined behavior," a specter I personally would rather not meet in even a moderately well-lit alley, thank you very much." (gotw.ca/publications/mill18.htm) -- Herb SutterLiggins
U
10

I like to think about interfaces and implementations of interfaces. In C++ speak interface is pure virtual class. Destructor is part of the interface and expected to implemented. Therefore destructor should be pure virtual. How about constructor? Constructor is actually not part of the interface because object is always instantiated explicitly.

Until answered 8/11, 2012 at 16:28 Comment(3)
It's a different perspective on the same question. If we think in terms of interfaces instead of base class vs derived class then it's natural conclusion: if it's a part of the interface than make it virtual. If it's not don't.Until
+1 for stating the similarity of the OO concept of interface and a C++ pure virtual class. Regarding destructor is expected to be implemented: that is often unnecessary. Unless a class is managing a resource such as raw dynamically allocated memory (e.g., not via a smart pointer), a file handle or a database handle, using the default destructor created by the compiler is fine in derived classes. And note that if a destructor (or any function) is declared virtual in a base class, it is automatically virtual in a derived class, even if it is not declared so.Siple
This misses the crucial detail that the destructor is not necessarily part of the interface. One can easily program classes that have polymorphic functions but which the caller does not manage/is not allowed to delete. Then a virtual destructor has no purpose. Of course, to ensure this, the non-virtual - probably default - destructor should be non-public. If I had to guess, I'd say such classes are more often used internally to projects, but that doesn't make them any less relevant as an example/nuance in all this.Laddie
N
6

I propose the following: If a class or struct is not declared as final, it should have a virtual destructor.

Although it might seem unnecessarily cautious to adopt this as a rule of thumb, it's the only way to ensure that subclasses derived from your class will not cause undefined behavior (UB) when deleted via a base pointer.

Scott Meyers, in Effective C++, provides a useful guideline:

if a class has any virtual function, it should have a virtual destructor, and that classes not designed to be base classes or not designed to be used polymorphically should not declare virtual destructors.

Defining a virtual function in a class somewhat signals the intention that the class is suitable for use as a base class in a polymorphic context. In contrast, the absence of virtual functions does not clearly convey this intent, and the compiler will not issue an error if the class is used polymorphically. While it's not possible to enforce polymorphic suitability through compiler checks when virtual functions are absent, you can clearly communicate that a class is not designed to be a base class by marking it with the final keyword.

Consider the scenario below where the base class B does not include any virtual functions. According to Meyers' recommendation, a virtual destructor might seem unnecessary. But omitting it will cause undefined behavior.

#include <iostream>

struct A
{
    ~A()
    {
        std::cout << "A::~A()" << std::endl;
    }
};

struct B
{
};

struct C : public B
{
    A a;
};

int main(int argc, char *argv[])
{
    B *b = new C;
    delete b; // UB, and won't print "A::~A()"
    return 0;
}
Nari answered 14/8, 2022 at 14:9 Comment(1)
Maybe the C++ standard needs to be changed to have all destructors virtual, unless marked as "non-virtual"Freytag
N
5

I think the core of this question is about virtual methods and polymorphism, not the destructor specifically. Here is a clearer example:

class A
{
public:
    A() {}
    virtual void foo()
    {
        cout << "This is A." << endl;
    }
};

class B : public A
{
public:
    B() {}
    void foo()
    {
        cout << "This is B." << endl;
    }
};

int main(int argc, char* argv[])
{
    A *a = new B();
    a->foo();
    if(a != NULL)
    delete a;
    return 0;
}

Will print out:

This is B.

Without virtual it will print out:

This is A.

And now you should understand when to use virtual destructors.

Nasia answered 18/5, 2014 at 14:50 Comment(4)
No, this only retreads the utter basics of virtual functions, totally ignoring the nuance of when/why the destructor should be one - which isn't as intuitive, hence why the OP asked the question. (Also, why the unnecessary dynamic allocation here? Just do B b{}; A& a{b}; a.foo();. Checking for NULL - which should be nullptr - before deleteing - with incorrect indendation - is not required: delete nullptr; is defined as a no-op. If anything, you should have checked this before calling ->foo(), as otherwise undefined behaviour can occur if the new somehow failed.)Laddie
It is safe to call delete on a NULL pointer (i.e., you don't need the if (a != NULL) guard).Liggins
@SaileshD Yes, I know. That is what I said in my commentLiggins
@Laddie People usually demonstrate the behavior using pointers, because the most common use cases use pointers such as having std::vector<Base*>. Of course, std::vector<Base&> isn't a thing.Solemn
S
5

Virtual base class destructors are "best practice" - you should always use them to avoid (hard to detect) memory leaks. Using them, you can be sure all destructors in the inheritance chain of your classes are beeing called (in proper order). Inheriting from a base class using virtual destructor makes the destructor of the inheriting class automatically virtual, too (so you do not have to retype 'virtual' in the inheriting class destructor declaration).

Surtout answered 24/1, 2017 at 16:22 Comment(1)
I'd recommend not using the massive number of implied behaviors in C++. You can in your own project, but anywhere else, explicit code conveys intent rather than just behavior plus someone else working on the project may not know C++ perfectly. For example, do you know the default linkage behavior of a const global variable versus a non-const one? Even if you do, I guarantee most don't with many not even knowing the two types of linkage exist.Solemn
L
5

If you use shared_ptr(only shared_ptr, not unique_ptr), you don't have to have the base class destructor virtual:

#include <iostream>
#include <memory>

using namespace std;

class Base
{
public:
    Base(){
        cout << "Base Constructor Called\n";
    }
    ~Base(){ // not virtual
        cout << "Base Destructor called\n";
    }
};

class Derived: public Base
{
public:
    Derived(){
        cout << "Derived constructor called\n";
    }
    ~Derived(){
        cout << "Derived destructor called\n";
    }
};

int main()
{
    shared_ptr<Base> b(new Derived());
}

output:

Base Constructor Called
Derived constructor called
Derived destructor called
Base Destructor called
Longrange answered 6/3, 2019 at 19:27 Comment(5)
Though this is possible, I would discourage anyone from using this. The overhead of a virtual destructor is miniscule and this just makes it possible to mess up, specially by a less experienced programmer, who doesn't know this. That little virtual keyword could save you from a lot of agony.Perspiratory
Out of curiosity - Why is it that in the case of a shared_ptr the Base destructor gets called but not in the case of a unique_ptr?Halvorsen
@Halvorsen The reference counting block has a pointer to the resource, which is a templated class type with a virtual destructor. shared_ptr has a constructor templated on its parameter. It instantiates the reference counting block with a class that inherits from it's parameter's class. So the reference counting block is destructed, it calls delete on the pointer. From here on, everything works as expected. I know this simplifies away the cases of arrays and built in types.Noonday
Is this still true when using c++14 or later? I think the unique_ptr is changed after c++14 e.g add make_unique. Maybe the committee imporved the unique_ptr?Rentfree
@Rentfree still trueFreytag
C
4

What is a virtual destructor or how to use virtual destructor

A class destructor is a function with same name of the class preceding with ~ that will reallocate the memory that is allocated by the class. Why we need a virtual destructor

See the following sample with some virtual functions

The sample also tell how you can convert a letter to upper or lower

#include "stdafx.h"
#include<iostream>
using namespace std;
// program to convert the lower to upper orlower
class convertch
{
public:
  //void convertch(){};
  virtual char* convertChar() = 0;
  ~convertch(){};
};

class MakeLower :public convertch
{
public:
  MakeLower(char *passLetter)
  {
    tolower = true;
    Letter = new char[30];
    strcpy(Letter, passLetter);
  }

  virtual ~MakeLower()
  {
    cout<< "called ~MakeLower()"<<"\n";
    delete[] Letter;
  }

  char* convertChar()
  {
    size_t len = strlen(Letter);
    for(int i= 0;i<len;i++)
      Letter[i] = Letter[i] + 32;
    return Letter;
  }

private:
  char *Letter;
  bool tolower;
};

class MakeUpper : public convertch
{
public:
  MakeUpper(char *passLetter)
  {
    Letter = new char[30];
    toupper = true;
    strcpy(Letter, passLetter);
  }

  char* convertChar()
  {   
    size_t len = strlen(Letter);
    for(int i= 0;i<len;i++)
      Letter[i] = Letter[i] - 32;
    return Letter;
  }

  virtual ~MakeUpper()
  {
    cout<< "called ~MakeUpper()"<<"\n";
    delete Letter;
  }

private:
  char *Letter;
  bool toupper;
};


int _tmain(int argc, _TCHAR* argv[])
{
  convertch *makeupper = new MakeUpper("hai"); 
  cout<< "Eneterd : hai = " <<makeupper->convertChar()<<" ";     
  delete makeupper;
  convertch *makelower = new MakeLower("HAI");;
  cout<<"Eneterd : HAI = " <<makelower->convertChar()<<" "; 
  delete makelower;
  return 0;
}

From the above sample you can see that the destructor for both MakeUpper and MakeLower class is not called.

See the next sample with the virtual destructor

#include "stdafx.h"
#include<iostream>

using namespace std;
// program to convert the lower to upper orlower
class convertch
{
public:
//void convertch(){};
virtual char* convertChar() = 0;
virtual ~convertch(){}; // defined the virtual destructor

};
class MakeLower :public convertch
{
public:
MakeLower(char *passLetter)
{
tolower = true;
Letter = new char[30];
strcpy(Letter, passLetter);
}
virtual ~MakeLower()
{
cout<< "called ~MakeLower()"<<"\n";
      delete[] Letter;
}
char* convertChar()
{
size_t len = strlen(Letter);
for(int i= 0;i<len;i++)
{
Letter[i] = Letter[i] + 32;

}

return Letter;
}

private:
char *Letter;
bool tolower;

};
class MakeUpper : public convertch
{
public:
MakeUpper(char *passLetter)
{
Letter = new char[30];
toupper = true;
strcpy(Letter, passLetter);
}
char* convertChar()
{

size_t len = strlen(Letter);
for(int i= 0;i<len;i++)
{
Letter[i] = Letter[i] - 32;
}
return Letter;
}
virtual ~MakeUpper()
{
      cout<< "called ~MakeUpper()"<<"\n";
delete Letter;
}
private:
char *Letter;
bool toupper;
};


int _tmain(int argc, _TCHAR* argv[])
{

convertch *makeupper = new MakeUpper("hai");

cout<< "Eneterd : hai = " <<makeupper->convertChar()<<" \n";

delete makeupper;
convertch *makelower = new MakeLower("HAI");;
cout<<"Eneterd : HAI = " <<makelower->convertChar()<<"\n ";


delete makelower;
return 0;
}

The virtual destructor will call explicitly the most derived run time destructor of class so that it will be able to clear the object in a proper way.

Or visit the link

https://web.archive.org/web/20130822173509/http://www.programminggallery.com/article_details.php?article_id=138

Collayer answered 17/7, 2013 at 14:3 Comment(0)
T
3

I thought it would be beneficial to discuss the "undefined" behavior, or at least the "crash" undefined behavior that may occur when deleting through a base class(/struct) without a virtual destructor, or more precisely no vtable. The code below list a few simple structs (the same would be true for classes).

#include <iostream>
using namespace std;

struct a
{
    ~a() {}

    unsigned long long i;
};

struct b : a
{
    ~b() {}

    unsigned long long j;
};

struct c : b
{
    ~c() {}

    virtual void m3() {}

    unsigned long long k;
};

struct d : c
{
    ~d() {}

    virtual void m4() {}

    unsigned long long l;
};

int main()
{
    cout << "sizeof(a): " << sizeof(a) << endl;
    cout << "sizeof(b): " << sizeof(b) << endl;
    cout << "sizeof(c): " << sizeof(c) << endl;
    cout << "sizeof(d): " << sizeof(d) << endl;

    // No issue.

    a* a1 = new a();
    cout << "a1: " << a1 << endl;
    delete a1;

    // No issue.

    b* b1 = new b();
    cout << "b1: " << b1 << endl;
    cout << "(a*) b1: " << (a*) b1 << endl;
    delete b1;

    // No issue.

    c* c1 = new c();
    cout << "c1: " << c1 << endl;
    cout << "(b*) c1: " << (b*) c1 << endl;
    cout << "(a*) c1: " << (a*) c1 << endl;
    delete c1;

    // No issue.

    d* d1 = new d();
    cout << "d1: " << d1 << endl;
    cout << "(c*) d1: " << (c*) d1 << endl;
    cout << "(b*) d1: " << (b*) d1 << endl;
    cout << "(a*) d1: " << (a*) d1 << endl;
    delete d1;

    // Doesn't crash, but may not produce the results you want.

    c1 = (c*) new d();
    delete c1;

    // Crashes due to passing an invalid address to the method which
    // frees the memory.

    d1 = new d();
    b1 = (b*) d1;
    cout << "d1: " << d1 << endl;
    cout << "b1: " << b1 << endl;
    delete b1;  

/*

    // This is similar to what's happening above in the "crash" case.

    char* buf = new char[32];
    cout << "buf: " << (void*) buf << endl;
    buf += 8;
    cout << "buf after adding 8: " << (void*) buf << endl;
    delete buf;
*/
}

I'm not suggesting whether you need virtual destructors or not, though I think in general it's a good practice to have them. I'm just pointing out the reason you may end up with a crash if your base class(/struct) does not have a vtable and your derived class(/struct) does and you delete an object via a base class(/struct) pointer. In this case, the address you pass to the heap's free routine is invalid and thus the reason for the crash.

If you run the above code you'll see clearly when the issue occurs. When the this pointer of the base class(/struct) is different from the this pointer of the derived class(/struct) you're going to run into this problem. In the sample above, struct a and b don't have vtables. structs c and d do have vtables. Thus an a or b pointer to a c or d object instance will be fixed up to account for the vtable. If you pass this a or b pointer to delete it will crash due to the address being invalid to the heap's free routine.

If you plan to delete derived instances which have vtables from base class pointers, you need to ensure the base class has a vtable. One way to do that is to add a virtual destructor, which you might want anyway to properly clean up resources.

Towne answered 23/3, 2017 at 17:50 Comment(0)
S
2

when you need to call derived class destructor from base class. you need to declare virtual base class destructor in base class.

Schema answered 9/9, 2014 at 7:2 Comment(0)
A
2

I think most answers here miss the point, with the exception of the accepted one, which is a good thing. However, let me add one more with a different view on the issue: You need a virtual destructor if you want to polymorphically delete instances of this class.

This kind-of sidesteps the question, so let me elaborate: As many pointed out, you get undesired behaviour if you invoke delete base_ptr and the destructor is not virtual. However, there are several assumptions there that need to be made explicit:

  • If your class is not a baseclass, you will hopefully not write code like this. In this case I don't mean the manual memory management, which is bad in and of itself, but deriving publicly from this class. A class not designed as baseclass should not be inherited from, like e.g. std::string. C++ allows you to shoot yourself in the foot. This is your fault though, not that of the baseclass not having a virtual destructor.
  • If the destructor is not accessible (protected or private), this code won't compile, so the undesired behaviour can not occur. Having a protected destructor is useful, especially for mixins but also (to a lesser extent) for interfaces. You don't want to incur the overhead of virtual functions unless you actually make use of them. Making the destructor protected instead prevents undesired behaviour but doesn't restrict you otherwise.
  • If you actually write a class that is supposed to be derived from, you will typically have virtual functions anyways. As a user of them, you will typically only use them via a pointer to the baseclass. When this use includes disposing of them, it then needs to be polymorphic as well. This is then the case when you should make the destructor virtual.

For a similarly different view on the subject, also read When should you not use virtual destructors?

Aviate answered 23/9, 2021 at 20:13 Comment(0)
I
1

Make all destructors virtual unless you have good reason not to.

Otherwise evil like this happens:

Suppose you have an array of Fruit pointers with both Apple and Orange objects.

When you delete from the collection of Fruit objects, ~Apple() and ~Orange() fail to be called unless ~Fruit() is virtual.

Example done right:

#include <iostream>
using namespace std;
struct Fruit { // good
  virtual ~Fruit() { cout << "peel or core should have been tossed" << endl; } 
};
struct Apple:  Fruit { virtual ~Apple()  {cout << "toss core" << endl; } };
struct Orange: Fruit { virtual ~Orange() {cout << "toss peel" << endl; } };

int main() { 
  Fruit *basket[]={ new Apple(), new Orange() };
  for (auto fruit: basket) delete fruit;
};

good output

toss core
peel or core should have been tossed
toss peel
peel or core should have been tossed

Example done wrong:

#include <iostream>
using namespace std;
struct Fruit { // bad 
  ~Fruit() { cout << "peel or core should have been tossed" << endl; } 
};
struct Apple:  Fruit { virtual ~Apple()  {cout << "toss core" << endl; } };
struct Orange: Fruit { virtual ~Orange() {cout << "toss peel" << endl; } };

int main() { 
  Fruit *basket[]={ new Apple(), new Orange() };
  for (auto fruit: basket) delete fruit;
};

bad output

peel or core should have been tossed
peel or core should have been tossed

(Note: Where I used struct for brevity, normally use class and specify public)

Ingra answered 23/9, 2021 at 18:51 Comment(0)
E
0

A basic definition about virtual is it determines if a member function of a class can be over-ridden in its derived classes.

A class's D-tor is called basically at the end of the scope, but there is a problem, for example when we define an instance on the Heap (dynamic allocation), we should delete it manually.

As soon as the instruction get executed, the base class destructor get called, but not for the derived one.

A Pratical example is when, in control field, you have to manipulate effectors, actuators.

At the end of the scope, if the destructor of one of the power elements (Actuator), isn't called, there will be fatal consequences.

#include <iostream>

class Mother{

public:

    Mother(){

          std::cout<<"Mother Ctor"<<std::endl;
    }

    virtual~Mother(){

        std::cout<<"Mother D-tor"<<std::endl;
    }


};

class Child: public Mother{

    public:

    Child(){

        std::cout<<"Child C-tor"<<std::endl;
    }

    ~Child(){

         std::cout<<"Child D-tor"<<std::endl;
    }
};

int main()
{

    Mother *c = new Child();
    delete c;

    return 0;
}
Emmalynne answered 20/5, 2020 at 7:45 Comment(0)
S
0

Undefined behaviour occurs when a derived class object is deleted using a pointer of a base class type with a non-virtual destructor. The base class has to be defined with a virtual destructor in order to fix this issue.

For example, the following program results in undefined behavior.

#include <iostream>
using namespace std;
class base {
public:
    base()   
    { 
        cout << "Constructing base\n";
    }
    ~base()
    { 
         cout<< "Destructing base\n"; 
    }    
};

class derived: public base {
public:
    derived()    
    { 
        cout << "Constructing derived\n";
    }
    ~derived()
    { 
        cout << "Destructing derived\n"; 
    }
};

int main()
{
    derived *d = new derived(); 
    base *b = d;
    delete b;
    getchar();
    return 0;
}

OutPut

Constructing base 
Constructing derived 
Destructing base

Making base class destructor virtual guarantees that the object of derived class is destructed properly, i.e., both base class and derived class destructors are called. For example,

#include <iostream>
 
using namespace std;
 
class base {
  public:
    base()     
    { 
        cout << "Constructing base\n";
    }
    virtual ~base()
    { 
        cout << "Destructing base\n"; 
    }     
};
 
class derived : public base {
  public:
    derived()     
    { 
        cout << "Constructing derived\n"; 
    }
    ~derived()
    { 
        cout << "Destructing derived\n"; 
    }
};
 
int main()
{
  derived *d = new derived();  
  base *b = d;
  delete b;
  getchar();
  return 0;
}

Output

Constructing base
Constructing derived
Destructing derived
Destructing base

As a guideline, any time you have a virtual function in a class, you should immediately add a virtual destructor (even if it does nothing). This way, you ensure against any surprises later.

Sipes answered 11/1 at 19:8 Comment(1)
Nothing really wrong with this answer but it doesn't add anything that hasn't already been covered in detail in the earlier answers. Unless you can bring a real game-changer it's better to not answer ancient questions, and especially not before you've built up enough goodwill from the server to offset a few zero-scored answers.Bartie
S
-1

Any class that is inherited publicly, polymorphic or not, should have a virtual destructor. To put another way, if it can be pointed to by a base class pointer, its base class should have a virtual destructor.

If virtual, the derived class destructor gets called and then the base class destructor. If not virtual, only the base class destructor gets called.

Slangy answered 2/1, 2015 at 16:27 Comment(1)
I would say this is only necessary "if it can be pointed to by a base class pointer" and can be publically deleted. But I guess it doesn't hurt to get into the habit of adding virtual dtors in case they might become needed later.Laddie

© 2022 - 2024 — McMap. All rights reserved.