Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Daniela Engert (dani_at_[hidden])
Date: 2018-11-24 17:32:18

Am 24.11.2018 um 15:52 schrieb Edward Diener via Boost:
> On 11/24/2018 7:55 AM, Daniela Engert via Boost wrote:
>> Am 23.11.2018 um 20:58 schrieb Emil Dotchevski via Boost:
>>>
>>> unsigned f();
>>>
>>> void g( int x )
>>> {
>>>    if( x < f() ) //warning C4018: '<': signed/unsigned mismatch
>>>    {
>>>      ....
>>>    }
>>> }
>>
>> The only problem that I can see here is the fact, that this is flagged
>> as a warning rather than an error. I know, this is technically correct
>> but you simply cannot compare values from different value domains
>> without preconditions. Not stating the preconditions is an error. If you
>> state them and assure that the actual values of both 'x' and 'f()' can
>> be equally represented as 'int' oder 'unsigned' then and only then the
>> comparison is correct and a explicit cast to either type is a valid one.
> 
> Errors should be when you are not following the C++ standard. If you
> think that comparing a signed number with an unsigned number is not
> following the C++ standard you should reread the C++ standard.

I've already acknowledged that this is not an error according to the C++
standard. Nonetheless is it an error in the mathematical sense that it
*may* invert the meaning of 'operator<' because of the implicit
conversion rules of C++.

> I do not
> mind this particular warning at all and go out of my way to fix it, but
> it is not an error in the C++ standard.

Right. Situations like these must be acted on. Just letting these go
"because it is correct by the standard" is inacceptable imho.

> This is what bothers me most about the idea that all warnings must be
> addressed in Boost libraries.

In most cases, I simply turn off compiler warnings by a #pragma after I
convinced myself that "everything is fine, nothing to see here, get
along". The simple fact that someone has audited warnings, acted
accordingly, and then documented this - may be by just suppressing them
in the source code - is an indicator of due diligence.

> Therefore while warnings should
> be heeded I do not think it is possible in practical use to fix all
> warnings for all compiler implementations without making code even more
> obfuscated and more confusing than it normally is. It is an ideal to fix
> all warnings but it is not a realistic goal in quite a number of
> situations.

True. And I think earlier versions of MSVC went way overboard spitting
out warnings about totally reasonable and perfectly valid code. The
versions up to vs2013 were just a pain in the a**, and I am happy to
compile my code using latest vs2017 only these days which is much more
sensical in this regard. (I can only speak about experiences with msvc,
it's the only compiler that we can use). Nevertheless, I made Boost
compile - at least in our codebase - on vs2013 without warnings at /W4
after following the procedure described above: audit and act upon.

Ciao
  Dani