长话短说-无论您在做什么，通过union投射数据都是不确定的行为。因此，它可以正常工作，而并非偶然。只有您被允许对union进行的操作才能读取您上次写给该成员的成员。您执行其他任何操作，程序无效。

编辑：

即使允许这样做，如果没有#pragma pack，您也将依赖于结构中的数据对齐。大概是32位或64位。因此，在这种情况下，您的结构实际上在内存中看起来像这样：

struct {
    unsigned int a      : 12;
    unsigned int a_align: 20;
    unsigned int b      : 12;
    unsigned int b_align: 20;
    unsigned int c      : 12;
    unsigned int c_align: 20;
    unsigned int d      : 12;
    unsigned int d_align: 20;
    unsigned int unused : 16;
    unsigned int unused_align: 16;

};

如果要从结构中提取一些数据，则可能应使用如下的掩码和位移位：

unsigned mask12 = 0xFFF;//1 on first 12 least significant bits
unsigned a = data & mask12;
unsigned b = (data >> 12) & mask12;
unsigned c = (data >> 24) & mask12;
unsigned d = (data >> 36) & mask12;

  

为什么我会看到这个问题？

正确地，访问联盟的不活动成员具有未定义的行为。但是让我们假设您的系统允许它。

unsigned可能是32位。 a和b放入第一个unsigned中，总共占用24位。 unsigned仅剩8位。 12位c不适合该8位插槽。因此，它改为启动一个新的unsigned并保留8位填充。

这是一种可能的结果。位域布局由实现定义。在另一个系统上，您可能会看到预期的结果。或者输出的结果与您的预期不同，与您在此处观察到的有所不同。

  

#pragma pack语句可以解决此问题吗？

它可能会更改布局规则，以允许跨多个基础对象“跨越”位域。这可能会使其访问速度稍微慢一些。

  

有人能推断出什么时候会成为问题吗？

如果您不尝试跨越基础对象，那么布局是否支持该对象就没有区别。在这种情况下，您可以简单地使用64位基础对象。

这不是位域布局可能与您期望的唯一不同的唯一方式。例如，位域可能是最重要的第一位或最后一位。 unsigned本身的位数是实现定义的。

通常，不应该依赖位集的布局。

  

那我想要达到的最佳效果怎么办？

要避免UB，您可以创建另一个对象，然后从一个字节复制另一个字节，而不是通过联合修剪。但是首先，必须确保对象具有相同的大小。可以使用std::memcpy或std::bit_cast完成复制。

为避免跨界问题，请使用完全填充每个基础对象的位域集。在这种情况下，使用64位基础对象。

要获得可靠的布局，请不要首先使用位域。 bartop展示了如何使用移位和遮罩来做到这一点。 （尽管布局仍然依赖于字节序）