AMDG On 03/17/2011 11:17 AM, Ted Byers wrote:
I must respectfully disagree.
There are two ways to look at this 'should'. First, there is what is required or permitted by the standard. Second, there is what is useful in managing a software development project. When I am trying to help my juniors develop good programming habits, one of the things I want them to do is always provide a virtual destructor whenever they make one or more member functions virtual. That lets a team comprised of many more junior programmers than really really old guys like me avoid a lot of subtle bugs. And I don't see a significant down side to making a destructor virtual. Hence, when I am mentoring junior programmers, I routinely advise them to make destructors virtual whenever they need one of the other member functions to be virtual, whenever the issue arises.
a) This is in Boost. If a junior programmer were maintaining it, this would be the least of his worries. b) Boost.Exception uses a different idiom which is even more safe. i.e. use shared_ptr. c) The virtual functions in question are an implementation detail used in a very restricted context. From a user's perspective, it's a concrete class, plain and simple. d) Emil is strongly against changing the code to eliminate warnings that don't represent real problems, and prefers suppressing them explicitly. I have to say that I have a lot of sympathy for his view, since beyond a certain point, if you try to eliminate all warnings, fixing problems turns into working around compiler quirks. In my experience, eliminating all warnings on all compilers, results in less readable and maintainable code as we dance around all the constructs that any compiler thinks /might/ be a problem under /some/ circumstances.
Are you aware of a significant downside to making destructors virtual as a matter of habit?
Well, I almost never use virtual destructors, because I rarely use virtual functions to begin with. In Christ, Steven Watanabe