Casting double array to a struct of doubles

Question

Is it OK to cast a double array to a struct made of doubles?

struct A
{
   double x;
   double y;
   double z;
};

int main (int argc , char ** argv)
{
   double arr[3] = {1.0,2.0,3.0};
   A* a = static_cast<A*>(static_cast<void*>(arr));
   std::cout << a->x << " " << a->y << " " << a->z << "\n";
}

This prints 1 2 3 . But is it guaranteed to work every time with any compiler?

EDIT: According to

9.2.21: A pointer to a standard-layout struct object, suitably converted ? using a reinterpret_cast, points to its initial member (...) and vice versa.

if I replace my code with

struct A
{
  double & x() { return data[0]; }
  double & y() { return data[1]; }
  double & z() { return data[2]; }
private:
   double data[3];
};

int main (int, char **)
{
   double arr[3] = {1.0,2.0,3.0};
   A* a = reinterpret_cast<A*>(arr);
   std::cout << a->x() << " " << a->y() << " " << a->z() << "\n";
}

then it is guaranteed to work. Correct? I understand that many people would not find this aesteticaly pleasing but there are advantages in working with a struct and not having to copy the input array data. I can define member functions in that struct to compute scalar and vector products, distances etc, that will make my code much easier to understand than if I work with arrays.

How about

int main (int, char **)
{
   double arr[6] = {1.0,2.0,3.0,4.0,5.0,6.0};
   A* a = reinterpret_cast<A*>(arr);
   std::cout << a[0].x() << " " << a[0].y() << " " << a[0].z() << "\n";
   std::cout << a[1].x() << " " << a[1].y() << " " << a[1].z() << "\n";
}

Is this also guaranteed to work or the compiler could put something AFTER the data members so that sizeof(A) > 3*sizeof(double) ? And is there any portable way to prevent the compiler from doing so?

Answer 1

No, it's not guaranteed.

The only thing prohibiting any compiler from inserting padding between x and y , or between y and z is common sense. There is no rule in any language standard that would disallow it.

Even if there is no padding, even if the representation of A is exactly the same as that of double[3] , then it's still not valid. The language doesn't allow you to pretend one type is really another type. You're not even allowed to treat an instance of struct A { int i; }; struct A { int i; }; as if it's a struct B { int i; }; struct B { int i; }; .

Answer 2

The standard gives little guarantees about memory layout of objects.

For classes/structs:

9.2./15: Nonstatic data members of a class with the same access control are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified. Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other ; so might requirements for space for managing virtual functions and virtual base classes.

For arrays, the elements are contiguous. Nothing is said about alignment, so it may or may not use same alignment rules than in struct :

8.3.4: An object of array type contains a contiguously allocated non-empty set of N subobjects of type T.

The only thing you can be sure of in your specific example is that ax corresponds to arr[0] , if using a reinterpret_cast:

9.2.21: A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (...) and vice versa. [
>

Answer 3

No it is not guaranteed, even if it should work with all compilers I know on common architectures, because C language specification says :

6.2.6 Representations of types 6.2.6.1 General1 The representations of all types are unspecified except as stated in this subclause. And it says nothing on the default padding in a struct.

Of course, common architectures use at most 64bits which is the size of a double on those architecture, so there should be no padding and your conversion should work.

But beware : you are explicitely invoking Undefined Behaviour, and next generation of compilers could do anything when compiling such a cast.

Answer 4

From all I know the answer is: yes.

The only thing that could throw you off is a #pragma directive with some very unusual alignment setting for the struct. If for example a double takes 8 bytes on your machine and the #pragma directive tells to align every member on 16-byte boundaries that could cause problems. Other than that you are fine.

Answer 5

std::complex implementation of msvc use the array solution, and llvm libc++ use the former form.

I think, just check the implementation of the std::complex of your libc++, and use the same solution with it.

Answer 6

I disagree with the consensus here. A struct with three doubles in it, is exactly the same as an array with 3 doubles in it. Unless you specifically pack the struct differently and are on a weird processor that has an odd number of bytes for doubles.

It's not built into the language, but I would feel safe in doing it. Style wise I wouldn't do it, because it's just confusing.