Union – useless anachronism or useful old school trick?

Question

I recently came across a great data structures book,"Data Structures Using C" (c) 1991, at a local Library book sale for only $2. As the book's title implies, the book covers data structures using the C programming language.

I got the book knowing it would be out-dated but would probably contain lots of advanced C topics that I wouldn't encounter elsewhere.

Sure enough within 5 minutes I found something I didn't know about C. I came across a section talking about the union keyword and I realized that I had never used it, nor ever seen any code that does. I was grateful for learning something interesting and quickly bought the book.

For those of you not knowledgeable about what a union is, the book uses a good metaphor to explain:

To fully understand the concept of a union, it is necessary to examine its implementation. A Structure may be regarded as a road map to an area of memory. It defines how the memory is to be interpreted. A union provides several different road maps for the same area of memory, and it is the responsibility of the programmer to determine which road map is in current use. In practice, the compiler allocates sufficient storage to contain the largest member of the union. It is the road map, however, that determines how that storage is to be interpreted.

I could easily come up with contrived situations or hacks where I would use a Union. (But I am not interested in contrived situations or hacks...)

Have you used or seen an implementation where using Union solved the problem **more elegantly** than not using a Union?

Added bonus if you include a quick explanation of why using union was better/easier than not using a union.

Answer 1

Indeed, it's a great tool when you write things like device drivers (a struct that you want to send to device that can have several similar but different formats) and you require precise memory arrangement...

Answer 2

UNIONs implement some sort of polymorphism in a non-OOP world. Usually, you have a part which is common and depending on that part, you use the rest of the UNIONs. Therefore, in such cases where you do not have an OOP language and you want to avoid excessive pointer arithmetic, unions can be more elegant in some cases.

Answer 3

Union is the simplest way to implement VARIANT-like data types in C/C++, I suppose.

Answer 4

Consider the case of accessing individual bytes within a large variable:

UInt32 x;
x = 0x12345678;
int byte_3 = x & 0x000000FF;          // 0x78
int byte_2 = (x & 0x0000FF00) >> 8;   // 0x56
int byte_1 = (x & 0x00FF0000) >> 16;  // 0x34
int byte_0 = (x & 0xFF000000) >> 24;  // 0x12

This can be far more elegant with a union:

typedef union
{
    UInt32 value;  // 32 bits
    Byte byte[4];  // 4 * 8 bits
}
UInt32_Bytes;

UInt32_Bytes x;
x.value = 0x12345678;
int byte_3 = x.byte[3];  // 0x78
int byte_2 = x.byte[2];  // 0x56
int byte_1 = x.byte[1];  // 0x34
int byte_0 = x.byte[0];  // 0x12

The use of a union means you no longer have to use bit masks and shift operators in order to access the individual bytes. It also makes the byte access explicit.

Answer 5

You should be aware that in C++ they are not such a great solution, as only POD (plain old data) types can be placed in a union. If your class has a constructor, destructor, contains classes that have constructors and/or destructors (and about a million other gotchas), it cannot be a member of a union.

Answer 6

It's useful for setting bits in, say, registers instead of shift/mask operations:

typedef union {
    unsigned int as_int; // Assume this is 32-bits
    struct {
        unsigned int unused1 : 4;
        unsigned int foo : 4;
        unsigned int bar : 6;
        unsigned int unused2 : 2;
        unsigned int baz : 3;
        unsigned int unused3 : 1;
        unsigned int quux : 12;
    } field;
} some_reg;

Note: Which way the packing happens is machine-dependent.

some_reg reg;
reg.field.foo = 0xA;
reg.field.baz = 0x5;
write_some_register(some_address, reg.as_int);

I might have blown some syntax somewhere in there, my C is rusty :)

EDIT:

Incidentally, this works the opposite way also:

