On 7/9/21 7:26 PM, Martin Sebor wrote:
On 7/8/21 8:08 PM, LIU Hao via Gcc-help wrote:
在 7/8/21 8:05 PM, johnsfine--- via Gcc-help 写道:
This is not the forum for such a discussion. But I want to make
people reading this aware that many expert C and C++ programmers
(likely a majority) consider that advice to avoid unsigned types to
be horrible advice.
I'm sorry if it's not the right place, I could remove the lists
from the CC if it's too noisy, but I think an important point is
here, and a couple of emails won't damage too much the mailing lists.
On the other hand, I consider bad etiquette removing CCs from
a discussion.
I advise people to avoid signed types and I do so myself. If an
integer value won't be negative, it shouldn't be signed. That makes
your intent clearer to anyone reading your code, and (especially in
x86-64) lets the compiler generate smaller and faster code.
As others have showed with facts, and the Google style guide also hints,
using unsigned types just removes the opportunity of the compiler
to optimize on overflow, because it has to account for wrapping around.
That makes no sense. Would you prefer unsigned integers to signed
ones, for something that can only be one of {1,2,3,4}? Just because
something can't be negative, does not mean it should be unsigned.
That.
The same way that because a number is never going to be
greater than 100 is it any better to use [u]int256_t.
Just use int, unless you have a reason not to.
Please John, read the paper from Bjarne about unsigned types,
it really covers a lot. If you still disagree after reading that,
feel free to argument it.
<http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1428r0.pdf>
There are benefits to making that explicit by choosing an unsigned
type: the result of converting a narrower unsigned type to a wider
unsigned type is unchanged. The result of converting it to a wider
signed type may change. This has an impact on value range propagation
which in turn can influence other optimizations as well as warnings.
That problem with implicit conversions to larger types is not a
problem of signed integers, not even a problem of unsigned integers.
It's a problem of mixing both.
If you use signed integers for everything, you won't have that problem.
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
