Accessing array elements by name

Question

I'm writing code that passes around a lot of multi-parameter variables. For example, I might pass an "orientation," which is six doubles (three Cartesian coordinates and three rotations about the axes). It would be reasonable to define an Orientation struct and use that as an argument type. However, due to API limitations, these parameters must be stored as, and often passed to functions as, pointers to arrays of parameters:

// The sane version, using a struct
double distance_from_origin(const Orientation & o) {
  return sqrt(o.x * o.x + o.y * o.y + o.z * o.z);
}

// The version I must write due to API constraints
double distance_from_origin(const double * const p) {
  return sqrt(p[0] * p[0] + p[1] * p[1] + p[2] * p[2]);
}

Obviously, this is error-prone. I have three potential solutions, with one favorite.

Solution 1

I can use #define or const globals, in a header somewhere, to alias names to indexes.

const size_t x = 0;
const size_t y = 1;
const size_t z = 2;

double distance_from_origin(const double * const p) {
  return sqrt(p[x] * p[x] + p[y] * p[y] + p[z] * p[z]);
}

This makes sure x is always consistent, but pollutes the global namespace. I could hide it in a namespace, but then it's more awkward to use.

Solution 2

An idea previously mentioned here:

struct Orientation {double x, y, z, rot_x, rot_y, rot_z};

Orientation& asOrientation(double * p) {
  return *reinterpret_cast<Orientation*>(p);
}

double distance_from_origin(const double * const p) {
  Orientation& o = asOrientation(p)  
  return sqrt(o.x * o.x + o.y * o.y + o.z * o.z);
}

This has nicer syntax, but relies on the rules of C/C++ struct packing. I think that it's safe as long as Orientation is a POD. I'm nervous about relying on that.

Solution 3

struct Orientation {
  Orientation(double * p): x{p[0]}, y{p[1]}, z{p[2]}, rot_x{p[3]}, 
    rot_y{p[4]}, rot_z{p[5]} {}

  double &x, &y, &z, &rot_x, &rot_y, &rot_z
};

double distance_from_origin(const double * const p) {
  Orientation o{p};
  return sqrt(o.x * o.x + o.y * o.y + o.z * o.z);
}

This no longer relies on struct-packing rules, and has nice syntax. However, it relies on compiler optimizations to ensure that it has zero overhead.

Solution 4

Based on this comment by GManNickG.

constexpr double& x(double * p) {return p[0];}
constexpr double& y(double * p) {return p[1];}
constexpr double& z(double * p) {return p[2];}
// ... etc.

double distance_from_origin(const double * const p) {
  return sqrt(x(p) * x(p) + y(p) * y(p) + z(p) * z(p));
}

Questions

1. Solution 3 seems like the best to me. Does it have a potential downside that I'm missing, beyond reliance on compiler optimization?

2. Is there another solution that's superior to any of these three?

Answer 1

Firstly, I wouldn't discount just copying the parameters from the array into a simple struct. Copying 6 doubles into a struct will be very quick.

Otherwise, I suggest wrapping the array in a class and expose the parameters as member functions:

class Orientation {
    const double *p_;
public:
    Orientation(const double *p) : p_(p) {}
    double x() const { return p_[0]; }
    double y() const { return p_[1]; }
    double z() const { return p_[2]; }
    double rot_x() const { return p_[3]; }
    double rot_y() const { return p_[4]; }
    double rot_z() const { return p_[5]; }
};

With your Solution 3 I doubt a compiler can optimize the size of your Orientation struct, it will have the size to contain 6 references. With Solution 3 it will not be assignable due to the references.

Answer 2

Don't try to reinterpet an array of doubles as a struct. Of course it will work, but it's not safe, and its confusing. The function signature is perfectly well-defined, it takes an array of six doubles, of which the first three are x, y, and z and the second three are Euler angles. So that's your interface.

/*
   get distance of an orientation from an origin

  Params: p[0] = x, p[1] = y, p[2] = z, p[4].p[4],p[6] Euler angles (unused)
  Returns: Euclidean distance of x,y,z from origin. 
*/
double distance_for_origin(const double *p);

No problem here, it's a bit hard to call but that's what you have to live with.

Now how to implement it? You've got several choices, depending on how many of these "orientation" structures you have in the code. If you've only one or two

double distance_from_origin(const double *p)
{
   double x = p[0];
   double y = p[1];
   double z = p[2];

   return sqrt(x*x + y*y + z*z);
}

This is fine, even the worst optimiser in the world will optimise out the assignments if for some reason it runs out of registers.

The question is however, when and where will this interface be likely to break? Let's say we go to describing orientations with quaternions. Now of course you'll have seven doubles, x,y,z, and normal vector, and an angle round that normal vector. Quite likely that someone will want to do that.

But in that case, who would take that decision, and what is the process for updating the code? If you are using an API provided by Megacorp, then only Megacorp can take the decision to go to quaternions, and probably only in formal release of a new version of the API. If you wrote the code yourself, presumably you yourself decided on Euler angles rather the quaternions and you might even change the representation in response to this reply.

That's the real issue. Because you've stripped out type information, the compiler can't help you, so you need to plan for it breaking.