Best way to type-differentiate a Point and Vector?

Question

I'm writing a ray-tracer in C++, and while writing a constructor for the Ray class:

class Ray {
public:
Ray(const glm::vec3& origin, const glm::vec3& direction) : o{origin}, d{direction} {}

private:
...
}

my IDE helpfully put a zigzag line, saying:

This got me thinking, and I decided I wanted to be a little stricter with my types, so that Point could not possibly be confused with Vector (a fairly common mistake in graphics, as far as I've seen).

The essence is that in 3D space, points are position vectors, and are 4-tuples with the last element always 1 (i.e. (x, y, z, 1)), whereas vectors are 4-tuples with the last element always zero (i.e. (x, y, z, 0)). There are some other constraints on binary operators; for instance:

Point + Point = undefined
Point - Point = Vector 
Point ± Vector = Point
Vector ± Vector = Vector
dot(Vector, Vector) = float
cross(Vector, Vector) = Vector (not defined for Point)

I therefore thought of this, as a first attempt:

struct Point {
    glm::vec4 p{0, 0, 0, 1};
};

struct Vector {
    glm::vec4 v{0, 0, 0, 0};
};

and the constructor, rewritten:

Ray(const Point& origin, const Vector& direction) : o{origin.p}, d{direction.v} {}

However, this is clearly insufficient, as we now would either have to access the members to use glm's operator overloads. Plus, it is missing rewrites for all the operator overloads to satisfy the type constraints above.

Furthermore, this does not prevent consumers of the Point/Vector structs from violating the constraint on the w-coordinate (although trivially solved by making them classes and the corresponding members private).

Is there a neater way of doing this (maybe with some C++20 concepts), and more importantly, is this worthwhile at all?

Answer 1

You've encountered the general problem with trying to do type-based sanity checking for generic constructs like "vectors": it requires a lot of work, basically rewriting the entirety of GLM, just to provide sane concepts for each interaction.

This can work in specific domains where the type of a value is key in how you use it. For example, the C++ timing chrono library does this with its duration and time_point types. durations are given a timescale, and time_points are given both a timescale and a clock that their tick-count is relative to.

But this works because the scale of a duration is simultaneously extremely important and entirely ephemeral. You can easily convert a duration of one scale into a duration of a different scale, with a possible loss of precision. So if an API asks for a time in milliseconds, and you have a time in seconds, you can still easily call the function and the function will still get the time it expects.

The distinction between a position and a direction isn't so ephemeral. It's an inherent property of the meaning of the data, and by its nature, it's not something that's easily convertible between. It's more like the distinction between time_point and duration. To convert a time point into a duration necessarily loses the epoch the point is relative to. To convert a duration to a time point necessarily adds information: an epoch that the duration is said to be relative to.

When you run into these sorts of things, it's a good idea to go back to the original problem. In this case, the problem can best be expressed as this: there is no way for the caller of this function to state that they are aware of the meaning behind the values it passes.

So you can create a fix specific to that problem. Rather than forcing the user of the library to say what the meaning of the value is at all times, make them say it when they call the function. Force the caller to have to say, "here is a vec3, and I know it's a position," but they only have to say it at the time they call the function.

This can be done by creating a wrapper type which is given a key-type and an arbitrary value. The catch is that the user needs to provide a value of the key-type at the time of the function call.

template<typename Key, typename Value>
struct KeyedValue
{
  Value val;

  KeyedValue(Key, Value const& v) : val(v) {}

  KeyedValue(int, Value const& v) = delete; //See below

  operator Value &() {return val;}
  operator Value const&() const {return val;}
};

struct position_key_t{};
struct direction_key_t{};

inline static position_key_t position_key = {};
inline static direction_key_t direction_key = {};

You can now declare your Ray class as follows:

using pos_vec3 = KeyedValue<position_key_t, glm::vec3>;
using dir_vec3 = KeyedValue<position_key_t, glm::vec3>;
class Ray
{
public:
   Ray(pos_vec3 origin, dir_vec3 direction) : o{origin}, d{direction} {}

private:
...
}

To call it, they must explicitly state if it is a position or a direction:

Ray r1({position_key, origin}, {direction_key, dir});
Ray r2({direction_key, origin}, {position_key, dir}); //Compile error

The "See below" constructor exists to stop users from being able to do this:

Ray r1({{}, origin}, {{}, dir});

The {} best fits the int constructor, but that's deleted. So you get a compile error.