short 通常占 2 字节，char 固定占 1 字节；C++ 标准规定 short 至少 16 位、char 恰为 1 字节，主流编译器在 x86/x64 上均严格遵循。
short 和 char 在内存里占几个字节？short 通常占 2 字节（16 位），char 固定占 1 字节（8 位）——这是最硬的差别，不看平台也基本成立。C++ 标准只要求 short ≥ 16 位、char = 1 字节，实际主流编译器（GCC/Clang/MSVC）在 x86/x64 上都严格按此实现。
用 sizeof 一试便知：
std::cout << sizeof(short) << " " << sizeof(char); // 通常输出：2 1
- 如果你只存 ASCII 字符（0–127）或小范围计数（比如数组下标 ≤ 255），
char 更省空间
- 但一旦要存 -100 到 200 这种跨正负的小整数，
char 就不够用了——它可能是有符号的（-128~127），也可能是无符号的（0~255），取决于编译器和选项（如 -fsigned-char），而 short 明确是有符号的（-32768~32767），行为更可预测
unsigned char 和 short 能互相替代吗？
不能直接替代，尤其在算术运算和类型推导场景下容易出错。
-
unsigned char 是纯无符号 8 位，溢出时自动回绕（255 + 1 → 0）
-
short 是有符号 16 位，溢出是未定义行为（UB），可能崩溃、静默错值，或被编译器优化掉逻辑
char 更省空间 char 就不够用了——它可能是有符号的（-128~127），也可能是无符号的（0~255），取决于编译器和选项（如 -fsigned-char），而 short 明确是有符号的（-32768~32767），行为更可预测 -
unsigned char是纯无符号 8 位，溢出时自动回绕（255 + 1 → 0） -
short是有符号 16 位，溢出是未定义行为（UB），可能崩溃、静默错值，或被编译器优化掉逻辑
常见翻车点：
- 把
unsigned char<em></em>强转成short后直接解引用——会读 2 字节，但原始数据只写了 1 字节，另一半是栈/堆上的垃圾值 - 用
vector<char></char>存二进制图像像素（0–255），想用reinterpret_cast<vector<short>&></short>加速处理？不行，字节序、对齐、大小都不匹配
实操建议：
- 传输或存储单字节数据（如网络协议字段、文件头）→ 用
unsigned char或std::byte（C++17） - 做中间计算、需要负数或稍大范围（比如音频采样偏移量）→ 用
short，别图省那 1 字节
指针运算时步长差一倍，很容易越界unsigned char* 每次 ++ 移动 1 字节，short* 每次 ++ 移动 2 字节——这在操作 raw buffer 时是高频坑点。
比如这段代码看着没问题，其实危险：
unsigned char buf[4] = {1, 2, 3, 4};
short* p = reinterpret_cast<short*>(buf);
std::cout << p[0] << " " << p[1]; // 输出：513 ?（1+2×256）和一个越界读！原因：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
p[0]读buf[0]和buf[1]（小端下是 1 + 2×256 = 513） -
p[1]读buf[2]和buf[3]→ 表面合法，但如果buf是栈上局部数组且后面没初始化，buf[3]后面那个字节就是未定义内容
正确做法：
- 明确用途再选类型：存字节流就用
unsigned char<em></em>，做批量短整数运算就用std::vector<short></short>或对齐分配的short - 必须类型重解释时，先确认源缓冲区长度是目标类型的整数倍，并检查对齐（
alignof(short)通常是 2）
为什么不该用 char 代替 short 来“节省内存”？
省下的那 1 字节，在现代 CPU 缓存行（64 字节）和结构体对齐面前几乎没意义，反而引入隐性成本：
- 编译器对
char 的算术常做整型提升（promote to int），实际运行时可能比 short 更慢
- 调试器显示
char 默认当字符打印（比如值 65 显示成 'A'），排查数值逻辑时反而费眼
- 与 C API 交互时（如
read()、send()），参数要求 void<em></em>，但语义上它们期待的是字节序列，这时用 char 是自然选择；而数学库（如 FFT）明确要 short* 输入，混用会导致静默错误
char 的算术常做整型提升（promote to int），实际运行时可能比 short 更慢 char 默认当字符打印（比如值 65 显示成 'A'），排查数值逻辑时反而费眼 read()、send()），参数要求 void<em></em>，但语义上它们期待的是字节序列，这时用 char 是自然选择；而数学库（如 FFT）明确要 short* 输入，混用会导致静默错误 真正该抠内存的场景：
- 嵌入式系统 RAM 极度紧张（< 64KB）
- 百万级结构体数组，且字段确实全在 0–255 范围内
否则，优先选语义清晰的类型：char 表示字节或字符，short 表示小整数——类型即文档。
这事说到底，不是字节多寡的问题，是别让后人（包括三天后的你自己）在 static_cast<short>(c)</short> 那行代码前发呆三分钟。
