Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-11-26 06:37:58

On Sun, Nov 25, 2018 at 8:52 PM Gavin Lambert via Boost <
boost_at_[hidden]> wrote:
> On 26/11/2018 15:50, Emil Dotchevski wrote:
> > This is similar to the implicit conversion, except it doesn't eliminate
the
> > other implicit conversion which will occur if the return type of f is of
> > size greater than the size of x, which will likely earn you another
> > warning.
>
> That was intentional, because that's another decision that has to be
> made explicitly, with evaluation of the range constraints on f()'s
> return value.

Yes, so you need what I wrote (below)...

> > Therefore you probably want
> >
> > auto xu = std::make_unsigned<decltype(f())>::type(x);
>
> No, that's pointless.  f() is already known to return an unsigned type
> or you wouldn't have received the original warning in the first place.

Except, obviously, I meant std::make_signed<decltype(f())>::type(x).

To avoid warnings, you need to match the signed/unsigned and the size.
Assuming f returns correct width, presumably you want to cast x to that
width regardless of whether it is wider or narrower, although even this may
be incorrect. You need to complicate it further and promote to the bigger
of the two types.

Of course all of this is just silly, because that's what the implicit
conversion does. :)

> > Fine. Do you think programmers actually write this to silence such
> > warnings, rather than cast? Are you arguing that they should?
>
> I don't think many currently do this, no.  I wonder if they should,
> given your complaint, but it's probably more generally useful to
> encourage use of safe_numerics or similar instead.

No, they shouldn't, instead they should learn the semantics of C/C++
implicit conversions and disable the noob warning.

> > Ironically, in my experience the warning police doesn't care about the
> > assert, even though it will actually catch the bugs they're trying to
> > defend against, while the warning, silenced with a cast, won't.
>
> True.  The assert is more explicit and more useful (if actually
> checked), but people seem unreasonably afraid of adding them for some
> reason.

The reason is that they have the wrong mindset when approaching the problem.

They think: I get a warning, because the compiler doesn't know that this
signed value is always positive, but I know that it is, so I'm going to
cast, to tell the compiler that I know what I'm doing.

A better reasoning is: I'm converting a signed value to unsigned value,
which will not be correct if the signed value is negative. With this in
mind, you'll notice that the cast is utterly useless in catching the actual
error the compiler is warning you about.