O Vector3 deve herdar do Vector2?

Estou criando um par de classes Vector2(X & Y) e Vector3(X, Y & Z), mas eu não sei se para fazer Vector3herdar a partir de Vector2, ou se a re implementar-as variáveis de membro m_xe m_yde novo? Quais são os prós e os contras de cada lado (herança versus redefinição).

Edit: Estou usando C ++ (VS2010).

Não, não deveria. A única coisa que você estaria usando da herança é o xe ycomponentes. Os métodos usados ​​em uma Vector2classe não seriam úteis em uma Vector3classe, provavelmente usariam argumentos diferentes e executariam operações em um número diferente de variáveis-membro.

Há uma coisa curiosa que você pode fazer com C ++ (você não especificou uma linguagem, e essa resposta é principalmente porque acho bom ver alternativas, embora eu realmente não acredite que isso seja útil na maioria dos casos.)

Usando modelos, você pode fazer algo assim:

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

e isso pode ser usado assim:

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

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

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

Como eu disse, não acho que isso seja útil e provavelmente complicará sua vida quando você tentar implementar pontos / normalizar / outras coisas e tentar ser genérico com qualquer número de vetores.

Independentemente da velocidade, a primeira pergunta que você deve fazer a si mesmo ao fazer uma herança é se vai usá-las polimorficamente. Mais especificamente, existe alguma situação em que você pode se ver usando a Vector3como se fosse um Vector2(que, herdando dela, está explicitamente dizendo que um vetor3 "é-um" vetor2).

Caso contrário, você não deve usar herança. Você não deve usar herança para compartilhar código. É para isso que servem os componentes e funções externas, não que você esteja compartilhando qualquer código entre eles de qualquer maneira.

Dito isto, você pode querer maneiras fáceis de converter Vector3 s para Vector2s e, nesse caso, pode escrever uma sobrecarga de operador que truncará implicitamente o Vector3para a Vector2. Mas você não deve herdar.

Não, já que todos os métodos também precisam ser substituídos, você não poderá herdar dele.

Se alguma coisa, ambos poderiam implementar uma interface Vector. No entanto, como você provavelmente não deseja adicionar / sub / dot / dst entre um Vector2 e Vector3, isso terá efeitos colaterais indesejados. E ter parâmetros diferentes, etc., seria um aborrecimento.
Então, eu realmente não consigo ver nenhum profissional de herança / interface neste caso.

Um exemplo é a estrutura Libgdx, onde Vector2 e Vector3 não têm nada a ver um com o outro, além de ter o mesmo tipo de métodos.

Se você planeja usar matrizes SIMD, provavelmente é o melhor. Se você ainda deseja sobrecarregar o operador, considere usar uma interface / mixin para acessar a matriz subjacente - por exemplo, aqui está um ponto de partida que possui apenas o (não testado) Add.

Observe como eu não forneci X/ Y/ Z, cada VectorXclasse herdaria diretamente dessa - pelas mesmas razões especificadas por outras pessoas. Ainda assim, eu vi matrizes usadas como vetores muitas vezes na natureza.

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

Isenção de responsabilidade: Meu C ++ pode ser uma droga, já faz um tempo desde que eu o usei.

Outro golpe sério em ter o Vec3 herdado do Vec2 ou, sem dúvida, em herdar os dois de uma única classe Vector: seu código estará fazendo muitode operações em vetores, geralmente em situações críticas, e é de seu interesse garantir que todas essas operações sejam o mais rápidas possível - muito mais do que é para muitos outros objetos que não são tão universal ou de baixo nível. Enquanto um bom compilador fará o possível para aplanar qualquer sobrecarga de herança, você continuará confiando mais no compilador do que gostaria; em vez disso, eu os construíria como estruturas com o mínimo de sobrecarga possível e possivelmente tentaria e faria com que a maioria das funções que as usassem (com exceção de coisas como operador + que realmente não podem ser ajudadas) fossem globais em vez de métodos no struct. Geralmente, a otimização antecipada é recomendada contra, e por um excelente motivo,