AMDG Peter Soetens wrote:
On Wed, Sep 30, 2009 at 20:48, Steven Watanabe
wrote: 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.
Great! I can point to 10000 lines of code in Boost that accommodate for compiler quirks, especially for MSVS and Borland compilers. So for once, do the GNU people the same honor and fix this single line of code for our automated testing happiness.
Compiler specific workarounds should only be used when we're dealing with compiler bugs or compiler specific features. This is neither.
I don't see any reason here why it shouldn't be fixed for the GNU compiler, giving the portability/non-discriminality that Boost claims to have over all compilers.
Because there's a better fix that guarantees that it will work correctly on all compilers...
Just #ifdef the virtual around the destructor for GNU compilers and we can all happily carry on.
IMO, it's a bad idea to throw in a hack to fix a problem without understanding why it works. In Christ, Steven Watanabe