Re: [boost] Current Guidance on Compiler Warnings?

On 26/11/2018 15:50, Emil Dotchevski wrote:

...

This is similar to the implicit conversion, except it doesn't eliminate

On Sun, Nov 25, 2018 at 8:52 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote: 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::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::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.