Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-11-28 04:57:24

On 28/11/2018 16:28, Emil Dotchevski wrote:
> Your position is self-contradictory. You're saying that under short
> operator+(short,short), it's fine to assume no overflow, without a warning,
> even though short overflow would produce incorrect y, but under int
> operator+(short,short) it's not fine to truncate the int result to short,
> without a warning, even though it would produce (on most platforms, exactly
> the same) incorrect y.

"int operator+(short, short)" simply shouldn't exist, because it's 
type-inconsistent.  (For example the others include "int operator+(int, 
int)" and "double operator+(double, double)" and you would generally 
expect things like "string operator+(string, string)" as well.)

Granted that some instruction sets provides things like 32*32=64, but 
C++ ignores those anyway.

If you are expecting a longer result than a short, then you should cast 
one of the operands to a larger type, just as you would if you were 
expecting a longer result than an int.

Why are "integers smaller than int" different from every other type in 
the language?

Integer promotion rules make sense in Ye Olde C with indeterminate type 
varargs and unspecified argument prototypes.  They don't make much sense 
once you move beyond that.

> The language currently works correctly in this case, thanks god. The idea
> that if x and y are of type short, then x+y should be of type short is
> utterly wrong. When you add two shorts, you get an int, because computing
> the int result does not use more resources than computing the short result.

That is not always true.  There are assembly instructions which can 
operate on values smaller than a register width, and if the compiler 
were able to use them then it might be able to use fewer registers for 
some code patterns, which might reduce use of memory (or cache), which 
can be a net performance benefit.

Granted this would probably be rare; processors are generally better at 
dealing with values in full register widths.

> And, of course, it should be truncated when stored in a short. And, of
> course, it would be lame to warn about the potential loss of data. It's
> just x+1, it's not that dangerous. :)

Until it is.