C++17中XOR链表是否合规？是否存在UB及launder能否修复？

问题背景 #

XOR链表的典型实现逻辑为：将指针转换为足够存储其值的整数类型，对整数执行XOR运算后再转换回指针；严格遵循XOR运算的性质，确保仅将从指针转换而来的整数转回指针，不依赖指针-整数映射的额外假设。需要明确这种实现在C++17前后是否允许访问仍存在的对象，是否会触发未定义行为，以及能否通过std::launder解决潜在问题。

C++17之前的合法性 #

在C++17之前，只要转换得到的指针满足两个条件：

• 指向的地址是仍存在的对象的地址
• 指针类型与对象类型匹配
  那么这个指针就是有效的，使用它访问对象不会触发未定义行为。标准仅要求指针到整数的映射为单射，只要严格按照“指针→整数→XOR→指针”的逻辑实现，这种XOR链表的写法是被允许的。

C++17之后的合法性 #

C++17引入了指针值的对象身份语义，指针的有效性不再仅由地址和类型决定，还取决于指针的起源链：只有通过合法方式（如直接取对象地址、标准允许的指针运算、合法的类型转换）得到的指针，才能合法关联到对应的对象。

对于XOR链表的实现，通过“指针转整数→XOR运算→转回指针”得到的指针，即使地址和类型完全正确，也属于无合法起源链的指针。使用这类指针访问对象会触发未定义行为——编译器可能无法识别该指针与目标对象的关联，进而进行错误的优化（比如认为指针指向的对象未被修改）。

能否通过std::launder解决？ #

不能。std::launder的核心作用是处理对象生命周期重叠场景（比如在同一地址上通过placement new创建新对象后），让编译器认可当前指针指向的是地址上的新对象，但它的前提是：指针本身的地址是正确的，且该地址上确实存在对应类型的对象。

而XOR链表生成的指针的核心问题是缺乏与目标对象的合法关联链，std::launder无法凭空构建这种关联，因此无法解决其未定义行为的问题。

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