Re: [Boost-users] boost::exception_detail::error_info_base does not have virtual destructor

Subject: Re: [Boost-users] boost::exception_detail::error_info_base does not have virtual destructor
From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2011-03-17 16:58:39

>From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] 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.

:-)
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.

>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.
>
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