c++ - 为什么对无符号字符的算术运算将它们提升为有符号整数？

Question

很多类似问题的回答都指出，标准是这样的。但是，我无法理解标准制定者做出这一决定背后的原因。

据我了解 unsigned char不以 2 的补码形式存储值。所以，我没有看到让我们说 的情况。异或 ing 二 unsigned chars会产生意想不到的行为。因此，将它们提升到 int似乎只是浪费空间(在大多数情况下)和 CPU 周期。

而且，为什么int ?如果变量被声明为 unsigned ，显然无符号对程序员很重要，因此升级为 unsigned int仍然比 int 更有意义， 在我看来。

[编辑 #1] 如评论中所述，升级到 unsigned int如果 int 将发生无法充分容纳 unsigned char 中的值.

[编辑 #2] 为了澄清这个问题，如果它是关于在 int 上运行的性能优势吗？比char ，那为什么在标准中呢？这可以作为向编译器设计者提供更好优化的建议。现在，如果有人要设计一个不这样做的编译器，这将使他们的编译器不完全遵守 C/C++ 标准，即使假设该编译器确实支持该语言的所有其他必需功能。简而言之，我想不出为什么我不能直接通过 unsigned chars 操作的原因。 ，因此需要将它们提升到 ints ，似乎没有必要。你能举个例子证明这是错误的吗？

Answer 1

您可以在线找到此文档:Rationale for International Standard - Programming Languages - C (Revision 5.10, 2003) .

第 6.3 章(第 44 - 45 页)是关于转换的

Between the publication of K&R and the development of C89, a serious divergence had occurred among implementations in the evolution of integer promotion rules. Implementations fell into two major camps which may be characterized as unsigned preserving and value preserving.

The difference between these approaches centered on the treatment of unsigned char and unsigned short when widened by the integer promotions, but the decision had an impact on the typing of constants as well (see §6.4.4.1).

The unsigned preserving approach calls for promoting the two smaller unsigned types to unsigned int. This is a simple rule, and yields a type which is independent of execution environment.

The value preserving approach calls for promoting those types to signed int if that type can properly represent all the values of the original type, and otherwise for promoting those types to unsigned int.

Thus, if the execution environment represents short as something smaller than int, unsigned short becomes int; otherwise it becomes unsigned int. Both schemes give the same answer in the vast majority of cases, and both give the same effective result in even more cases in implementations with two's complement arithmetic and quiet wraparound on signed overflow - that is, in most current implementations. In such implementations, differences between the two only appear when these two conditions are both true:

1. An expression involving an unsigned char or unsigned short produces an int-wide result in which the sign bit is set, that is, either a unary operation on such a type, or a binary operation in which the other operand is an int or “narrower” type.

2. The result of the preceding expression is used in a context in which its signedness is significant:

   • sizeof(int) < sizeof(long) and it is in a context where it must be widened to a long type, or

   • it is the left operand of the right-shift operator in an implementation where this shift is defined as arithmetic, or

   • it is either operand of /, %, <, <=, >, or >=.

In such circumstances a genuine ambiguity of interpretation arises. The result must be dubbed questionably signed, since a case can be made for either the signed or unsigned interpretation. Exactly the same ambiguity arises whenever an unsigned int confronts a signed int across an operator, and the signed int has a negative value. Neither scheme does any better, or any worse, in resolving the ambiguity of this confrontation. Suddenly, the negative signed int becomes a very large unsigned int, which may be surprising, or it may be exactly what is desired by a knowledgeable programmer. Of course, all of these ambiguities can be avoided by a judicious use of casts.

One of the important outcomes of exploring this problem is the understanding that high-quality compilers might do well to look for such questionable code and offer (optional) diagnostics, and that conscientious instructors might do well to warn programmers of the problems of implicit type conversions.

The unsigned preserving rules greatly increase the number of situations where unsigned int confronts signed int to yield a questionably signed result, whereas the value preserving rules minimize such confrontations. Thus, the value preserving rules were considered to be safer for the novice, or unwary, programmer. After much discussion, the C89 Committee decided in favor of value preserving rules, despite the fact that the UNIX C compilers had evolved in the direction of unsigned preserving.

QUIET CHANGE IN C89

A program that depends upon unsigned preserving arithmetic conversions will behave differently, probably without complaint. This was considered the most serious semantic change made by the C89 Committee to a widespread current practice.

作为引用，您可以在此 answer 中找到有关更新到 C11 的那些转换的更多详细信息。来自 Lundin .