许多类似问题的答案都指出，这是由于标准造成的。但是，我无法理解标准制定者做出这一决定背后的原因。
据我了解unsigned char不以 2 的补码形式存储值。所以，我没有看到这样的情况XORing two unsigned chars会产生意想不到的行为。因此，推动他们int看起来像是浪费空间（在大多数情况下）和 CPU 周期。
此外，为什么int？如果变量被声明为unsigned，显然无符号性对于程序员来说很重要，因此晋升为程序员unsigned int仍然比int， 在我看来。
[编辑 #1] 正如评论中所述，晋升为unsigned int如果发生int无法充分容纳该值unsigned char.
[编辑#2] 为了澄清这个问题，是否与操作的性能优势有关int than char，那么为什么它会出现在标准中呢？这可以作为编译器设计者更好优化的建议。现在，如果有人要设计一个不这样做的编译器，那么他们的编译器就不会完全遵守 C/C++ 标准，尽管假设该编译器确实支持该语言的所有其他所需功能。简而言之，我不明白为什么我不能直接操作unsigned chars，因此需要将他们提升为ints，似乎没有必要。你能给我一个例子来证明这是错误的吗？
您可以在线找到此文档：国际标准的基本原理 - 编程语言 - C（修订版 5.10，2003 年） http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf.
第 6.3 章（第 44 - 45 页）是关于转换的
从K&R的发布到C89的开发，整数提升规则的演进实现之间出现了严重的分歧。实施分为两个主要阵营，其特点是无符号保留 and 保值.
这些方法之间的差异集中在治疗上unsigned char and unsigned short当通过整数提升扩大时，但该决定也会对常量的类型产生影响（参见§6.4.4.1）。
The 无符号保留方法要求将两个较小的无符号类型提升为unsigned int。这是一个简单的规则，并产生一个独立于执行环境的类型。
The 保值方法要求推广这些类型signed int如果该类型可以正确表示原始类型的所有值，否则将这些类型提升为unsigned int.
因此，如果执行环境表示short作为小于int, unsigned short变成int;否则就会变成unsigned int。两种方案在绝大多数情况下都给出了相同的答案，并且在使用二进制补码算术和带符号溢出的安静环绕的实现中（即在大多数当前实现中）的更多情况下都给出了相同的有效结果。在此类实现中，仅当这两个条件都为真时，才会出现两者之间的差异：
包含一个表达式unsigned char or unsigned short产生一个int-wide 结果，其中符号位被设置，即，对此类类型进行一元运算，或其中另一个操作数是int或“较窄”类型。
-
上述表达式的结果在其符号性很重要的上下文中使用：
• sizeof(int) < sizeof(long)并且它处于必须扩展为长类型的上下文中，或者
• 在将移位定义为算术的实现中，它是右移运算符的左操作数，或者
• 它是/、%、 或>= 操作数。
在这种情况下，解释就会产生真正的模糊性。结果必须被称为有问题的签名，因为可以为签名或未签名的解释提供案例。每当unsigned int面对一个signed int跨操作员，并且signed int具有负值。在解决这场对抗的模糊性方面，这两种方案都没有做得更好，也没有做得更差。突然负面signed int变成一个非常大的unsigned int，这可能令人惊讶，也可能正是知识渊博的程序员所期望的。当然，所有这些歧义都可以通过明智地使用强制转换来避免.
探索这个问题的重要成果之一是认识到高质量的编译器可能会很好地查找此类有问题的代码并提供（可选）诊断，并且认真的讲师可能会很好地警告程序员隐式类型转换的问题。
无符号保留规则大大增加了以下情况的数量：unsigned int面对signed int产生一个有问题的签名结果，而保值规则则最大限度地减少了这种对抗。因此，保值规则被认为对于新手或粗心的程序员来说更安全。经过多次讨论，C89 委员会决定支持值保留规则，尽管 UNIX C 编译器已经朝着无符号保留的方向发展。
C89 悄然发生变化
依赖于无符号保留算术转换的程序的行为会有所不同，可能不会有任何抱怨。这被认为是 C89 委员会对当前广泛实践所做的最严重的语义更改。
作为参考，您可以在此处找到有关更新到 C11 的转换的更多详细信息answer https://stackoverflow.com/a/46073296/4944425 by Lundin https://stackoverflow.com/users/584518/lundin.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
