From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe
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,
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
:-) I wouldn't have a junior programmer maintaining it. However, I would routinely encourage junior programmers to make use of boost libraries, so they don't run the risk of reinventing the wheel (e.g. in our code, you'll never find a naked pointer, but rather one of boost's smart pointers). But then I was responding specifically to the question of whether or not destructors should be virtual if there are other virtual member functions. plain and simple. problem under /some/ >circumstances.
I wouldn't presume to tell Emil what he should do with his library. It does, though, mean I have some explaining to do when the kids see a good library that occassionally does things a bit differently from what I try to teach them. I do have a little sympathy with your, and his, position, when dealing with extremely tight time constraints, but not a lot. If one of the design criteria is that the code being produced must be widely portable, then I pass it through the range of platforms and compilers that we have to support, and as far as it is possible, I try to treat all warnings as errors. And that is an attitude I try to encourage among those junior programmers I mentor. This is, without question, much easier when dealing with only one compiler on one platform, but it remains the ideal I encourage the kids to aim for. I don't worry so much about 'readability' as I encourage extensive comments within the code for those blocks that are a little less than obvious. Such comments have the effect of both making the code maintainable and flagging those potential querks that can be reviewed as new versions of compilers are released (to see if they are still an issue with the new version of the supported compiler(s)). Cheers Ted