Vector3 doit-il hériter de Vector2?

Je crée quelques classes Vector2(X & Y) et Vector3(X, Y & Z), mais je ne sais pas si je dois Vector3hériter de Vector2, ou si je dois réimplémenter les variables membres m_xet m_yencore? Quels sont les avantages et les inconvénients de chaque côté (héritage vs redéfinition).

Edit: j'utilise C ++ (VS2010).

Non, ça ne devrait pas. La seule chose que vous utiliseriez de l'héritage est les composants xet y. Les méthodes utilisées dans une Vector2classe ne seraient pas utiles dans une Vector3classe, elles prendraient probablement différents arguments et effectueraient des opérations sur un nombre différent de variables membres.

Il y a une chose curieuse que vous pouvez faire avec C ++ (Vous n'avez pas spécifié de langage, et cette réponse est principalement parce que je pense que c'est agréable de voir des alternatives, bien que je ne pense pas vraiment que cela soit utile dans la plupart des cas.)

En utilisant des modèles, vous pouvez faire quelque chose comme ceci:

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

et cela peut être utilisé comme ceci:

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

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

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

Comme je l'ai dit, je ne pense pas que ce soit utile, et cela compliquera probablement votre vie lorsque vous essayez d'implémenter dot / normaliser / autre et d'essayer d'être générique avec un certain nombre de vecteurs.

Quelle que soit la vitesse, la première question que vous devez vous poser lorsque vous effectuez un héritage est de savoir si vous allez les utiliser de manière polymorphe. Plus précisément, existe-t-il une situation où vous pouvez vous voir utiliser un Vector3comme si c'était un Vector2(qui, en héritant de celui-ci, vous dites explicitement qu'un Vector3 "est-un" Vector2).

Sinon, vous ne devez pas utiliser l'héritage. Vous ne devez pas utiliser l'héritage pour partager du code. C'est à cela que servent les composants et les fonctions externes, pas que vous partagiez de tout code entre eux de toute façon.

Cela étant dit, vous voudrez peut-être des moyens simples de convertir Vector3 s en Vector2s, et dans ce cas, vous pouvez écrire une surcharge d'opérateur qui tronquera implicitement le Vector3en a Vector2. Mais vous ne devriez pas hériter.

Non, car chaque méthode devra également être remplacée, vous n'aurez donc pas besoin d'en hériter.

Si quelque chose, ils pourraient tous deux implémenter une interface vectorielle. Cependant, comme vous ne voulez probablement pas ajouter / sub / dot / dst entre un Vector2 et un Vector3, cela aura des effets secondaires indésirables. Et avoir différents paramètres, etc. serait un problème.
Donc, je ne vois vraiment aucun avantage de l'héritage / interface dans ce cas.

Un exemple est le framework Libgdx, où Vector2 et Vector3 n'ont rien à voir l'un avec l'autre, à part avoir le même type de méthodes.

Si vous prévoyez d'utiliser des baies SIMD sont probablement les meilleures. Si vous souhaitez toujours utiliser la surcharge d'opérateur, vous pouvez envisager d'utiliser une interface / mixin pour accéder au tableau sous-jacent - par exemple, voici un point de départ qui n'a que le (non testé) Add.

Remarquez comment je n'ai pas fourni X/ Y/ Z, chaque VectorXclasse hériterait directement de celle-ci - pour les mêmes raisons spécifiées par d'autres personnes. Pourtant, j'ai vu des tableaux utilisés comme vecteurs à plusieurs reprises dans la nature.

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

Avertissement: Mon C ++ pourrait être nul, cela fait un moment que je ne l'ai pas utilisé.

Un autre inconvénient sérieux pour que Vec3 hérite de Vec2 ou, sans doute, pour que les deux héritent d'une seule classe Vector: votre code fera beaucoupd'opérations sur des vecteurs, souvent dans des situations critiques, et il est dans votre intérêt de vous assurer que toutes ces opérations sont aussi rapides qu'elles le peuvent - beaucoup plus que pour de nombreux autres objets qui ne le sont pas tout à fait si universel ou bas niveau. Alors qu'un bon compilateur fera de son mieux pour aplanir les frais généraux d'héritage, vous comptez toujours plus sur le compilateur que vous ne le souhaiteriez; au lieu de cela, je les construirais comme des structures avec le moins de frais généraux possible et j'essaierais peut-être même de faire en sorte que la plupart des fonctions qui les utilisent (à l'exception de choses comme operator + qui ne peuvent pas vraiment être aidées) soient globales plutôt que des méthodes sur le struct. Une optimisation précoce est généralement recommandée contre, et pour une bonne raison,