Templated vectors

In episode 71, Casey mentions that templatizing vectors would be another approach (not one that he would necessarily use) to implement them to avoid copy-pasting and duplicated code. I'm not a big template fan either, but I do use them on occasion when it makes sense, so I decided to templatize the vectors to see how it would come out. In case others are interested in this approach, here is what I came up with:

template <int T>
union vec
{
    real32 e[T];
    
    real32& operator[](int index) { return e[index]; }
    const real32& operator[](int index) const { return e[index]; }
};

template<>
union vec<2>
{
    struct { real32 x, y; };
    real32 e[2];
};

template<>
union vec<3>
{
    struct { real32 x, y, z; };
    struct { real32 r, g, b; };
    struct { vec<2> xy; real32 pad_; };
    real32 e[3];
};

template<>
union vec<4>
{
    struct { real32 x, y, z, w; };
    struct { real32 r, g, b, a; };
    struct { vec<3> xyz; real32 pad_; };
    real32 e[4];
};

typedef vec<2> vec2_t;
typedef vec<3> vec3_t;
typedef vec<4> vec4_t;

#if 0
//!!! DANGER !!!
template <int T> vec<T>
Vec(real32 e, ...)
{
    vec<T> result;
    va_list args;
    va_start(args, e);
    
    result.e[0] = e;
    for (int i = 1; i < T; ++i) {
        result.e[i] = (real32)va_arg(args, real64);
    }
    
    va_end(args);
    
    return result;
}
#endif

template <int T, class... Args> vec<T>
Vec(Args... args)
{
    const int length = sizeof...(args);
    static_assert(length == T, "");
    vec<T> result = {static_cast<real32>(args)...};
    return result;
}

template <int T> vec<T>
operator*(real32 scalar, vec<T> v)
{
    vec<T> result;
    for (int i = 0; i < T; ++i) {
        result.e[i]  = scalar * v.e[i];
    }
    
    return result;
}

template <int T> vec<T>
operator*(vec<T> v, real32 scalar)
{
    vec<T> result = scalar * v;
    return result;
}

template <int T> vec<T>&
operator*=(vec<T>& v, real32 scalar)
{
    v = scalar * v;
    return v;
}

template <int T> vec<T>
operator-(vec<T> v)
{
    vec<T> result;
    for (int i = 0; i < T; ++i) {
        result.e[i] = -v.e[i];
    }
    
    return result;
}

template <int T> vec<T>
operator+(vec<T> A, vec<T> B)
{
    vec<T> result;
    for (int i = 0; i < T; ++i) {
        result.e[i] = A.e[i] + B.e[i];
    }
    
    return result;
}

template <int T> vec<T>&
operator+=(vec<T>& A, vec<T> B)
{
    A = A + B;
    return A;
}

template <int T> vec<T>
operator-(vec<T> A, vec<T> B)
{
    vec<T> result;
    for (int i = 0; i < T; ++i) {
        result.e[i] = A.e[i] - B.e[i];
    }
    
    return result;
}

template <int T> vec<T>&
operator-=(vec<T>& A, vec<T> B)
{
    A = A - B;
    return A;
}

template <int T> vec<T>
Hadamard(vec<T> A, vec<T> B)
{
    vec<T> result;
    for (int i = 0; i < T; ++i) {
        result.e[i] = A.e[i] * B.e[i];
    }
    
    return result;
}

template <int T> real32
Dot(vec<T> A, vec<T> B)
{
    real32 result = 0.f;
    for (int i = 0; i < T; ++i) {
        result += (A.e[i] * B.e[i]);
    }
    
    return result;
}

template <int T> real32
LengthSq(vec<T> v)
{
    real32 result = Dot(v, v);
    return result;
}

template <int T> real32
Length(vec<T> v)
{
    real32 result = Sqrt(LengthSq(v));
    return result;
}

One notable thing is that by using template specialization, you can in fact use member accesses like .x, .y, .r, .g, etc. That would have been a deal-breaker for me, because writing

1	velocity.x;

is obviously so much more preferable than

1	velocity.e[0];

1	velocity[0];

I also included the va_args version of the creator function as an alternative (particularly since some compilers may not yet support variadic templates), but it's marked danger for good reason. It doesn't offer any type-safety for the arguments after the first one, so writing

1	vec<3> aVec = Vec<3>(1.5f, 2.5f, 6);

will lead to trouble (i.e. when I tested it, the 6 turned into a 0 so I had {1.5, 2.5, 0}!).

While I haven't tested this, the for loops should be unrolled by any decent compiler since the bounds are known at compile time. All in all, it was pretty straightforward, but in the end I'm not sure this buys us a whole lot. Even though you would just have to add a function once in this version, it is less readable.

In any case, I'm going to keep in my version of HmH because, well.. I took the time to write it. :P

EDIT: I've only tested this using Clang.