Why? If they don't it is going to mess up the destruction sequence if they are ever stored and then released polymorphically, such as from a collection of pointers to classes.
You can also use a protected non-virtual destructor in the base class to avoid to mess up the destruction sequence. But what he says is indeed the most common case.
All of which is a workaround for the fact that there is no explicit way to declare a c++ class to be abstract-only.
What happens if you do have shared logic to put in the abstract base class's destructor? It can't be pure virtual, and you're back to being able to instantiate your 'abstract' base class...
> All of which is a workaround for the fact that there is no explicit way to declare a c++ class to be abstract-only.
Sure you can. Just put the word "Abstract" in the class name, and then every programmer who reads that class name will know that it's abstract. What more does one need?
That approach is much clearer than resorting to tricks like a pure virtual destructor. At the end of the day it's all about communicating design.
9 comments
[ 3.1 ms ] story [ 23.8 ms ] threadNot a good way to start the article... I immediately question the author's credibility following this statement.
What he is saying is standard C++ knowledge.
What happens if you do have shared logic to put in the abstract base class's destructor? It can't be pure virtual, and you're back to being able to instantiate your 'abstract' base class...
Sure you can. Just put the word "Abstract" in the class name, and then every programmer who reads that class name will know that it's abstract. What more does one need?
That approach is much clearer than resorting to tricks like a pure virtual destructor. At the end of the day it's all about communicating design.