short运算自动提升为int，是C++标准规定的整型提升规则；两个short相加结果为int，直接赋值给short可能引发有符号溢出等未定义行为。
short 运算时自动提升为 int，不是你想象的“原地计算”
几乎所有 short 的算术运算（+、-、*、/、%）都会先被提升为 int，再计算。这不是编译器优化，是 C++ 标准规定的整型提升（integer promotion）规则。哪怕两个 short 相加，结果类型也是 int，不是 short。
常见错误现象：short a = 32767; short b = 1; short c = a + b; 看似合理，但实际触发未定义行为——因为 a + b 是 int 类型（32768），赋值给 short c 时发生有符号溢出。
- 使用场景：当你需要紧凑内存布局（如大量数组）但又得做中间计算时，不能假设运算全程在
short范围内 - 参数差异：函数形参为
short不影响实参提升；模板推导时short传入可能被推成int（取决于上下文） - 性能影响：提升本身无开销，但后续若频繁强制转回
short，可能阻碍寄存器复用或触发额外截断指令
赋值和显式转换必须自己动手，编译器不会“帮你缩回去”
从 int 结果写回 short 变量，是显式收缩（narrowing），C++17 起会触发警告（-Wnarrowing），且不检查运行时溢出。它只截低 16 位，不管符号。
示例：short x = 32768; 在大多数平台得到 -32768（补码截断），但这是实现定义行为，不是标准保证。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：用
static_cast<short>(expr)</short>明确表达意图，但依然不校验 - 真要防溢出：先判断范围，比如
if (expr >= -32768 && expr (expr); - 别依赖
short x = expr;隐式转换——它等价于static_cast，且更隐蔽
printf / scanf 里用错格式符，直接 UB
short 传给 printf 必须用 %hd，不是 %d；scanf 读 short* 必须用 %hd，否则栈上字节错位，轻则输出乱码，重则崩溃。
错误示例：short s = 42; printf("%d", s); —— s 被提升为 int 传入，但 %d 仍按 int 解释，看似碰巧对，实则依赖调用约定，不可靠。
- 正确写法：
printf("%hd", s);、scanf("%hd", &s); - 用
std::cout更省心：std::cout 自动处理类型，无需格式符 - 跨平台注意：Windows MinGW 和某些嵌入式 libc 对
%hd支持不一，CI 中建议加测试用例验证
模板和 auto 推导时，short 很容易“消失”
auto 声明变量时，如果初始化表达式含 short 运算，推导结果几乎总是 int；模板函数实参推导也一样。这不是 bug，是类型系统忠实反映运算结果类型。
示例：short a = 1, b = 2; auto x = a + b; → x 是 int，不是 short。想保持 short，必须显式写 short x = a + b; 或 auto x = static_cast<short>(a + b);</short>
- 陷阱：用
auto写容器迭代器或算法返回值时，误以为类型和容器元素一致（比如vector<short>::value_type</short>），其实可能差一个提升层 - 调试技巧：用
typeid(x).name()或编译器扩展（如 GCC 的__PRETTY_FUNCTION__）看真实类型 - 兼容性提醒：C++20
std::span<short></short>的operator[]返回short&，但下标运算本身不触发提升；而std::accumulate默认用int累加，需传自定义初值才能保short
最易忽略的一点：整型提升发生在表达式求值期，和变量存储无关。哪怕你把 short 存在寄存器里，只要参与二元运算，就立刻“变 int”。别指望硬件级 short 运算——现代 CPU 几乎没有原生 short ALU 指令，全是靠 int 寄存器模拟的。
