C++中short传参时值不对，因整型提升为int；指针或引用传临时量会触发未定义行为；推荐值传递而非const&；跨平台需注意ABI对齐和printf格式符%hd；精确16位场景应使用int16_t。
传 short 参数时，为什么函数里拿到的值不对？
因为 C++ 默认对小整型参数做整型提升（integer promotion），short 传入函数时会自动转成 int——哪怕你声明的是 void f(short x)，调用时传 short s = -1;，函数体内看到的仍是正确的值，但底层传递过程已不是原始类型。真正出问题的场景是：函数形参是 short* 或引用，而你传了临时量或字面量地址。
- 别写
f(&42)——42是int字面量，取地址后类型是const int*，强制转short*会触发未定义行为 - 如果函数要修改原值，必须确保传入的是真正的
short变量，比如short x = 100; f(&x); - 用
std::ref包装临时short也不行——引用绑定到临时量本身合法，但若函数内部通过指针改写内存，仍可能越界（因临时short实际占 2 字节，但编译器可能按int对齐分配）
short 作函数参数要不要加 const&？
一般不用。传 short 值本身开销极小（通常 2 字节，和寄存器宽度比可忽略），加引用反而引入解引用开销，还限制调用方式（不能传字面量、表达式结果）。只有当函数需要明确禁止拷贝（比如配合 move-only 类型封装）或参数是大结构体模拟的“伪 short”时才考虑。
- 推荐写法：
void process(short value)—— 直接值传，语义清晰，编译器通常优化为寄存器传参 - 避免写法：
void process(const short& value)—— 多余，且process(123)会隐式绑定到临时量，生命周期管理易出错 - 例外：若函数签名需与模板泛化接口对齐（如
template<typename t> void f(const T&)</typename>），那另说，但这是设计约束，不是short本身的需要
跨平台传 short 参数要注意什么？
short 在所有主流平台（x86/x64/ARM）都是 16 位有符号整型，但 ABI 层面对齐规则不同：Windows x64 要求 short 参数在栈上传递时按 4 字节对齐；Linux x86_64 则允许紧凑排列。实际影响不大，除非你手写汇编调用或解析栈帧。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 纯 C++ 代码无需关心——编译器自动生成符合 ABI 的调用序列
- 如果用 C 风格可变参函数（
printf等），必须用正确格式符：%hd对应short，写成%d会导致读取错误字节数（尤其在 64 位系统上） - 结构体里含
short成员时，打包（#pragma pack）会影响 sizeof，但函数参数本身不受影响
什么时候真该用 int16_t 替代 short？
当你需要确定宽度、可移植性或和二进制协议打交道时。short 只保证 ≥16 位，理论上可以是 32 位（虽然现实中没有），而 int16_t 是精确 16 位的别名，来自 <cstdint>。
立即学习“C++免费学习笔记（深入）”；
- 网络通信、文件格式解析、硬件寄存器映射——一律用
int16_t，避免平台差异 - 函数接口暴露给外部库或跨语言绑定（如 Python ctypes）时，用
int16_t更可靠 - 普通业务逻辑中，
short和int16_t效果一致，选哪个取决于团队约定；但混用容易引发隐式转换警告（比如short + int16_t可能触发 signed/unsigned 警告）
short，其实编译器早把它升成了 int；而你以为安全的地址传递，可能正踩在未定义行为的边缘。 
