NaN-boxing 是动态语言在64位浮点数中利用quiet NaN的52位payload编码类型标签的技巧；C++因缺乏标准支持、易触发UB、优化风险及跨平台问题而不适用，推荐用std::variant替代。
NaN-boxing 是什么，为什么 C++ 里不用它做动态类型
NaN-boxing 不是 C++ 标准特性，也不是语言原生支持的机制；它是某些动态语言（如 JavaScript 引擎 V8、LuaJIT）在 64 位浮点寄存器/内存布局上“借道”实现紧凑动态类型的技巧。C++ 编译器不保证 double 的二进制表示可被随意篡改，也不提供对 NaN payload 的标准化访问接口。强行模仿容易触发未定义行为（UB），比如 std::isnan 返回 false、优化器重排指令、或跨平台失效。
你真想在 C++ 里模拟 NaN-boxing，得绕过哪些坑
核心限制来自 IEEE 754 和 ABI：x86-64 下 double 的 quiet NaN 有 52 位 payload，但 C++ 标准没规定如何写入/读取它；std::bit_cast 或联合体（union）可能因严格别名规则（strict aliasing）被优化掉；MSVC/GCC/Clang 对 __builtin_nan 行为不一致。
- 必须用
uint64_t操作 raw bits，再通过std::bit_cast<double>（C++20）或memcpy转换，禁用 union 直接赋值 - 只用 quiet NaN（最高 bit of payload = 1），避免 signaling NaN 触发陷阱
- 检查目标平台是否支持
std::numeric_limits<double>::is_iec559，否则整个方案无效 - 所有读写操作加
volatile或编译器屏障（如__asm volatile("" ::: "r0")）防优化——但这会拖慢性能
更现实的替代方案：用 std::variant + 小对象优化
现代 C++ 里，std::variant<int, double, bool, std::string_view> 在多数场景下比手工 NaN-boxing 更安全、更快、更易调试。它的栈内存储（small buffer optimization）在 sizeof(variant) ≤ 16 字节时几乎零堆分配；而手写 NaN-boxing 的类型判别逻辑（如 (bits & 0x7ff8000000000000ULL) == 0x7ff8000000000000ULL）极易写错，且无法静态检查类型安全。
示例判别伪代码（实际应封装）：
立即学习“C++免费学习笔记（深入）”；
uint64_t bits = std::bit_cast<uint64_t>(value);
if ((bits & 0x7ff8000000000000ULL) == 0x7ff8000000000000ULL) {
// 可能是 tagged value，但需额外约定低 3 位为 tag
int tag = bits & 7;
switch (tag) { /* ... */ }
}如果你非要硬上 NaN-boxing，至少守住这三条线
第一，只在明确控制 ABI 的嵌入式运行时或 JIT 编译器中用（比如自己写的轻量脚本引擎）；第二，所有 NaN-boxed 值必须用 constexpr 构造，避免运行时构造引发浮点异常；第三，放弃 std::isfinite/std::isnan 等标准函数做类型判断，全部走 raw bits 分析——因为一旦用了 std::nan("")，payload 就不可控。
最常被忽略的一点：NaN-boxing 的“类型 tag”必须和平台浮点寄存器的舍入模式、FPU 控制字解耦。哪怕只在一个函数里调用 fesetround(FE_UPWARD)，都可能导致后续 NaN 比较行为突变。
