Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-11-28 08:57:02

Am 27.11.18 um 22:01 schrieb Emil Dotchevski via Boost:
> The problem is that implicit conversions happen a lot in C++ and it is
> wrong for the compiler to warn you about things you should know. By your
> logic this code should generate a warning:
>
> short x;
>
> ++x;
>
> Semantically, ++x contains an implicit conversion from int to short, which
> can result in loss of data.
In this case I expect no warning. The initial conversion to int is a 
(strange) detail of C/C++. If I explicitly choose to operate on a short, 
why would I want an int? if "x" were an int, should it be promoted to a 
wider type on addition? If not, where is the consistency?
So: Compiler can see *intend* here and not produce a warning.
> Same is true about signed/unsigned implicit conversions. Do you want a
> warning in this case?
>
> unsigned x;
> int y;
>
> x += y;
>
> You're adding a signed int to an unsigned int, that seems so dangerous! You
> better cast, that would be so much safer. :)
It is not about safer per se, it is about intend. If you cast explicitly 
you show intend (implying you checked the preconditions or have own 
assumptions on the value range in your domain), using the implicit cast 
*may* be a bug for all the compiler knows: "y = -(x+1)" -> Boom
So it's all about: I know what I'm doing instead of I may know what I'm 
doing.
> To me it seems like a potential bug, introduced by a programmer who is
> unsure about implicit conversions in C. Semantically, I can't imagine why I
> would want the call to f to always cast to unsigned. Consider:
>
> void f( unsigned );
> void f( int ); //Later we add this overload
>
> void g( int x )
> {
>    assert(x>=0);
>    f(unsigned(x));
> }
Again: Intend. What if the (original) call to unsigned f is the correct 
one? Not using the cast now changes other, seemingly unrelated code just 
by adding a new function and may hence *introduce* a bug rather than 
avoid it.