I also got this advice from a C++ expert:If your constructor does nothing: better not to define it. You can define a dummy destructor - but if you do it, define it as virtual.
This is actually quite a bad advice in my opinion. An empty constructor does not help, but it does not harm either.
On the other hand, a virtual destructor
does harm. Maybe "harm" is the wrong word, let's say "cost", but the general idea is the same. At the very least, this bears an unnecessary storage cost of one pointer in the vtable plus one pointer for every allocated object. The single vtable entry may be neglegible, but if you allocate and deallocate 5 million objects, then carrying around one unnecessary v-ptr for each object
may make a difference (as may the two additional pointer dereferences to call a destructor that does nothing...).
As always, the significance depends on what you do, but I think carrying around a penalty that you absolutely don't need is not a good idea.
You could say it is like using
x++; or
++x;, the difference (if any) is not terribly big... but then, here we
do bother
The one and only case in which you really
need a virtual destructor is when all of the following three conditions are met:
1. you have one or more virtual functions
2. you allocate an object of a derived class
3. you free this object as a type of the base class
For convenience, and for safety, one usually defines a virtual class' destructor virtual, as it does not make much difference (you have to carry the v-ptr around anyway) and you don't have to worry about who might derive from and tamper with your class.
However, it makes no sense at all to make a destructor virtual in a non-virtual class just for the sake of doing it.
