Re: [boost] Current Guidance on Compiler Warnings?

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

On Wed, Nov 21, 2018 at 7:43 PM Gavin Lambert via Boost <
boost_at_[hidden]> wrote:
>
> On 22/11/2018 14:49, Emil Dotchevski wrote:
> > First, any change in a correct program can introduce a new bug.
Secondly,
> > "fixing" a warning often alters the semantics of the operation in a
subtle
> > way. Consider for example the use of an explicit cast to silence a
warning
> > that an implicit conversion may lead to something bad. You may think
that
> > all you've done is silence the warning, but in fact you've changed the
> > program semantically: it no longer does an implicit type conversion,
> > instead it does an explicit one. And the thing is, one of the two is
> > incorrect.
> >
> > Now, if your programmers don't understand how implicit type conversions
> > work in C++, it is possible that enforcing warning-free compilation
avoids
> > more bugs than it causes. If that's the case, there's no argument.
>
> Perhaps I am one of these programmers who don't understand how implicit
> type conversions work (although I don't believe so), but...
>
> Where implicit conversions are permitted, there is no difference in
> actual compiled behaviour at the call site between an implicit and
> explicit conversion.  At all.  They are utterly identical.

Nope, they're different. Implicit conversions convert to the target type,
while a static_cast converts to what you tell it to convert. Consider:

void f(long);
void f(short);
void f(double);
....

f(x);

Is semantically different from

f( static_cast<short>(x) );

Things get even more interesting if you cast to a typedef:

f( static_cast<int32_t>(x) );

The point is, if casting is correct, then the implicit conversion is not.
If the implicit conversion is correct, then casting is not. You should
write the correct code even if that leads to a warning. And if you must
silence the warning, you should do it without changing the behavior of a
correct program.