What's the problem with making the destructor virtual in the first
Hartmut wrote: place?
Since the class already has other virtual functions this won't generate any (significant) additional overhead (the only thing what's added is another function pointer to the already existing virtual function table, barely something to worry about).
This is not true. In this case, the destructor is a no-op. Virtual functions incur significant overhead over non-virtual functions in the case that the non-virtual would be inlined, where-as the virtual must have a symbol for the pointer in the virtual function table to point to, and cannot be called inline unless the exact type is known at compile time (defeating the purpose of polymorphism.) Consider the difference between this: inline ~classname() {} //do nothing inline virtual ~classname() {} //do nothing but pay function call overhead anyway because the compiler usually can't inline the function. There seems to be a widespread misconception that virtual functions have low overhead. This can be true, but when loss of potential inlining happens it is a significant overhead. This may seem like a small issue until you profile code that spends double digit percentage of runtime executing an out-of-line function call to a no-op destructor. Luke