Hm, I'd rather pay the cost of having to add a virtual keyword in a few places (easily found using the equivalent of g++ -Wnon-virtual-dtor, and you do ship C++ code that is warning-free, right? :) rather than have to deal with up to eight bytes extra per instance in all my classes.
Thanks for the hint!
Actually I did not know about this option. I've just fixed such bug in one of our tools, written using wxWidgets for Windows. Have to check MSVC on this option.
At the same time a coworker was able to get the Xbox360 analyze thing and it worked finding suspicious stuff in the runtime code.
But we have only the professional version for PC :(
In MSVC, this warning's off by default: http://msdn.microsoft.com/en-us/library/wzxffy8c(v=VS.100).a...
This would've been prevented if destructors were always virtual.
My take is that if the compiler cannot make the decision, but it's left to you, in this case it's better to always have the virtual destructors ON.
The problem is more visual than analytical - you would have to dig through the whole hierarchy in several files to understand whether you need to put a virtual destructor or not. Compiler/Linker/some post-proc tool should be better at that job. It already has all that information.