基于虚方法实现命名union字段的合法性及std::launder使用疑问

虽然std::variant适用于部分场景，但它类似std::tuple，无法为每个变体命名——通常struct比tuple更合适。我尝试通过以下技巧实现命名union字段：让union中所有值共享一个基类，利用基类的虚方法判断union的激活类型，依赖虚析构函数正确销毁激活的union字段。相关代码在测试编译器中可运行，但有以下疑问：

1. 从C++语言规则角度，该方法是否合法？若不合法，如何修正？
2. 若合法，是否所有std::launder调用都是必需的？可移除哪些？
3. 能否进一步简化：移除虚type()函数，通过typeid(*std::launder(this))在UnionBase中获取正确的动态类型信息（仍保留虚析构，确保UnionBase*可获取运行时类型信息）？

合法性分析 #

这种基于带虚函数的基类实现命名union的方案，核心逻辑在C++标准下是合法的，但必须严格遵守对象生命周期管理规则：

• union中带有非平凡构造/析构/拷贝赋值的成员，必须手动管理生命周期：激活某成员时要显式调用构造函数（比如placement new），切换成员前必须显式销毁当前激活的对象。
• 基类带虚函数的设计是合规的：当你在union存储位置上构造派生类对象时，虚表指针会被正确初始化，只要保证同一时间只有一个成员处于激活状态，就不会违反标准规则。

如果你的代码存在以下情况，则属于非法：

• 未销毁当前激活的union成员就直接构造新成员；
• 直接给union成员赋值而不先调用其构造函数（针对无默认构造的类型）；
• 使用已销毁的union成员对象。

这些行为都会导致对象生命周期混乱、虚表指针失效，触发未定义行为。

std::launder的必要性判断 #

std::launder的作用是绕过编译器的对象别名优化，确保访问的是新构造的有效对象。判断是否需要保留的规则如下：

必须保留std::launder的场景 #

1. 在union存储位置上用placement new构造新对象后，直接通过union成员的指针/引用访问该对象时：编译器可能认为该存储位置仍属于旧对象，std::launder会告知编译器这里存在一个新的、生命周期已开始的对象。
2. 当你通过union的原始存储指针（比如void*转换而来的指针）访问新构造的对象时，必须用std::launder。

可以移除std::launder的场景 #

1. 通过基类指针调用已激活对象的虚方法（比如虚析构）：虚函数调用依赖运行时虚表，编译器不会对这类操作做错误的别名优化，无需std::launder。
2. 直接使用从新构造的派生类对象转换而来的基类指针：此时指针指向的是已完成构造的有效对象，无需额外launder。

简化方案：用typeid替代自定义虚type()函数 #

完全可以这么做，但有几个关键注意事项：

• 必须保留虚析构函数：typeid用于多态类型时，要求指针指向的对象是带有虚函数的完整类型，虚析构足以让基类成为多态类型，保证typeid能获取正确的运行时类型。
• 调用typeid(*std::launder(this))时，必须确保this指向的是已激活且完整的派生类对象：如果this指向未构造或已销毁的对象，typeid调用会触发未定义行为。
• 不要依赖std::type_info::name()的字符串内容做类型判断：该字符串的格式是实现定义的（不同编译器输出差异很大），应该直接用==比较std::type_info对象，比如typeid(*this) == typeid(DerivedType)。

这种简化方案的性能和自定义虚type()函数几乎无差异——两者都是通过虚表查找运行时类型信息，只是typeid是标准库提供的实现，无需手动维护每个派生类的类型判断逻辑。

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