On Wed, Nov 21, 2018 at 7:43 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 22/11/2018 14:49, Emil Dotchevski wrote:
First, any change in a correct program can introduce a new bug.
"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
Secondly, 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