Должен ли Vector3 наследоваться от Vector2?

Я создаю пару классов Vector2(X & Y) и Vector3(X, Y & Z), но я не знаю, делать ли Vector3наследование Vector2, или заново реализовать переменные-члены m_xи m_yснова? Каковы плюсы и минусы каждой стороны (наследование против переопределения).

Изменить: я использую C ++ (VS2010).

Нет, не должно. Единственное , что вы хотите использовать от наследования является xи yкомпонентов. Методы, используемые в Vector2классе, не будут полезны в Vector3классе, они, вероятно, будут принимать разные аргументы и выполнять операции с другим числом переменных-членов.

Есть любопытная вещь, которую вы можете сделать с C ++ (вы не указали язык, и этот ответ в основном потому, что я думаю, что приятно видеть альтернативы, хотя я не очень верю, что это полезно в большинстве случаев.)

Используя шаблоны, вы можете сделать что-то вроде этого:

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;
        }
};

и это можно использовать так:

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

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

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

Как я уже сказал, я не думаю, что это полезно, и это, вероятно, усложнит вашу жизнь, когда вы попытаетесь внедрить точки / нормализации / другие вещи и попытаться быть обобщенными с любым количеством векторов.

Независимо от скорости, первый вопрос, который вы должны задать себе при выполнении любого наследования, это то, собираетесь ли вы использовать их полиморфно. Точнее говоря, есть ли ситуация, когда вы можете видеть себя, использующего, Vector3как если бы это было Vector2(что, наследуя от него, вы явно говорите, что Vector3 "is-a" Vector2).

Если нет, то вы не должны использовать наследование. Вы не должны использовать наследование для совместного использования кода. Для этого и нужны компоненты и внешние функции, а не то, что вы все равно будете делиться между ними кодом.

При этом вам могут потребоваться простые способы преобразования Vector3 s в Vector2s, и в этом случае вы можете написать перегрузку оператора, которая будет неявно обрезать Vector3a Vector2. Но вы не должны наследовать.

Нет, так как каждый метод также должен быть переопределен, вы не будете использовать его наследование.

Если что-то, они оба могут реализовать интерфейс Vector. Однако, поскольку вы, вероятно, не хотите добавлять / sub / dot / dst между Vector2 и Vector3, это будет иметь нежелательные побочные эффекты. И иметь разные параметры и т. Д. Было бы хлопот.
Так что я действительно не вижу никаких плюсов наследования / интерфейса в этом случае.

Примером является среда Libgdx, где Vector2 и Vector3 не имеют ничего общего друг с другом, кроме как с использованием методов одного типа.

Если вы планируете использовать SIMD- массивы , вероятно, лучше всего. Если вы все еще хотите использовать перегрузку операторов, вы можете рассмотреть возможность использования интерфейса / миксина для доступа к базовому массиву - например, вот отправная точка, которая имеет только (непроверенную) Add.

Обратите внимание, что я не предоставил X/ Y/ Z, каждый VectorXкласс наследовал бы напрямую от этого - по тем же причинам, которые были указаны другими людьми. Тем не менее, я видел множество массивов, используемых как векторы много раз в дикой природе.

#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);
    }
};

Отказ от ответственности: мой C ++ может быть отстой, прошло много времени с тех пор, как я его использовал.

Еще один серьезный довод в пользу того, чтобы Vec3 наследовал от Vec2 или, возможно, оба они наследовали от одного класса Vector: ваш код будет делать многоопераций над векторами, часто в критических по времени ситуациях, и в ваших интересах быть уверенными, что все эти операции выполняются настолько быстро, насколько это возможно - намного больше, чем для многих других объектов, которые не довольно универсальный или низкоуровневый. Хотя хороший компилятор сделает все возможное, чтобы сгладить любые издержки наследования, вы все равно больше полагаетесь на компилятор, чем хотели бы; вместо этого я бы построил их как структуры с минимальными накладными расходами и, возможно, даже попытался бы сделать большинство функций, которые их используют (за исключением таких вещей, как operator +, с которыми ничего не поделаешь), глобальными, а не методами STRUCT. Ранняя оптимизация, как правило, рекомендуется против