Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?

Subject: Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-09-08 20:19:38

Michael Fawcett wrote:
> Well, it's right.  That's a constant conditional expression.

You're trying to tease me, right?


> You can
> either ignore the warning or put it in a template specialization which
> would get rid of the warning.  Is it defined in the standard that the
> conditional will *always* get optimized away?  If it isn't, that seems
> like a reasonable warning.

MSVC explicitly says whether a warning is just a performance warning, and C4127 is not a performance warning. It is a warning to inform the programmer about a possible mistake (IIRC, if(true) or if(false) don't trigger this warning). I don't understand what you mean by "... or put it in a template specialization which would get rid of the warning". Are you suggesting I should try to emulate the optimizer of the compiler, even if this would imply substantial code duplication?


> > I don't know what about the boost way to silence warnings, but if it is along the line of
> >
> > #ifdef BOOST_WARNING_MSVC_WORKAROUND
> > #pragma warning(push)
> > #pragma warning(disable:4127)
> > #endif
> >
> > ...
> >
> > #ifdef BOOST_WARNING_MSVC_WORKAROUND
> > #pragma warning(pop)
> > #endif
> >
> > then silencing 60+ warnings in this way will add 420+ lines to the source code.
>
> I don't think that works with templates.  Typically to silence errors
> in template code, the user must put those pragmas around the point of
> instantiation.

I hope you're joking.


> The warnings I saw were int->bool, bool->int conversions, unused
> parameters, and struct now seen as class.
>
> I agree some warnings are nonsense, but there are some cases (just
> mentioned) that should be silenced by proper code changes.

Agreed.


> I don't think a strict "no warning" policy needs to be in place, which
> I think is what Emil is against, but I think Boost should strive to
> have as few as possible and there's too much low hanging fruit waiting
> to be picked currently (causing lots of noise).

Agreed.

I just tried to give a concrete example to Christopher Currie's request:  "That said, I'd be interested in an example of a warning not worth fixing. I haven't worked with the more draconian compilers in a long time, and it'd be educational to have a concrete counter-example to compare against."

Regards,
Thomas