Boost logo

Boost :

Subject: Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2009-09-08 19:39:22


On Tue, Sep 8, 2009 at 7:26 PM, Thomas
Klimpel<Thomas.Klimpel_at_[hidden]> wrote:
>
> Thomas Klimpel wrote:
>> - It is true that msvc-9 spits out many warnings. However, it is also
>> true that "warning C4127: conditional expression is constant" for a code like
>>  template <typename value_type, typename geometry_type_1, typename geometry_type_2, int op_type>
>>  void execute_boolean_op(value_type& output_, const geometry_type_1& lvalue_, const geometry_type_2& rvalue_,
>>      ...
>>      if(op_type < 2)
>> is nonsense, because op_type is a template parameter. So I have the
>> impression that the only way to get rid of the msvc warnings is by
>> disabling the nonsense warnings with appropriate pragmas.

Well, it's right. That's a constant conditional expression. 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.

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

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.

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

--Michael Fawcett


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk