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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk