Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-11-24 14:52:30

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

This is what bothers me most about the idea that all warnings must be 
addressed in Boost libraries. People do not seem to understand that a 
warning should not mean that the C++ standard is not being followed. 
Some compilers actually do produce warnings when the C++ standard is not 
being followed and unfortunately IMO the C++ standard allows this. So 
now we have warnings from some compilers that run the gamut from actual 
errors because the C++ standard is not being followed to essentially 
lint-like worries that some syntax may be hiding incorrect use of C++ 
even when the code is perfectly correct. 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.

> 
> Ciao
>    Dani
>