C.35: A base class destructor should be either public and virtual, or protected and nonvirtual
Destructor base class virtual function either open, or is a protected non-virtual functions
Reason (reason)
To prevent undefined behavior. If the destructor is public, then calling code can attempt to destroy a derived class object through a base class pointer, and the result is undefined if the base class's destructor is non-virtual. If the destructor is protected, then calling code cannot destroy through a base class pointer and the destructor does not need to be virtual; it does need to be protected, not private, so that derived destructors can invoke it. In general, the writer of a base class does not know the appropriate action to be done upon destruction.
In order to avoid undefined behavior. If the destructor is public, then the calling code will attempt to use side base class pointer to a derived class of destroying objects, when the result is not defined when the base class destructor non-virtual functions. If the protection destructor, then the call-side code that can not be destroyed by the derived object base type pointer, it is not necessary destructor must be virtual. Destructor is to protect, rather than private, so the derived class destructor can invoke it. Typically, the base class designer does not know what actions should be performed in the destructor.
Discussion (discussion)
See this in the Discussion section: see the discussion section:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Sd-dtor.
Example, bad (negative sample)
struct Base { // BAD: implicitly has a public nonvirtual destructor
virtual void f();
};
struct D : Base {
string s {"a resource needing cleanup"};
~D() { /* ... do some cleanup ... */ }
// ...
};
void use()
{
unique_ptr<Base> p = make_unique<D>();
// ...
} // p's destruction calls ~Base(), not ~D(), which leaks D::s and possibly more
Swipe left or right to see more
Note (Note)
A virtual function defines an interface to derived classes that can be used without looking at the derived classes. If the interface allows destroying, it should be safe to do so.
Virtual function derived class defines interfaces, it can not concerned with the case of using the derived class. If the interface allows an object, then the destruction process should be safe.
Note (Note)
A destructor must be nonprivate or it will prevent using the type:
Destructor must be non-private, except that it does not want others to be used. (This can be controlled by a class of its own destruction, Translator's Note)
class X {
~X(); // private destructor
// ...
};
void use()
{
X a; // error: cannot destroy
auto p = make_unique<X>(); // error: cannot destroy
}
Exception (exception)
We can imagine one case where you could want a protected virtual destructor: When an object of a derived type (and only of such a type) should be allowed to destroy another object (not itself) through a pointer to base. We haven't seen such a case in practice, though.
We can imagine a virtual function is a need to protect destructor situation: When it is desired to allow the object (only this type) base class by the derived class pointer to another object (not its own) destruction. But we have not encountered such a situation in the actual development.
Enforcement (Suggestions)
-
A class with any virtual functions should have a destructor that is either public and virtual or else protected and nonvirtual.
-
Has a virtual function virtual function class either public virtual functions, either to protect the non-virtual functions.
Translator's Note: virtual functions has generally means it has derived classes.
Original link:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c35-a-base-class-destructor-should-be-either-public-and-virtual-or-protected-and-nonvirtual
I think this article helpful? Welcome thumbs up and share it with more people.
Read more updated articles, please pay attention to micro-channel public number of object-oriented thinking []
