联合作为基类

Question

标准定义Union不能用作Base类，但是这有什么具体的理由吗？据我了解，联合可以有构造函数、析构函数、成员变量以及对这些变量进行操作的方法。简而言之，联合可以封装可通过成员函数访问的数据类型和状态。因此，从最常见的角度来看，它有资格成为一个类，如果它可以充当一个类，那么为什么它不能充当基类呢？

编辑：虽然答案试图解释推理，但我仍然不明白 Union 作为派生类如何比 Union 作为一个类时更糟糕。因此，为了获得更具体的答案和推理，我将推动这个问题以获得赏金。无意冒犯已经发布的答案，谢谢！

Answer 1

Bjarne Stroustrup 在《带注释的 C++ 参考手册》中表示“似乎没有什么理由这样做”。

Answer 2

标题询问为什么联合不能作为基类，但问题似乎是关于联合作为派生类。那么，是哪一个呢？

没有任何技术原因说明联合体不能成为基类；这是不允许的。合理的解释是将联合视为一个结构，其成员可能在内存中重叠，并将派生类视为从此（相当奇怪的）结构继承的类。如果您需要该功能，通常可以说服大多数编译器接受匿名联合作为结构的成员。这是一个适合用作基类的示例。 （为了更好的衡量，联合中有一个匿名结构。）

struct V3 {
    union {
        struct {
            float x,y,z;
        };
        float f[3];
    };
};

联合作为派生类的基本原理可能更简单：结果不会是联合。工会必须是所有成员和所有基地的联合体。这很公平，并且可能会带来一些有趣的模板可能性，但是您会遇到许多限制（所有基类和成员都必须是 POD ——并且您是否能够继承两次，因为派生类型本质上是非-POD？），这种类型的继承与该语言所支持的其他类型不同（好吧，这并不是说这之前已经停止了 C++），而且无论如何它都是多余的——现有的联合功能也可以。

Stroustrup 在 D&E 书中这样说：

与 void * 一样，程序员应该知道联合...本质上是危险的，应尽可能避免，并且在实际需要时应特别小心处理。

（省略不会改变含义。）

所以我想这个决定是任意的，他只是认为没有理由改变联合功能（它与 C++ 的 C 子集一起工作得很好），所以没有设计与新 C++ 功能的任何集成。当风向改变时，它就陷入了困境。

Answer 3

我想您在对 EJP 答案的评论中自己已经得到了答案。

我认为 C++ 中包含联合只是为了向后兼容 C。我想在 1970 年，在内存空间很小的系统上，联合似乎是一个好主意。当 C++ 出现时，我想联合已经看起来不太有用了。

考虑到联合体无论如何都非常危险，而且不是很有用，从联合体继承所产生的大量新机会可能看起来不是一个好主意:-)

Answer 4

这是我对 C++ 03 的猜测。

按照 $9.5/1，在 C++ 03 中，联合不能有虚函数。有意义的派生的全部要点是能够重写派生类中的行为。如果联合不能具有虚函数，则意味着从联合派生没有意义。

因此就有了这个规则。

Answer 5

您可以使用 C++11 中的匿名联合功能继承联合的数据布局。

#include <cstddef>

template <size_t N,typename T>
struct VecData {
  union {
    struct {
      float x;
      float y;
      float z;
    };
    float a[N];
  };
};

template <size_t N, typename T>
  class Vec : public VecData<N,T> {
    //methods..
};

一般来说，最好不要直接使用联合，而是将它们包含在结构或类中。然后，您可以将继承建立在结构外层的基础上，并在需要时在内部使用联合。

Answer 6

托尼·帕克给出了一个非常接近事实的答案。 C++ 委员会基本上认为不值得付出努力使联合成为 C++ 的重要组成部分，类似于将数组视为我们必须从 C 继承但实际上并不想要的遗留内容。

联合有问题：如果我们允许联合中使用非 POD 类型，那么它们是如何构造的？这当然可以做到，但不一定安全，任何考虑都需要委员会资源。最终的结果将不太令人满意，因为在理智的语言中真正需要的是受歧视的联合，而裸露的 C 联合永远不可能以与 C 兼容的方式提升为受歧视的联合（无论如何，我可以想象）。