reg.as_int = read_some_register(some_address);
if(reg.field.bar == BAR_ERROR1) { ...

Answer 7

It's often used in the specification of data transmission protocols, where you'd want to avoid wasting space in your data structures. It allows memory space to be saved by using the same space for multiple mutually exclusive options.

For example:

enum PacketType {Connect, Disconnect};
struct ConnectPacket {};
struct DisconnectPacket {};
struct Packet
{
    // ...
    // various common data
    // ...
    enum PacketType type;
    union
    {
        ConnectPacket connect;
        DisconnectPacket disconnect;
    } payload;
};

The ConnectPacket and DisconnectPacket structures occupy the same space, but that's ok because a packet can't be both types at the same time. The enum value is used to determine which part of the union is in use. Using the union has allowed us to avoid duplicating the common parts of the Packet structure.

Answer 8

It's quite a good way to get the IEEE bit values of a float (assuming of course that floats are IEEE on your system). Anything which involves casting float* to int* risks tripping over the strict aliasing rules. This isn't just theoretical - high levels of optimisation actually will break your code.

Technically, union does not deal with the problem. In practice, all known compilers will (a) allow you to write one member of a union and read back another, and (b) perform the read after performing the write. GCC at least is capable of rolling the union into a register, turning the whole thing into a no-op (assuming floats are stored in registers to begin with).

Answer 9

We've used unions in lots of code for network packet parsing.

Union allocates the size of the biggest element. You would create a union with a buffer element of maximum message size, then you can easily access the values in the packet.

Imagine that data "c123456" arrived online and you need to parse and access the values:

  #include <iostream>
  using namespace std;

  struct msg
  {
     char header;
     union
     {
       char a[3];
       char b[2];
       char c[5];
       char d[6];
       char buf[10];
     } data;
  } msg;

  int main()
  {
    struct msg m;
    memcpy(&m, "c123456", sizeof("c123456"));

    cout << "m.header: " << m.header << endl;
    cout << "m.data.d: " << string(m.data.d,sizeof(m.data.d)) << endl;
    cout << "m.data.b: " << string(m.data.b,sizeof(m.data.b)) << endl;

    switch (m.header)
    {
     case 'a': cout << "a: " << string(m.data.a, sizeof(m.data.a)) << endl; break;
     case 'b': cout << "b: " << string(m.data.b, sizeof(m.data.b)) << endl; break;
     case 'c': cout << "c: " << string(m.data.c, sizeof(m.data.c)) << endl; break;
     default: break;
    }
  }

The output would look like this:

m.header: c
m.data.d: 123456
m.data.b: 12
c: 12345

Answer 10

I used it once for a rough kind of data polymorphism in a similar way to markh44's answer. I had several different kinds of data that I wanted potentially to use. I created a union of all of those types and a struct that contained the union and a code defining which type was to be used.

union
{
    data_type_1;
    data_type_2;
    data_type_3;
} data_union;

typedef struct _TAG_DATA_WRAPPED_
{
    data_union data;
    int data_type; //better an enum
} WRAPPED_DATA;

WRAPPED_DATA loads_of_data[1024];

To answer your question about why this is advantageous:

What this allows you to do is easily allocate lists or arrays of different sorts of data and programatically manage their type. The big issue is of course storage space because if the types have very different storage sizes you can waste a lot of space.

Answer 11

I know this has been repeated, but I will just post a code sample to see how unions do add to elegance and efficiency when reading network traffic:

#pragma packed(1)
struct header_t {
   uint16_t msg_id;
   uint16_t size;
};
struct command_t {
   uint8_t cmd;
};
struct position_t {
   uint32_t x;
   uint32_t y;
   uint32_t z;
};
// ... Rest of the messages in an IDS
struct message {
   header_t header;
   union {
      command_t command;
      position_t position;
   } body;
};
#pragma packed(0)
message read( int socket ) {
   message data;
   unsigned int readed = read( socket, &data, sizeof(header_t) );
   // error checks... readed bytes smaller than header size and such
   readed = read( socket, &(data.body), data.header.size ); 
   // error checks...
}

In the snippet above you can perform the message read in place, and you do not need to care about the concrete type of object received. If you did not use the union, you would be left with reading the header, extracting both the size and the type, instantiating an object of the appropriate type (either in a hierarchy or to include inside a variant type as boost::any/boost::variant), and performing the second read on the newly created space.

We use this solution extensively to control simulators (some companies do not appreciate 'new' technologies like DDS or HLA and still depend on raw UDP/TCP data for their simulators). In the network layer we use unions that are transformed into internal data structures (network-to-host conversion, data scaling...) before feeding it into the application layers. As it was mentioned before, you must be careful with the padding at all times.