short 到 int 的转换是隐式且安全的，属于整型提升，编译器自动完成，无需显式转换；赋值时仅按原值复制并高位补零或符号扩展，结果一致。
short 到 int 的转换是隐式且安全的
只要 short 值在 int 表示范围内（绝大多数平台都满足），C++ 编译器会自动完成转换，不需要手动干预。这是因为 int 的位宽通常 ≥ short（常见为 16 位 vs 32 位），属于标准规定的“整型提升”（integer promotion）场景。
常见错误现象：short s = 30000; int i = s; 看起来像“要转换”，其实没做任何事——编译器只是把 s 的值按原样复制进 i 的高位补零（或符号扩展，但结果一致）。
- 不要写
(int)s或static_cast<int>(s)</int>—— 没必要，还可能掩盖真正的问题（比如你其实在意溢出） - 如果
short是有符号的（默认），而你把它赋给无符号unsigned int，才需留意符号扩展行为 - 所有主流平台（x86/x64/ARM）上，
sizeof(short) 是 C++ 标准保证的，所以不会截断
什么时候显式转换反而危险
显式转换本身不报错，但容易让人误以为“做了什么保障”，实际上它既不检查范围，也不改变语义。尤其当源值来自外部输入或计算中间结果时，盲目加 static_cast<int></int> 可能掩盖潜在溢出。
使用场景：只有当你明确需要抑制编译器警告（例如函数参数类型不匹配但你知道安全），或在模板元编程中强制类型推导时，才考虑显式转换。
立即学习“C++免费学习笔记（深入）”；
-
short s = 32767; int i = static_cast<int>(s);</int>—— 安全但冗余 -
short s = -32768; unsigned int u = static_cast<unsigned int>(s);</unsigned>—— 危险！结果是大正数（如 4294934528），不是你想的“绝对值” - 如果真担心溢出，该用
std::numeric_limits检查，而不是靠 cast
跨平台兼容性里唯一要注意的点
short 和 int 的实际大小虽由标准约束（short ≤ int），但具体值依赖平台。极少数嵌入式环境可能让两者都是 16 位，此时 int 并不比 short 更“宽”——但转换依然安全，因为值域完全重合。
性能影响：零成本。隐式转换在编译期完成，生成的汇编和直接读取 short 后存入 int 变量是一样的指令（通常就是一条 movsx 或 movzx）。
- 别为“效率”加 cast —— 编译器比你更懂怎么优化
- 如果代码跑在 DSP 或老款单片机上，查一下
sizeof(short)和sizeof(int)，但即便相等，赋值也无需额外处理 - 真正影响兼容性的不是转换本身，而是你假设了
int一定 32 位（比如用%d打印却传short）
容易被忽略的边界：IO 和格式化输出
转换本身没问题，但一到输入输出就容易翻车。C++ 流和 C 风格 printf 对类型敏感，short 传进去不等于自动当 int 处理。
常见错误现象：printf("%d", s); 其中 s 是 short —— 这是未定义行为，因为 %d 期望 int，而 short 被压栈时可能只占 2 字节，导致读错内存。
- 正确做法：
printf("%hd", s);（%hd明确对应short）或先转：printf("%d", (int)s); -
std::cin >> s;没问题，流操作符已重载；但std::cout 输出的是数值，类型无关 - 结构体序列化、网络字节序转换时，别依赖“short 转 int 就安全”，得看字段对齐和大小端
