使用std::bit_cast替代std::variant或union共享内存的技术疑问

可以通过std::bit_cast让int或float共享同一内存地址，哪怕是大于2^24的int（这类整数因浮点数尾数位数限制无法完整存储为浮点值）也能实现，示例代码如下：

float storage = 0.0f;

// 将超大整数的底层位存储到float中
storage = std::bit_cast<float>(2'147'483'647);

// 还原出整数
int int_val = std::bit_cast<int>(storage);

// 随时可以用任意float值覆盖该变量，实现类似无标签联合的内存共享效果

技术疑问解答 #

1. 该实现是否依赖未定义行为？
   不会。std::bit_cast是C++20标准明确引入的特性，只要满足两个前提：一是转换的两种类型大小完全相同，二是两者都是可平凡复制（TriviallyCopyable）类型，操作就是完全合法的，不存在未定义行为。主流平台上int和float都是4字节，且均属于可平凡复制类型，所以这个实现完全合规。

2. 由于浮点格式、字节序或其他差异，该方法是否会在部分系统上失效？
   仅在小众特殊平台可能失效：

• 浮点格式：主流平台都采用IEEE 754单精度浮点数，但如果是老式平台使用非标准浮点格式（比如IBM十六进制浮点），转换后的位模式对应关系会错乱；
• 字节序：平台的字节序是全局统一的（要么全小端、要么全大端），只要int和float大小相同，字节序不会成为问题；
• 类型大小：如果某平台int和float大小不同（比如int为2字节、float为4字节），std::bit_cast会直接编译报错，无法运行。
  在符合现代标准的主流平台（x86、ARM等）上，该方法可以正常工作。

3. 某些位模式是否会被浮点数判定为无效，导致无法完成bit_cast或正确存储？
   不会。std::bit_cast的核心是直接复制内存位模式，不会对目标类型的有效性做任何检查。即使把int的位模式转换为float后得到NaN、无穷大或者非规格化数，这些都是IEEE 754标准定义的合法浮点值，完全可以正常存储。就算存在平台定义的“无效浮点位模式”，std::bit_cast也只会原样复制，不会触发存储失败，只是后续使用该浮点值时可能出现逻辑问题，但存储本身不受影响。

4. 该方法能否扩展至其他4字节或8字节类型的内存地址共享场景？
   可以扩展，但必须满足两个核心条件：

• 待转换的两种类型内存大小完全一致；
• 两者都是可平凡复制（TriviallyCopyable）类型。
  比如4字节的uint32_t与float、8字节的int64_t与double，或是自定义的无自定义构造/析构函数、无虚函数的平凡结构体（只要大小匹配），都可以用这个方法实现内存共享。但非平凡复制类型（如带自定义构造函数的类）无法使用std::bit_cast，会直接编译报错。

5. 与std::variant或union相比，该方法有哪些优缺点？

优点 #

• 极致性能：仅做直接位复制，无额外类型标记存储、检查开销，性能接近内存操作的极限；
• 使用简洁：无需定义额外的联合类型或变体结构，直接通过变量覆盖实现内存共享，写法灵活。

缺点 #

• 无类型安全：没有任何机制跟踪当前存储的类型，一旦错误读取类型，会得到无意义的值，甚至可能引发逻辑错误；
• 兼容性受限：依赖类型大小匹配、可平凡复制属性，且对平台的位表示格式有要求；
• 可读性差：代码无法直观反映当前存储的类型，后期维护难度高。

对比其他方案 #

• 与std::variant：std::variant提供类型安全保障，会跟踪当前存储类型，错误读取会抛出异常或返回错误，但存在额外的类型标记存储开销，性能略低；
• 与传统union：C17之前读取union的非活跃成员属于未定义行为，C17后虽放宽限制，但仍有使用约束；而std::bit_cast完全合法，无未定义行为，但两者同样都不提供类型安全。

内容的提问来源于stack exchange，提问作者greenlagoon