|
Boost : |
Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-11-24 18:57:28
On Sat, Nov 24, 2018 at 9:12 AM Daniela Engert via Boost <
boost_at_[hidden]> wrote:
>
> Am 24.11.2018 um 16:52 schrieb Peter Dimov via Boost:
> > Daniela Engert 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.
> >
> > Making it an error would be a useful first step towards making it work
> > correctly. :-)
>
> This is exactly what we do in our software. And because of that there
> must must at least be warnings from the compiler to stop us from
> committing such mathematical nonsense.
It is only nonsense if the value stored in the signed side can be negative,
and that's something the programmer should know. Therefore, assert, not
cast.
> Situations like these must be
> inspected, audited and acted upon by human beings. Throwing the hands in
> the air and insisting "but the language allows me to" is just asking for
> disaster.
It's more like "I need to do this comparison, I know it is fine in this
case, and the language allows me to". There is no question that a human
being should inspect it, I'm not saying the warning is meaningless. What
makes it impractical is that the only way to silence it is to replace the
implicit conversion with a cast. The inspecting human being should
understand that these are two semantically different operations, and should
use the cast only if it is correct (and the implicit conversion is
incorrect), not as a means to silence the warning.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk