unsigned short 的取值范围标准规定为 0 至 65535，但实际取决于平台实现，可能为 16 位（常见）或更宽（如 TI C2000 的 32 位），应使用 std::numeric_limits<unsigned short>::max() 或 uint16_t 确保可移植性。
unsigned short 的取值范围是多少
标准规定是 0 到 65535（即 216 − 1），但这个“16 位”不是绝对的——它取决于编译器和平台对 short 的实际实现。
常见场景下（x86/x64 上的 GCC、Clang、MSVC），short 确实占 2 字节，所以 unsigned short 就是 0～65535。但 C++ 标准只要求 short 至少能表示 −32767～+32767（即至少 16 位宽），理论上允许更宽（比如某些嵌入式平台用 32 位 short）。
- 查实际宽度最可靠的方式是
sizeof(unsigned short)+std::numeric_limits<unsigned short>::max()</unsigned> - 别硬编码 65535 做边界判断；用
std::numeric_limits<unsigned short>::max()</unsigned>更安全 - 在跨平台或嵌入式项目中，如果依赖“一定是 16 位”，建议改用
uint16_t（需#include <cstdint>）
为什么有时 sizeof(unsigned short) != 2
这不是 bug，是标准留的余地。C++ 只规定 sizeof(short) >= sizeof(char) 且 sizeof(int) >= sizeof(short)，没锁死字节数。
典型例外：TI C2000 DSP 编译器把 short 实现为 32 位；某些老款 DSP 或定制 ABI 也可能如此。这时候 unsigned short 范围就是 0～4294967295。
立即学习“C++免费学习笔记（深入）”；
- 现象：代码在 PC 上跑得好好的，移植到 DSP 后数值截断或逻辑异常
- 原因：假设了
unsigned short必然是 16 位，但实际是 32 位，导致位操作、序列化、内存布局错位 - 检查方法：
static_assert(sizeof(unsigned short) == 2, "unexpected short size");编译期兜底
unsigned short 和 uint16_t 到底该用谁
看需求：要可移植性就选 uint16_t；要兼容旧接口或最小内存占用（且已知平台行为）才考虑 unsigned short。
uint16_t 是 typedef 到某个恰好 16 位无符号整型的别名，不存在时（如某些平台不支持精确 16 位类型）uint16_t 根本不会定义（可用 std::optional<uint16_t> 或宏 UINT16_MAX 是否存在来判断）。
- 网络协议字段、文件格式、硬件寄存器映射 → 无条件用
uint16_t - 函数参数/返回值需匹配已有 C API（比如 Windows 的
WORD或 POSIX 的u_short）→ 用unsigned short - 性能敏感循环里频繁使用 → 差异通常可忽略，现代 CPU 对 16/32 位运算吞吐差别不大，别过早优化
容易被忽略的隐式转换陷阱
当 unsigned short 参与算术运算时，会先整型提升（integer promotion）为 int（即使值很小）。这本身没问题，但若结果再赋回 unsigned short，就可能静默截断。
unsigned short a = 65535; unsigned short b = 1; auto c = a + b; // 类型是 int！值为 65536 unsigned short d = a + b; // 截断：d == 0 —— 没警告，但逻辑崩了
- 现象：计算结果突变为 0 或很小的数，调试时发现中间变量类型意外变大
- 编译器很少为此报 warning，除非开了
-Wconversion（GCC/Clang）或/Wall（MSVC） - 安全写法：显式转换 + 断言，例如
unsigned short d = static_cast<unsigned short>(a + b); assert(d == a + b); - 更稳妥：全程用
uint16_t并配合std::add_overflow（C++23）或手动检查
实际项目里，这种截断常出现在索引计算、长度累加、状态机计数等地方，一旦出问题很难复现。比范围本身更值得花时间盯住的是——它参与运算时怎么不出事。
