C why virtual destructor

Please note, destructors of base classes can be declared in the protected class scope in order to prevent compilation of such client code, if public scope is not required by design. Still remaining, are all the other classes that do not use runtime polymorphism.

In other words, those which do not need any virtual functions. Some classes are not designed to be base classes at all, as exhibited in SomeDataWrapper from the first code snippet.

Furthermore, a base class may not use runtime polymorphism, as shown in the following example:. Declaring virtual destructors for these classes can incur costs for the virtual function mechanism, although they will not be utilized. The runtime costs of virtual destructors have already been discussed for Type 2 classes. However, these costs are not the same for classes without any other virtual functions.

Below is a list of the potential disadvantages of declaring the destructor virtual in a class not utilizing runtime polymorphism, the importance of each depending on the particular use case:. Contrarily, the only advantage of declaring destructors of such classes as virtual is to prevent against possible client misuse by destructing derived class objects through pointers or references of base class types.

As aforementioned, the toll can be too costly for this type of advantage, especially to make it a habit. In fact, virtual destructors are still reasonable for non-runtime polymorphic base classes for which performance and size are not important concerns and all costs are acceptable.

This is true particularly when the destructor must be public, keeping in mind that protected base class destructors prevent this misuse as well. It is also worth reminding that base classes that do not have any virtual functions are not very common in object-oriented design. In general, blindly declaring every destructor as virtual is a bad practice and can potentially lead to a significant waste of resources.

However, in the case of experienced programmers, this can better be explained with a tendency of overlooking the rationale and costs of using specific language features, which leads to an incorrect level of abstraction in the coding process, resulting in bad code. On the other hand, doing this deliberately may well point to a zealous belief in defensive programming to the point of significant performance loss, as well as making the code less coherent. If a class has any virtual functions, it should have a virtual destructor.

Classes not designed to be base classes or not designed to be used polymorphically should not declare virtual destructors. Check out our Data Structures in C course to start learning today. It is important to note that a class becomes abstract class when it contains a pure virtual destructor. For example, try to compile the following program. Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

Skip to content. Change Language. Related Articles. Table of Contents. Save Article. See this: Virtual Destructor — Naveen.

Every destructor down gets called no matter what. 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?

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 : — Mooing Duck. Show 5 more comments. Active Oldest Votes. Luc Touraille Luc Touraille This would explain why i had massive leaks using a factory i made before. All makes sense now.

Thanks — Lodle. Well, this is a bad example as there are no data members. What if Base and Derived have all automatic storage variables? Is it ok then to leave off writing any destructors at all? Or will the derived class still have a memory leak? Wait, it will be undefined behavior — bobobobo. From the Herb Sutter's article: "Guideline 4: A base class destructor should be either public and virtual, or protected and nonvirtual.

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. Show 8 more comments. Tunvir Rahman Tusher Tunvir Rahman Tusher 5, 2 2 gold badges 33 33 silver badges 30 30 bronze badges.

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. Thanks — Tunvir Rahman Tusher.

Murkantilism, "virtual constructors cannot be done" is true indeed. A constructor cannot be marked virtual. See parashift. TunvirRahmanTusher could you please explain why the Base Destructor is called?? Add a comment. Bill the Lizard Bill the Lizard k gold badges silver badges bronze badges. If not, would it make sense to have the compiler check this condition and issue an error is it is not satisfied?

Giorgio I don't know of any exceptions to the rule. A compiler warning or a warning from a static analysis tool makes sense to me. 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. 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.

Of course the scope is quite limited. Show 2 more comments. Community Bot 1 1 1 silver badge. BigSandwich BigSandwich 2, 2 2 gold badges 21 21 silver badges 26 26 bronze badges.

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"? Thats pretty much the same thing.

The default constructor is not virtual. BigSandwich "hang myself"? You mean memory leaking? Make the destructor virtual whenever your class is polymorphic. Dana 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. Abyx Abyx Or is that implied by the language making it safe to omit? Wallacoloo no, only declare it when it's necessary. Am I right? Not have the base virtual destructor and calling delete on a base pointer leads to undefined behavior.

JamesAdkison why does it lead to undefined behaviour?? I don't have a copy but the link takes you to a comment where someone references the location within the standard. 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.

Mukul Kashmira Mukul Kashmira 1 1 silver badge 7 7 bronze badges. Dragan Ostojic Dragan Ostojic 99 1 1 silver badge 1 1 bronze badge. 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.