Czy Vector3 powinien dziedziczyć po Vector2?

Tworzę kilka klas Vector2(X i Y) i Vector3(X, Y i Z), ale nie wiem, czy Vector3odziedziczyć Vector2, czy ponownie zaimplementować zmienne składowe m_xi m_yponownie? Jakie są zalety i wady każdej ze stron (dziedziczenie vs redefinicja).

Edycja: Używam C ++ (VS2010).

Nie, nie powinno. Jedyną rzeczą, której będziesz używać po spadku, jestxy elementy i . Metody stosowane w Vector2klasie nie byłyby przydatne w Vector3klasie, prawdopodobnie przyjmowałyby różne argumenty i wykonywały operacje na innej liczbie zmiennych składowych.

Jest ciekawa rzecz, którą możesz zrobić w C ++ (nie określiłeś języka, a ta odpowiedź jest głównie dlatego, że myślę, że fajnie jest widzieć alternatywy, chociaż tak naprawdę nie sądzę, aby było to przydatne w większości przypadków).

Za pomocą szablonów możesz zrobić coś takiego:

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

i można tego użyć w następujący sposób:

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

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

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

Jak powiedziałem, nie sądzę, aby było to przydatne i prawdopodobnie skomplikuje twoje życie, gdy spróbujesz wdrożyć kropkę / normalizację / inne rzeczy i spróbujesz być ogólny z dowolną liczbą wektorów.

Niezależnie od prędkości, na pierwsze pytanie należy zadać sobie pytanie, kiedy robi każdy dziedziczenie jest jeśli masz zamiar używać ich polimorficznie. Mówiąc dokładniej, czy jest jakakolwiek sytuacja, w której możesz zobaczyć, jak używasz Vector3tak jakby to byłVector2 (który, dziedzicząc po nim, wyraźnie mówisz, że Vector3 „jest-Vector2”).

Jeśli nie, to nie powinieneś używać dziedziczenia. Nie należy używać dziedziczenia do udostępniania kodu. Do tego służą komponenty i funkcje zewnętrzne, a nie to, że i tak dzielisz między nimi dowolny kod.

To powiedziawszy, możesz chcieć łatwych sposobów konwersji Vector3 s na Vector2s, w takim przypadku możesz napisać przeciążenie operatora, które domyślnie skróci je Vector3do a Vector2. Ale nie powinieneś dziedziczyć.

Nie, ponieważ każda metoda również będzie musiała zostać przesłonięta, więc nie będziesz miał pożytku z dziedziczenia po niej.

Jeśli coś, oboje mogliby wdrożyć interfejs Vector. Ponieważ jednak prawdopodobnie nie chcesz dodawać / sub / dot / dst między Vector2 i Vector3, będzie to miało niepożądane skutki uboczne. A posiadanie różnych parametrów itp. Byłoby kłopotliwe.
Więc naprawdę nie widzę żadnych zalet dziedziczenia / interfejsu w tym przypadku.

Przykładem jest framework Libgdx, w którym Vector2 i Vector3 nie mają ze sobą nic wspólnego, oprócz tego samego typu metod.

Jeśli planujesz użyć karty SIMD tablic prawdopodobnie najlepiej. Jeśli nadal chcesz używać przeciążania operatora, możesz rozważyć użycie interfejsu / mixinu w celu uzyskania dostępu do podstawowej tablicy - na przykład tutaj jest punkt początkowy, który ma tylko (niesprawdzone) Add.

Zauważ, że nie podałem X/ Y/ Z, każda VectorXklasa dziedziczy bezpośrednio po tej - z tych samych powodów, które określiły inne osoby. Mimo to wiele razy widziałem tablice używane jako wektory na wolności.

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

Oświadczenie: Mój C ++ może być do kitu, minęło trochę czasu, odkąd go użyłem.

Kolejna poważna wada związana z dziedziczeniem Vec3 po Vec2 lub, być może, obojem dziedziczeniem z jednej klasy Vector: kod będzie dużo działałoperacji na wektorach, często w sytuacjach krytycznych czasowo, i w twoim najlepszym interesie leży upewnienie się, że wszystkie te operacje są tak szybkie, jak mogą być - o wiele bardziej niż w przypadku wielu innych obiektów, które nie są dość uniwersalny lub niski poziom. Podczas gdy dobry kompilator dołoży wszelkich starań, aby spłaszczyć wszelkie koszty związane z dziedziczeniem, nadal w większym stopniu polegasz na kompilatorze niż chciałbyś; zamiast tego zbudowałbym je jako struktury z możliwie najmniejszym narzutem, a być może nawet spróbuję uczynić większość funkcji, które ich używają (z wyjątkiem rzeczy takich jak operator +, na które tak naprawdę nie można pomóc), są raczej globalne niż metody na struct. Wczesna optymalizacja jest na ogół zalecana przeciwko, iz nie bez przyczyny,