
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