
AMDG Rush Manbert wrote:
I see your point, but by not using the pointer polymorphically to delete the derived class objects, you now need to write a workaround for how some compilers are implemented. But if the base class destructor were virtual, the delete would be guaranteed to work by the language definition, regardless of the compiler implementation. You wouldn't care how the compiler implemented it, it would just work. And it will still just work as compilers and runtime libraries for C++ evolve. That seems to make more sense to me.
As Gennadiy has already said, the fact that making the destructor virtual fixes the problem is an artifact of the way that compilers implement virtual destructors. with a non virtual destructor, the compiler generates read the pointer call the destructor read the pointer call operator delete. The problem is the second read after the destructor has run, With a virtual destructor the compiler generates read the pointer use the v-table to call the destructor/delete. This is a single function call so the pointer is only looked up once. In Christ, Steven Watanabe