sizeof（short）=sizeof（int）实现的整数提升 背景 我正在研究C++中的整数提升规则，并遇到以下（取自）：

4.5.1[pconv.prom]

如果

int

可以表示源类型的所有值，则除

bool

、

char16\u t

、

char32\u t

或

wchar\u t

以外的整数类型的PR值（其整数转换秩（4.13）小于

int

可以转换为

int

类型的PR值； 否则，可以将源prvalue转换为类型为的prvalue

无符号整数

4.13.1.3[conv.rank]

• long-long-int

  的等级应大于

  long-int

  的等级，后者应大于

  int

  的等级，后者 应大于

  short int

  的等级，该等级应大于 而不是

  有符号字符的秩

5.10[expr]

许多需要算术或枚举类型操作数的二进制运算符会导致转换并产生结果 以类似的方式输入。其目的是生成一个通用类型，该类型 也是结果的类型。这种模式被称为普通模式 算术转换，定义如下：

[省略了许多要点]

• 否则，应在两个操作数上执行积分提升（4.5）

[进一步遗漏]

问题: 鉴于

short int

的大小和范围可能与

int

的大小和范围相同，因此在这些情况下，似乎没有必要将

short int

提升为

int

。然而，上面没有提到这样一个例外

标准是否要求在这些情况下将

short int

提升为

int

（即使在生成的同一可执行文件中预先假定了实现优化）

附注/补充问题

---

我还注意到，措辞中使用了“可以是”而不是“应该是”，这是故意的吗？

这是完全合法的，而且曾经非常普遍，因为

short

和

int

具有相同的范围和表示；即使在今天，嵌入式系统对两者使用相同的16位表示也并不少见。C规范确实包含一些特定于此类实现的语言，因为在此类平台上，

unsigned short

提升为

unsigned int

，而在后者可以表示

unsigned short

的所有值的平台上，它提升为

signed int

。它并没有免除此类实现的规则要求将小于

int

或

unsigned int

的类型升级为其中一种类型，因为此类免除不会带来任何好处

---

该标准允许实现以其认为合适的任何方式执行计算，如果在所有情况下，

int

或

unsigned int

的指定提升将产生定义的行为，则实现的计算产生相同的行为（假设规则）。如果类型为

int

和

short

的右值的行为无法区分，则这意味着如果实现选择在

short

上执行计算，而不是在

int

上执行计算。没有必要在标准中添加一条规则来豁免

int

大小的

short

类型的升级，因为“仿佛”规则已经足够了。

是什么让你认为

short int

可以具有与

int

相同的大小和范围？@Javia1492标准定义了它so@Javia：因为它可以。e、 g.

short int

要求至少为16位，在很长一段时间内，大多数环境将

int

设置为16位类型。因此……@Javia1492：是什么让你认为它不能？正如其他人所提到的，除了一些系统将

short

和

int

都设置为16位之外，我还研究了两个都是64位的系统（克雷矢量系统）。这两种方法都是完全有效的。如果

short

和

int

大小相同，则促销成本为零。感谢，似乎部分解决了这一问题：）@OMGtechy：直到最近，几乎所有的编译器都遵守另一条似乎规则，但这条规则从未添加到标准中：如果整数的结果

+

，

-

，

*

或按位运算符被强制转换或强制转换为小于

int

的无符号整数类型，结果应与操作数被强制转换为该较小类型以及使用该类型执行的操作相同。在标准规定行为的所有情况下，它要求编译器的行为与规则规定的行为相同，但标准未定义某些情况语句

x*=x

在

int

为16位或至少33位的所有编译器上的行为相同，但在

int

为32位的编译器上可能会否定时间定律和因果关系。我不认为允许

int

为17到32位的平台与

int

为任何其他大小的平台具有不同的行为有任何好处，但目前的标准免除了此类编译器遵守无符号类型应遵守模运算规则的原则。