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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk