我以前很轻松地使用过工会;今天当我读到这篇文章并知道这个代码时,我很震惊

union ARGB
{
    uint32_t colour;

    struct componentsTag
    {
        uint8_t b;
        uint8_t g;
        uint8_t r;
        uint8_t a;
    } components;

} pixel;

pixel.colour = 0xff040201;  // ARGB::colour is the active member from now on

// somewhere down the line, without any edit to pixel

if(pixel.components.a)      // accessing the non-active member ARGB::components

实际上是未定义的行为,即从工会成员中读取除最近写的人以外的内容会导致未定义的行为。如果这不是联合的预期用途,那么什么才是?谁能详细解释一下吗?

更新:

我想事后澄清一些事情。

The answer to the question isn't the same for C and C++; my ignorant younger self tagged it as both C and C++. After scouring through C++11's standard I couldn't conclusively say that it calls out accessing/inspecting a non-active union member is undefined/unspecified/implementation-defined. All I could find was §9.5/1: If a standard-layout union contains several standard-layout structs that share a common initial sequence, and if an object of this standard-layout union type contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of standard-layout struct members. §9.2/19: Two standard-layout structs share a common initial sequence if corresponding members have layout-compatible types and either neither member is a bit-field or both are bit-fields with the same width for a sequence of one or more initial members. While in C, (C99 TC3 - DR 283 onwards) it's legal to do so (thanks to Pascal Cuoq for bringing this up). However, attempting to do it can still lead to undefined behavior, if the value read happens to be invalid (so called "trap representation") for the type it is read through. Otherwise, the value read is implementation defined. C89/90 called this out under unspecified behavior (Annex J) and K&R's book says it's implementation defined. Quote from K&R: This is the purpose of a union - a single variable that can legitimately hold any of one of several types. [...] so long as the usage is consistent: the type retrieved must be the type most recently stored. It is the programmer's responsibility to keep track of which type is currently stored in a union; the results are implementation-dependent if something is stored as one type and extracted as another. Extract from Stroustrup's TC++PL (emphasis mine) Use of unions can be essential for compatness of data [...] sometimes misused for "type conversion".

最重要的是,这个问题(它的标题从我的提问开始就没有改变)是为了理解联合的目的而提出的,而不是关于标准允许什么。例如,使用继承来实现代码重用当然是c++标准允许的,但这并不是将继承引入c++语言特性的目的或初衷。这就是为什么安德烈的回答仍然被人们所接受的原因。


当前回答

@bobobobo代码是正确的,正如@Joshua指出的那样(遗憾的是,我不允许添加注释,所以在这里做,IMO不允许它放在第一位的坏决定):

https://en.cppreference.com/w/cpp/language/data_members#Standard_layout告诉我们这样做是可以的,至少从c++ 14开始

在具有非并集类类型T1的活动成员的标准布局联合中,允许读取另一个非并集类类型T2的联合成员的非静态数据成员m,前提是m是T1和T2的公共初始序列的一部分(除非通过非易失性glvalue读取易失性成员是未定义的)。

因为在当前的情况下T1和T2无论如何都提供了相同的类型。

其他回答

行为可能没有定义,但这只是意味着没有一个“标准”。所有优秀的编译器都提供#pragmas来控制打包和对齐,但可能有不同的默认值。默认值也会根据所使用的优化设置而改变。

此外,工会不仅仅是为了节省空间。它们可以帮助现代编译器使用类型双关语。如果你reinterpret_cast<>所有的东西,编译器就不能假设你正在做什么。它可能不得不放弃它所知道的类型并重新开始(强制写回内存,与CPU时钟速度相比,这是非常低效的)。

其他人提到了架构上的差异(小端到大端)。

我读到的问题是,由于变量的内存是共享的,那么写入一个变量,其他变量就会改变,根据它们的类型,值可能是没有意义的。

如。 联盟{ 浮动f; int我; });

如果你从x.f读取数据,那么写入x.i是没有意义的——除非你想要查看浮点数的符号、指数或尾数分量。

我认为还有一个对齐的问题:如果一些变量必须字对齐,那么你可能得不到预期的结果。

如。 联盟{ 字符c [4]; int我; });

假设,在某些机器上,一个char必须字对齐,那么c[0]和c[1]将与i共享存储空间,而不是c[2]和c[3]。

在1974年记录的C语言中,所有结构成员共享一个公共名称空间,“ptr->成员”的含义被定义为添加 成员的位移到“ptr”,并使用 成员的类型。这种设计使得成员可以使用相同的ptr 名称取自不同的结构定义,但偏移量相同; 程序员将这种能力用于各种目的。

When structure members were assigned their own namespaces, it became impossible to declare two structure members with the same displacement. Adding unions to the language made it possible to achieve the same semantics that had been available in earlier versions of the language (though the inability to have names exported to an enclosing context may have still necessitated using a find/replace to replace foo->member into foo->type1.member). What was important was not so much that the people who added unions have any particular target usage in mind, but rather that they provide a means by which programmers who had relied upon the earlier semantics, for whatever purpose, should still be able to achieve the same semantics even if they had to use a different syntax to do it.

从技术上讲,它是未定义的,但实际上大多数(所有?)编译器都将其视为从一种类型使用reinterpret_cast到另一种类型,其结果是已定义的实现。我不会因为你现在的代码而失眠。

在C语言中,这是实现像变体这样的东西的好方法。

enum possibleTypes{
  eInt,
  eDouble,
  eChar
}


struct Value{

    union Value {
      int iVal_;
      double dval;
      char cVal;
    } value_;
    possibleTypes discriminator_;
} 

switch(val.discriminator_)
{
  case eInt: val.value_.iVal_; break;

在内存较少的情况下,此结构体比具有所有成员的结构体使用更少的内存。

顺便说一下,C提供了

    typedef struct {
      unsigned int mantissa_low:32;      //mantissa
      unsigned int mantissa_high:20;
      unsigned int exponent:11;         //exponent
      unsigned int sign:1;
    } realVal;

访问位值。