详细说明技术问题：由于您可以将仅包含 POD 组件的联合包装在结构中而不会丢失任何内容，因此允许联合作为基础没有任何优势。对于仅包含 POD 的联合组件，显式构造函数简单地分配组件之一，或者使用 bitblit (memcpy) 来生成编译器生成的复制构造函数（或赋值），都没有问题。

然而，这样的联合并没有足够的用处，除非保留它们，以便现有的 C 代码可以被认为是有效的 C++。这些仅限 POD 的联合在 C++ 中被破坏，因为它们无法保留在 C 中拥有的重要不变量：任何数据类型都可以用作组件类型。

为了使联合有用，我们必须允许可构造类型作为成员。这很重要，因为仅在构造函数主体中分配组件（无论是联合本身还是任何封闭结构）是不可接受的：例如，您不能将字符串分配给未初始化的字符串组件。

接下来，我们必须发明一些规则来使用内存初始化器初始化联合组件，例如：

union X { string a; string b; X(string q) : a(q) {} };

但现在的问题是：规则是什么？通常规则是您必须初始化类的每个成员和基类，如果您不显式地这样做，则默认构造函数用于其余部分，并且如果未显式初始化的一种类型没有默认构造函数，则它是一个错误[异常：复制构造函数，默认为成员复制构造函数]。

显然，这一规则不适用于联合：规则必须改为：如果联合至少有一个非 POD 成员，则必须在构造函数中显式初始化一个成员。在这种情况下，不会生成默认构造函数、复制构造函数、赋值运算符或析构函数，并且如果实际使用这些成员中的任何一个，则必须显式提供它们。

所以现在的问题是：你会如何编写一个复制构造函数？当然，如果您按照 X-Windows 事件联合的设计方式来设计联合，则完全有可能做到并获得正确的结果：在每个组件中使用判别标记，但您必须使用放置运算符 new 来完成此操作，你将不得不打破我上面写的规则，乍一看似乎是正确的！

那么默认构造函数呢？如果您没有其中之一，则无法声明未初始化的变量。

在其他情况下，您可以在外部确定组件并使用placement new 在外部管理联合，但这不是复制构造函数。事实是，如果你有 N 个组件，你就需要 N 个构造函数，而 C++ 有一个错误的想法，即构造函数使用类名，这会让你缺少名称，并迫使你使用幻像类型来允许重载来选择正确的类型构造函数..并且您不能对复制构造函数执行此操作，因为它的签名是固定的。

好吧，那么还有其他选择吗？也许是的，但这些想法并不那么容易实现，而且更难说服 100 多人相信值得在三天的充满其他问题的会议中进行思考。

遗憾的是委员会没有实施上述规则：联合对于对齐任意数据是强制性的，并且组件的外部管理实际上并不难手动完成，并且当代码由合适的算法生成时微不足道且完全安全，换句话说，如果您想使用 C++ 作为编译器目标语言并仍然生成可读、可移植的代码，则该规则是强制。这种具有可构造成员的联合有很多用途，但最重要的一个是表示包含嵌套块的函数的堆栈框架：每个块在结构中都有本地数据，每个结构都是联合组件，不需要任何构造函数或者这样，编译器将只使用新的放置。该联合提供对齐和尺寸以及自由转换的组件访问。
[并且没有其他一致的方法来获得正确的对齐！]

因此，你的问题的答案是：你问了错误的问题。仅 POD 联合作为基类没有任何优势，而且它们当然不能是派生类，因为那样它们就不是 POD。为了使它们有用，需要一些时间来理解为什么应该遵循 C++ 中其他地方使用的原则：丢失的位不是错误，除非您尝试使用它们。

Answer 7

Union 是一种可以用作其任何一个成员的类型，具体取决于已设置的成员 - 以后只能读取该成员。

当您从类型派生时，派生类型将继承基类型 - 派生类型可以在基类型所在的任何位置使用。如果可以从联合派生，则可以在任何可以使用联合成员的地方使用派生类（不是隐式的，而是通过命名成员显式地使用），但在这些成员中只有一个成员可以合法访问。问题是已设置成员的数据未存储在联合中。

为了避免这种微妙但危险的矛盾，实际上破坏了从联合派生的类型系统是不允许的。