对包含包装类型和类型本身的联合有任何保证吗？

Question

我可以将T 和包装好的T 放在union 中，然后随意检查它们吗？

union Example {
    T value;
    struct Wrapped { 
       T wrapped;
    } wrapper;
};

// for simplicity T = int

Example ex;
ex.value = 12;
cout << ex.wrapper.wrapped; // ?

C++11 标准仅保证对通用初始序列进行保存检查，但value 不是struct。我猜答案是否，因为wrapped types aren't even guaranteed to be memory compatible to their unwrapped counterpart 和accessing inactive members is only well-defined on common initial sequences。

Answer 1

我相信这是未定义的行为。

[class.mem] 给我们：

两种标准布局结构类型的公共初始序列是按声明顺序排列的最长的非静态数据成员和位域序列，从每个结构中的第一个此类实体开始，使得对应的实体具有布局兼容的类型，或者两个实体都不是位域，或者两者都是具有相同宽度的位域。 [...]

在具有结构类型T1 的活动成员的标准布局联合中，允许读取结构类型T2 的另一个联合成员的非静态数据成员m，前提是m 是T1和T2的共同初始序列；行为就像T1 的相应成员被提名一样。

如果T 不是标准布局结构类型，这显然是未定义的行为。 （请注意，int 不是标准布局结构类型，因为它根本不是类类型）。

但即使对于标准布局结构类型，构成“公共初始序列”的内容也严格基于非静态数据成员。也就是说，T 和 struct { T val; } 没有共同的初始序列 - 根本没有共同的数据成员！

因此，这里：

template <typename T>
union Example {
    T value;
    struct Wrapped { 
       T wrapped;
    } wrapper;
};


Example<int> ex;
ex.value = 12;
cout << ex.wrapper.wrapped; // (*)

您正在访问工会的非活动成员。这是未定义的。

Answer 2

访问不是最后一个写入的成员时，联合行为未定义。所以不，你不能依赖这种行为。

原理上与使用联合从整数中提取特定字节的想法相同；但额外的风险是，您现在依赖于编译器，而不是在您的结构中添加任何填充。详情请见Accessing inactive union member and undefined behavior?。

Answer 3

它应该可以工作，因为Example 和Wrapped 都是标准布局 类，并且C++14 标准有足够的要求来保证在这种情况下value 和wrapper.wrapped 是位于同一地址。 n4296 草案在 9.2 类成员 [class.mem] §20 中说：

如果标准布局类对象有任何非静态数据成员，其地址与地址相同 它的第一个非静态数据成员。

一个注释甚至说：

[ 注意：因此在标准布局结构中可能存在未命名的填充 对象，但不是在其开始时，作为实现适当对齐所必需的。 ——尾注]

这意味着您至少尊重 3.10 左值和右值 [basic.lval] §10 中的严格别名规则

如果一个程序试图通过 Glvalue 访问一个对象的存储值，而不是其中一个 以下类型的行为未定义
— 对象的动态类型，
...
— 在其元素中包含上述类型之一或非静态的聚合或联合类型 数据成员（递归地包括子聚合的元素或非静态数据成员） 或包含联合），

所以这是完美定义的：

cout << *(&ex.wrapper.wrapped) << endl

因为&ex.wrapper.wrapped 必须与&ex.value 相同，并且指向的对象具有正确的类型。 . 但由于标准仅对公共子序列是明确的。所以我的理解是cout << ex.wrapper.wrapped << endl 调用未定义的行为，因为 1.3.24 [defns.undefined] 中有一条关于 未定义的行为 说（强调我的）：

当本国际标准省略任何明确的定义时，可能会出现未定义的行为 行为...

TL/DR：我敢打赌，即使不是所有常见实现，大多数常见实现都会接受它，但由于 1.3.24 [defns.undefined] 中的注释，我永远不会在生产代码中使用它，但会使用 @改为 987654329@。

---

在最新的 C++17 草案 n4659 中，相关概念是inter-convertibility（[basic.compound] §4）。