short在绝大多数现代系统中为16位有符号整数，范围是-32768到32767；实际范围应通过SHRT_MIN/SHRT_MAX宏或std::numeric_limits<short>::min/max()获取，而非sizeof推算；有符号溢出是未定义行为，需警惕编译器优化导致边界检查失效。
short 在 C++ 里到底能存多大数字？
取决于平台和编译器，但绝大多数现代系统（x86/x64，GCC/Clang/MSVC）下，short 是 16 位有符号整数，取值范围固定为 -32768 到 32767（即 -2^15 到 2^15 - 1）。
这个范围由 C++ 标准保证最小宽度（至少 16 位），但不强制等于 16 位——理论上某嵌入式编译器可能让 short 占 32 位，不过现实中几乎不存在。你写的跨平台代码，基本可以安全按 16 位理解。
怎么查自己编译器的 short 实际范围？
别猜，用标准头文件 limits.h 或 climits 直接读宏定义，这是最可靠的方式：
#include <climits> // ... std::cout << "short min: " << SHRT_MIN << "\n"; std::cout << "short max: " << SHRT_MAX << "\n";
注意：SHRT_MIN 和 SHRT_MAX 是宏，不是函数，不能加括号调用；它们在 climits 中定义，在 limits.h 中也存在（C 风格）。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 如果用
std::numeric_limits<short>::min()，记得包含<limits> - 不要用
sizeof(short)推算范围——它只告诉你字节数，不告诉你是否补码、是否有填充位 - 在 Windows MSVC 下，
short和__int16等价；Linux GCC 下同理，但别依赖这种别名
为什么 short 有时比 int 还慢？
在 32/64 位 CPU 上，寄存器天然适合处理 32 位或 64 位数据。short 虽然占内存少，但每次读写常触发“读-修改-写”或零扩展/符号扩展操作，反而增加指令开销。
- 数组密集计算时，
vector<short>可能比vector<int>内存友好，但单次访问延迟略高 - 作为函数参数传递时，
short通常被提升为int（整型提升规则），实际栈上传的还是 4 字节 - 结构体里混用
short和char可能因对齐 padding 反而更占空间，得看alignof(short)
赋值超范围时会发生什么？
C++ 标准规定：有符号整数溢出是未定义行为（UB）。编译器可优化掉相关逻辑，或产生任意结果——不只是“绕回”。
常见现象包括：
- 值突然变成负数（比如
32767 + 1变成-32768），这只是常见实现（二进制补码）的巧合，不能依赖 - 开启
-fsanitize=undefined（Clang/GCC）会直接报错中断 - Release 模式下，编译器可能删掉整个 if 分支：“既然你写了
x > SHRT_MAX，那 x 就不可能是short，这分支永不执行”
所以，做边界检查时，务必在提升为 int 后比较，而不是对 short 变量直接加减再判断。
真正要注意的不是“最大值是多少”，而是“我有没有隐式提升、有没有被编译器优化掉检查、有没有在结构体里为了省字节反而浪费了对齐”。这些地方一不留神，bug 就藏得特别深。
