Is the use of union in this matrix class completely safe?

Question

Unions aren't something I've used that often and after looking at a few other questions on them here it seems like there is almost always some kind of caveat where they might not work. Eg. structs possibly having unexpected padding or endian differences.

Came across this in a math library I'm using though and I wondered if it is a totally safe usage. I assume that multidimensional arrays don't have any extra padding and since the type is the same for both definitions they are guaranteed to take up exactly the same amount of memory?

template<typename T> class Matrix44T
{
    ...

    union
    {
        T M[16];
        T m[4][4];
    } m;
};

Are there any downsides to this setup? Would the order of definition make any difference to how this works?

Answer 1

No. This seems just fine usage of union under your assumptions.

I would have chosen better names and not m and M but other than that it is a nice usage for union.

Answer 2

If you play by the rules, padding and endian differences won't hurt you.

Look at this code

union { int a; float b; } wrong;

wrong.a = 1;
printf("%f", wrong.b);

This is wrong because if you have written member "a", then any reading except from "a" is undefined.

To sum this up: Whether a union is safe cannot be told. It's not the definition, that is unsafe, it's how it is being used.

Answer 3

Although I do exactly the same in my Matrix-class I think this is implementation dependent, reading the standard to the letter:

Standard 9.5.1:

In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. [Note: one special guarantee is made in order to simplify the use of unions: If a POD-union contains several POD-structs that share a common initial sequence (9.2), and if an object of this POD-union type contains one of the POD-structs, it is permitted to inspect the common initial sequence of any of POD-struct members; see 9.2. ]

The question then is do m and M share a common initial sequence, to answer this we look at 9.2/15:

Two POD-union (clause 9) types are layout-compatible if they have the same number of nonstatic data members, and corresponding nonstatic data members (in any order) have layout-compatible types (3.9).

After reading this the answer seems to be, no m and M are not layout-compatible in the strict sense of the word.

In practice I think this will work fine on all compilers though.