Simonson, Lucanus J wrote:
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.)
Do you realize that you just made an argument why it is important for the destructor to be virtual ? If the compiler doesn't know the exact type (and thus can't inline the call), there is a serious risk that any derived destructor might need to be executed, but the compiler doesn't know that (and neither does the runtime, as there is no entry for the destructor in the vtable). It doesn't matter whether the base-class destructor is a no-op. What matters is what is in the derived class destructor, which you (or the base class implementor) does not have any control over. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...