Vector3 có nên kế thừa từ Vector2 không?

Tôi đang tạo ra một vài lớp học Vector2(X & Y) và Vector3(X, Y & Z), nhưng tôi không biết liệu để làm cho Vector3kế thừa từ Vector2, hay để tái thực hiện các biến thành viên m_xvà m_ymột lần nữa? Những ưu và nhược điểm của mỗi bên (thừa kế so với xác định lại).

Chỉnh sửa: Tôi đang sử dụng C ++ (VS2010).

Không, không nên. Điều duy nhất bạn đang sử dụng từ thừa kế là xvà ycác thành phần. Các phương thức được sử dụng trong một Vector2lớp sẽ không hữu ích trong một Vector3lớp, chúng có thể sẽ lấy các đối số khác nhau và thực hiện các hoạt động trên một số biến thành viên khác nhau.

Có một điều tò mò bạn có thể làm với C ++ (Bạn đã không chỉ định ngôn ngữ và câu trả lời này chủ yếu là vì tôi nghĩ thật tuyệt khi thấy các lựa chọn thay thế, mặc dù tôi không thực sự tin rằng điều này hữu ích trong hầu hết các trường hợp.)

Sử dụng các mẫu bạn có thể làm một cái gì đó như thế này:

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

và điều này có thể được sử dụng như thế này:

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

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

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

Như tôi đã nói, tôi không nghĩ rằng điều này hữu ích và nó có thể sẽ làm phức tạp cuộc sống của bạn khi bạn cố gắng thực hiện dấu chấm / chuẩn hóa / các công cụ khác và cố gắng chung chung với bất kỳ số lượng vectơ nào.

Bất kể tốc độ, câu hỏi đầu tiên bạn nên tự hỏi khi thực hiện bất kỳ sự kế thừa nào là liệu bạn có đang sử dụng chúng một cách đa hình không. Cụ thể hơn, có bất kỳ tình huống nào bạn có thể thấy chính mình khi sử dụng Vector3như thể nó là một Vector2(mà, bằng cách kế thừa từ nó, bạn nói rõ ràng rằng Vector3 "là" Vector2 ".

Nếu không, thì bạn không nên sử dụng thừa kế. Bạn không nên sử dụng tính kế thừa để chia sẻ mã. Đó là những thành phần và chức năng bên ngoài dành cho, không phải là bạn sẽ chia sẻ bất kỳ mã nào giữa chúng.

Điều đó đang được nói, bạn có thể muốn các cách dễ dàng để chuyển đổi Vector3 s thành Vector2s, và trong trường hợp đó bạn có thể viết một quá tải toán tử sẽ ngầm cắt ngắn Vector3thành a Vector2. Nhưng bạn không nên thừa kế.

Không, vì mọi phương thức sẽ cần được ghi đè cũng như bạn sẽ không sử dụng thực sự kế thừa từ nó.

Nếu một cái gì đó, cả hai có thể thực hiện một giao diện Vector. Tuy nhiên, vì có lẽ bạn không muốn thêm / sub / dot / dst giữa Vector2 và Vector3 nên điều này sẽ có tác dụng phụ không mong muốn. Và có các thông số khác nhau, vv sẽ là một rắc rối.
Vì vậy, tôi thực sự không thể thấy bất kỳ ưu điểm của thừa kế / giao diện trong trường hợp này.

Một ví dụ là khung Libgdx, trong đó Vector2 và Vector3 không liên quan gì đến nhau, ngoài việc có cùng loại phương thức.

Nếu bạn có kế hoạch sử dụng mảng SIMD có khả năng là tốt nhất. Nếu bạn vẫn muốn sử dụng quá tải toán tử, bạn có thể xem xét sử dụng giao diện / mixin để truy cập mảng bên dưới - ví dụ, đây là điểm bắt đầu chỉ có (chưa được kiểm tra) Add.

Lưu ý cách tôi chưa cung cấp X/ Y/ Z, mỗi VectorXlớp sẽ kế thừa trực tiếp từ lớp này - vì những lý do tương tự được chỉ định bởi những người khác. Tuy nhiên, tôi đã thấy các mảng được sử dụng như các vectơ nhiều lần trong tự nhiên.

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

Tuyên bố miễn trừ trách nhiệm: C ++ của tôi có thể bị mất, đã được một thời gian kể từ khi tôi sử dụng nó.

Một giả thuyết nghiêm trọng khác về việc thừa kế Vec3 từ Vec2 hoặc, được cho là có cả hai kế thừa từ một lớp Vector duy nhất: mã của bạn sẽ hoạt động rất nhiềucác hoạt động trên vectơ, thường trong các tình huống quan trọng về thời gian và rất có lợi cho bạn để đảm bảo rằng tất cả các hoạt động đó đều nhanh nhất có thể - nhiều hơn so với nhiều đối tượng khác không phải là khá phổ quát hoặc cấp thấp. Mặc dù một trình biên dịch tốt sẽ cố gắng hết sức để loại bỏ mọi chi phí thừa kế, nhưng bạn vẫn phụ thuộc nhiều vào trình biên dịch ở đó hơn là bạn muốn; thay vào đó, tôi sẽ xây dựng chúng thành các cấu trúc với càng ít chi phí càng tốt và thậm chí có thể thử và tạo ra hầu hết các chức năng sử dụng chúng (ngoại trừ những thứ như toán tử + không thực sự được trợ giúp) chứ không phải là phương thức trên cấu trúc. Tối ưu hóa sớm thường được đề nghị chống lại, và với lý do tuyệt vời,