Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-11-06 22:13:46

On Fri, Nov 6, 2009 at 8:52 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Gottlob Frege wrote:
>> Some specific warnings, and our conclusions:
>>
>> - missing virtual dtor
>>    - didn't find any bugs in our code, but it is not a bad warning in
>> general, when you think about who might be using/maintaining your code
>> in the future.
>
> That's an excellent rationale.  You may handle it well in the current code, but a user may be concerned, may use your code in an unexpected way, or a maintainer may violate your design idea.
>
>>    - solution:  add virtual dtor, make it protected, leave a comment
>> about the warning
>
> That's a bit vague.  The policy should be public and virtual or protected and non-virtual.  If the latter leads to a warning from a compiler, we should document the manner by which to quiet that compiler.  We could even create a pair of macros to bracket the protected, non-virtual dtor or use a macro to generate the declaration with the warning suppression.
>

That's the thing - in all of our cases there were no bugs - ie we were
not deleting derived classes via the base class. So we didn't _need_
virtual.  But gcc complains.  Even if we made it protected, hoping to
make our intent clear (to other developers and to the compiler) we
still needed to make it virtual to get rid of the warning.  I hear
that may have since changed.  Maybe because of us, actually, because I
do recall someone was going to bring up the issue with gcc developers.

> Keeping the initializer list in good order means you can't be confused about the order of initialization.  I *have* found bugs in others' code because of this.  Many developers are ignorant of the order of initialization and can be bitten by it.  If such developers are trained to honor warnings, then this warning will help them.  At the very least, they will ask me about it.
>

It bothers me that the compiler is pandering to developers who don't
know their language well enough.  But maybe that's what all warnings
are about, to some extent.

> The fix for this warning is so trivial that there shouldn't be an issue with it.  Fix the initializer list order and be done with it.
>

It would be trivial unless you had a large code-base and hundreds of
occurrences that needed fixing.  Then it just seems a waste of time.
But it's the same thing - once you are at 0 it is easier and
worthwhile.  It is just getting there that's the problem.

Tony