C语言中如何声明无符号短整型变量？

本文共计1023个文字，预计阅读时间需要5分钟。

它就是 `unsigned short`，`unsigned short int` 是合法的，但多余的完整写法，编译器会将其视为同一类型。C++ 标准中 `int` 在 `short` 后面是可选的，就像 `signed int` 可以简写为 `signed` 一样。

实际编码中几乎没人写 unsigned short int，原因有三：一是多打五个字符，二是易读性没提升，三是部分旧代码检查工具会警告“冗余类型说明符”。

• unsigned short —— 推荐，简洁且无歧义
• uint16_t —— 更推荐（需 #include <cstdint>），语义明确、宽度固定
• unsigned short int —— 合法，但属于教科书式写法，工程中少见

为什么不能直接用 unsigned short 存储 65535 就一定安全？

因为 unsigned short 的位宽不保证是 16 位，只保证 ≥16 位（C++ 标准要求至少能表示 0 到 65535）。在绝大多数桌面/服务器平台（x86/x64）上它是 16 位，但在某些嵌入式平台（比如 TI C2000 系列 DSP）上可能是 20 位甚至 24 位。

这意味着：如果代码依赖“正好 16 位”做位操作、内存布局或网络传输，直接用 unsigned short 会出问题。

立即学习“C++免费学习笔记（深入）”；

• 跨平台通信时，用 uint16_t 才能确保发送/接收双方解释一致
• 做位域（bit-field）时，unsigned short : 12 的行为可能因平台而异
• 结构体对齐和序列化时，sizeof(unsigned short) 可能不是 2

常见错误：把 unsigned short 当作“更省内存”的万能替代

有人看到 int 占 4 字节，就以为换成 unsigned short 能省一半内存——这在数组或结构体里看似成立，但容易忽略隐式转换开销和 ABI 兼容问题。

比如函数参数传 unsigned short，在 x86-64 System V ABI 下会被提升为 int 传参；返回值同理。你省了存储，却没省寄存器或调用开销。

• 数组大量使用时，vector<uint16_t> 确实比 vector<int> 节省内存，但访问局部性可能变差（CPU 缓存行利用率下降）
• 不要用 unsigned short 做循环变量（如 for (unsigned short i = 0; i ），溢出后行为难调试（<code>i 从 65535 变成 0）
• 与 size_t 或指针运算混用时，会触发整型提升，可能产生意外的符号扩展或截断警告

什么时候该用 uint16_t 而不是 unsigned short

只要涉及二进制兼容、硬件寄存器映射、文件格式解析、网络协议字段定义，一律优先选 uint16_t。

它来自 <cstdint>，是 C++11 引入的精确宽度整型，只有当平台确实支持 16 位无符号整数时才会定义。如果编译失败，说明目标平台不满足前提，比运行时行为不确定强得多。

• 读写 BMP 文件头中的 bfOffBits 字段 → 必须用 uint16_t
• 映射 STM32 的 ADC_DR 寄存器（16 位只读）→ volatile uint16_t*
• 定义 Protocol Buffer 中的 fixed32 对应字段 → 用 uint16_t 避免平台差异

真正麻烦的从来不是怎么写，而是哪一层该关心宽度——类型名本身就在传递契约。用 unsigned short 表示“差不多短就行”，用 uint16_t 表示“必须刚好 16 位”。这个分寸，一不留神就埋在线上环境的字节序或截断 bug 里。