整型提升在C++中指将char、short、bool等窄整型隐式转为int或unsigned int的规则，触发于二元运算、函数调用等场景，影响位运算、比较和溢出行为，需通过固定宽度类型和显式转换安全应对。
在C++中，整型提升（Integer Promotion）是表达式计算时一个关键但常被忽略的隐式转换规则。它不改变值，但可能改变类型、影响运算结果（尤其是位运算、比较、赋值），甚至引发未定义行为。理解它，是写出可移植、健壮整型代码的基础。
什么情况下触发整型提升？
当表达式中出现比 int 更小的整型（如 char、short、bool、enum 且其底层类型小于 int）参与运算时，编译器会自动将其提升为 int（或 unsigned int，仅当 int 无法表示原类型所有值时才用后者）。
- 常见场景：函数参数传递（非模板/非引用）、二元运算符（+、&、|、== 等）、条件表达式（? :）中的子表达式
- 注意：它只发生在“窄整型”上；long、long long、int 自身不提升
- 数组下标、sizeof、typeid 等上下文中不发生提升
提升目标类型怎么选？int 还是 unsigned int？
标准规定：若所有 int 值都能表示该类型的全部取值，则提升为 int；否则提升为 unsigned int。这取决于平台的 int 位宽与源类型的有符号性。
- 典型情况（ILP32 或 LP64）：signed char、short → int；unsigned char、unsigned short → int（因为 int 通常 ≥16 位，能容纳 0~255 或 0~65535）
- 特殊情况（如 16 位系统）：unsigned int 只有 16 位，此时 unsigned short 提升为 unsigned int（因 int 也是 16 位，无法表示 unsigned short 的最大值 65535）
- bool 总是提升为 int（false→0，true→1）
为什么它会影响程序行为？
整型提升不是“透明”的——它可能改变溢出行为、符号扩展方式、位宽，进而影响逻辑判断和位操作结果。
立即学习“C++免费学习笔记（深入）”；
- 符号问题：对 signed char c = -1; 执行 c & 0xFF，先提升为 int(-1)（即 0xFFFFFFFF），再与 0xFF（提升为 0x000000FF）按位与，结果是 0xFF（255），而非预期的 -1
- 比较陷阱：unsigned short us = 65535; 与 int i = -1; 比较：us == i 实际是 (int)65535 == -1 → false；但若平台中 int 是 16 位，则 us 提升为 unsigned int，而 i 也会被转换为 unsigned int（-1 → 65535），结果变成 true
- 位运算截断：char a = 0x80, b = 0x01;，a 先提升为 int(0xFFFFFF80) ，结果是 0xFFFFFF00，再赋给 char 时才截断——不是直接在 8 位上左移
如何安全应对整型提升？
不靠记忆规则，而用显式、可控的方式管理类型。
- 涉及位操作或精确宽度时，优先使用 std::uint8_t、std::int16_t 等固定宽度类型，并在运算前显式转回目标宽度（如 static_cast
(a & b) ） - 避免混合有符号/无符号窄类型参与比较或算术，统一提升到相同明确类型（如都转成 int 或 unsigned int）
- 使用 clang -Wsign-conversion 或 gcc -Wconversion 编译选项捕获潜在提升导致的隐式符号变化
- 对布尔参与算术（如 bool + int），明确写成 static_cast
(b) + i ，避免依赖提升语义
整型提升不是 bug，而是 C++ 类型系统在兼容性和效率间做的权衡。它不复杂，但容易忽略细节。写表达式时多问一句“这里每个操作数实际是什么类型”，就能避开大多数坑。
