short 在循环中自增为什么会卡住或跳变
因为 short 是有符号 16 位整数，取值范围是 -32768 到 32767。一旦加到 32767 后再执行 ++，会触发有符号整数溢出，行为未定义（C++ 标准不保证结果），但绝大多数编译器实际表现为回绕成 -32768 —— 这不是“错误”，而是底层二进制补码自然翻转的结果，但程序逻辑通常没预料到这点。
- 常见错误现象：
for (short i = 0; i 会无限循环，因为 <code>i永远不会 ≥ 40000（它到 32767 后变成负数） - 使用场景：嵌入式或内存敏感环境可能真用
short做计数器，但必须明确控制上限 ≤ 32767 - 别依赖“自动回绕”写逻辑：C++ 不保证溢出后一定是 -32768，优化级别升高时编译器可能直接删掉整个循环（认为条件永远为假）
- 实操建议：循环变量优先用
int；若必须用short，改用无符号类型unsigned short（范围 0–65535），此时溢出行为是明确定义的回绕
unsigned short 溢出后到底怎么算
unsigned short 的溢出是标准规定的模运算：超出最大值后对 65536 取余。比如 65535 + 1 → 0，65534 + 5 → 3。这比有符号安全得多，但依然得小心边界判断。
- 常见错误现象：
for (unsigned short i = 0; i 会多跑一轮（从 65535 → 0 后继续），导致 i == 0 被重复处理 - 正确写法应是
i 或更直观地用 <code>i != 65535U + 1U（但没必要，直接换int更稳妥） - 注意隐式转换：
unsigned short x = 65535; int y = x + 1;中，x先提升为int，结果是 65536，不会溢出 —— 但若写成unsigned short z = x + 1;，则 65536 对 65536 取余得 0
clang/gcc 对 short 溢出的警告和优化陷阱
默认编译下，g++ 和 clang++ 不报有符号溢出警告，但开启 -Woverflow 或 -fsanitize=undefined 就能捕获。更危险的是，高优化等级（如 -O2）下，编译器看到 i 且 <code>i 是 short，会直接推断该循环永不终止并优化掉——生成的汇编里可能根本没有循环体。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 实操建议：开发阶段加
-fsanitize=undefined，运行时报错定位溢出点；CI 流水线中至少启用-Woverflow -Wsign-compare - 不要用
short存储可能超限的中间计算结果，比如short a = 30000, b = 30000; short c = a + b;—— 此处a + b先提升为int计算，但赋值给short会截断，丢失高位，且无警告 - 若结构体里为省空间用
short，确保所有读写路径都严格在 [-32768, 32767] 内，最好加静态断言：static_assert(std::numeric_limits<short>::max() == 32767, "");</short>
什么时候真该用 short 而不是 int
只有两种情况值得考虑：内存带宽/缓存行敏感场景（如处理百万级 short 数组，且 CPU 缓存小）、与硬件/协议强制对齐的接口（如某些传感器寄存器只接受 16 位值）。除此之外，现代 x86/x64 上 int 和 short 运算性能几乎无差别，寄存器都是 32/64 位，short 还要额外做符号扩展或截断。
立即学习“C++免费学习笔记（深入）”；
- 反模式示例：用
short当容器索引（std::vector<T>::size_type是size_t，不是short） - 替代方案：想节省内存？用
std::vector<int16_t>明确语义；想约束范围？用强类型封装（如struct Temperature { short value; };），配合构造函数检查 - 最容易被忽略的一点：
sizeof(short)在不同平台不固定（C++ 只要求 ≥sizeof(char)），虽然主流平台都是 2 字节，但裸写short时心里得清楚这是平台约定，不是语言保证
