Should Vector3 inherit from Vector2?

Question

I'm creating a couple of classes Vector2 (X & Y) and Vector3 (X, Y & Z), but I don't know whether to make Vector3 inherit from Vector2, or whether to re-implement the member variables m_x and m_y again? What are the pros and cons of each side (inheritance vs redefinition).

Edit: I'm using C++ (VS2010).

Answer 1

No it shouldn't. The only thing you'd be using from the inheritance is the x and y components. The methods used in a Vector2 class wouldn't be useful in a Vector3 class, they would likely take different arguments and perform operations on a different number of member variables.

Answer 2

There's a curious thing you can do with C++ (You didn't specify a language, and this answer is mostly because I think it's nice to see alternatives, though I don't really believe this is useful in most cases.)

Using templates you can do something like this:

template <class T, class S, int U>
class VectorN
{
    protected:
        int _vec[U];
    public:
        S& operator+=(const S c)
        {
            for(int i = 0; i < U; i++)
            {
                _vec[i] += c.at(i);
            }
            return (S&)*this;
        }
        int at(int n) const
        {
            return _vec[n];
        }
};

template <class T>
class Vec2 : public VectorN<T,Vec2<T>,2>
{
    public:
        T& x;
        T& y;
        Vec2(T a, T b) : x(this->_vec[0]), y(this->_vec[1])
        {
            this->_vec[0] = a;
            this->_vec[1] = b;
        }
};

template <class T>
class Vec3 : public VectorN<T,Vec3<T>,3>
{
    public:
        T& x;
        T& y;
        T& z;
        Vec3(T a, T b, T c) : x(this->_vec[0]), y(this->_vec[1]), z(this->_vec[2])
        {
            this->_vec[0] = a;
            this->_vec[1] = b;
            this->_vec[2] = c;
        }
};

and this can be used like this:

int main(int argc, char* argv[])
{

    Vec2<int> v1(5,0);
    Vec2<int> v2(10,1);

    std::cout<<((v1+=v2)+=v2).x;
    return 0;
}

Like I said, I don't think this is useful, and it will probably complicate your life when you try to implement dot/normalize/other stuff and try to be generic with any number of vectors.

Answer 3

Regardless of speed, the first question you should ask yourself when doing any inheritance is if you're going to be using them polymorphically. More specifically, is there any situation where you can see yourself using a Vector3 as if it were a Vector2 (which, by inheriting from it, you're explicitly saying that a Vector3 "is-a" Vector2).

If not, then you shouldn't use inheritance. You shouldn't be using inheritance to share code. That's what components and external functions are for, not that you'd be sharing any code between them anyway.

That being said, you might want easy ways to convert Vector3s to Vector2s, and in that case you can write an operator overload that will implicitly truncate the Vector3 to a Vector2. But you shouldn't inherit.

Answer 4

No, since every method will need to be overridden as well you will have no use of actually inheriting from it.

If something, they could both implement a Vector interface. However, since you probably don't want to add/sub/dot/dst between a Vector2 and Vector3 this will have unwanted side effects. And having different parameters etc. would be a hassle.
So I really cannot see any pros of inheritance/interface in this case.

An example is the Libgdx framework, where Vector2 and Vector3 have nothing to do with each other, other than having same type of methods.

Answer 5

If you plan to use SIMD arrays are likely the best. If you still wish to use operator overloading you can consider using an interface/mixin to access the underlying array - for example, here is a starting point that has only the (untested) Add.

Notice how I haven't provided X/Y/Z, each VectorX class would inherit directly from this one - for the same reasons specified by other people. Still, I have seen arrays used as vectors many times in the wild.

#include <xmmintrin.h>

class Vector
{
public:
    Vector(void)
    {
        Values = AllocArray();
    }

    virtual ~Vector(void) 
    { 
        _aligned_free(Values);
    }

    // Gets a pointer to the array that contains the vector.
    float* GetVector()
    {
        return Values;
    }

    // Gets the number of dimensions contained by the vector.
    virtual char GetDimensions() = 0;

    // An example of how the Vector2 Add would look.
    Vector2 operator+ (const Vector2& other)
    {
        return Vector2(Add(other.Values));
    }

protected:
    Vector(float* values)
    {
        // Assume it was created correctly.
        Values = values;
    }

    // The array of values in the vector.
    float* Values;

    // Adds another vector to this one (this + other)
    float* Add(float* other)
    {
        float* r = AllocArray();

#if SSE
        __m128 pv1 = _mm_load_ps(Values);
        __m128 pv2 = _mm_load_ps(other);
        __m128 pvr = _mm_load_ps(r);

        pvr = _mm_add_ps(pv1, pv2);
        _mm_store_ps(r, pvr);

#else
        char dims = GetDimensions();
        for(char i = 0; i < dims; i++)
            r[i] = Values[i] + other[i];
#endif

        return r;
    }

private:

    float* AllocArray()
    {
        // SSE float arrays need to be 16-byte aligned.
        return (float*) _aligned_malloc(GetDimensions() * sizeof(float), 16);
    }
};

Disclaimer: My C++ might suck, it's been a while since I used it.

Answer 6

Another serious con to having Vec3 inherit from Vec2 or, arguably, to having both inherit from a single Vector class: your code will be doing a lot of operations on vectors, often in time-critical situations, and it's very much in your best interests to make sure that all of those operations are as fast as they can be - much more so than it is for many other objects that aren't quite so universal or low-level. While a good compiler will do its best to flatten out any inheritance overhead, you're still relying more on the compiler there than you'd like to; instead, I would build them as structs with as little overhead as possible and possibly even try and make most of the functions that use them (with the exception of things like operator+ which can't really be helped) be globals rather than methods on the struct. Early optimization is generally recommended against, and with excellent reason, but in a circumstance like this where you can be sure that vector operations will almost certainly be a substantial chunk of your runtime, it's worth a bit of effort up front to design for efficiency.