C++: derived class?

unihiekka · 02-02-2009, 04:28 AM

Hi guys!

I have written my own Vector class template on the same lines as valarray, but it supports arbitrary precision and has some additional class functions that I need. Vectors are now declared as

Code:

Vector <long double,10> vec;

for example, where vec has 10 elements of type long double.

However, I am now working on a new class template that should use these "Vectors". The new class template should do some operations with these vectors. Should this new class be a derived class then? I am slightly confused about when to make something a derived class. If not, how should I parse these vectors to the new class?

Thanks.

Nylex · 02-02-2009, 06:15 AM

What kinds of things are you going to use this new class for? Can you give examples?

Derived classes are specialisations of the base classes they're derived from and usually have more specific features. For example, both cats and dogs are types of animals, but they're (very) different. Do your classes fit this model at all?

unihiekka · 02-02-2009, 06:43 AM

No, not really, but never mind. I have solved the problem. I was having some issues with typedefs, which made me think that I might need inheritance, which I did not.

ta0kira · 02-02-2009, 02:38 PM

You should generally have a base class for Vector that doesn't have the numerical template argument, then fill it with pure-virtual functions for everything that isn't restricted by the numerical specification. You can then define less-specific operations in terms of this base class.

Code:

template <class Element>
struct VectorBase
{
    //general function for all length specializations
    virtual unsigned int vectorSize() const = 0;
};


template <class Element, unsigned int Length>
struct Vector : public VectorBase <Element>
{
    unsigned int vectorSize() const { return Length; }

    //cannot use with different sizes
    Vector operator + (const Vector&) const;
};

ta0kira

sundialsvcs · 02-03-2009, 09:40 AM

Speaking in broad-brush terms, you'll find that there are two general ways that you can "combine" functionality in an object-oriented system:

(1) Inheritance and subclassing work straight down the family tree. You get all of what your gene-pool gives you, plus what you change. But you must be "part of the family."

(2) Mix-ins let you deviate from that straight-inheritance approach. You can take any set of existing functionality and "mix in" other functionality ... the idea being that those "mixins" can be "mixed in" to almost anything, "regardless of who its daddy is."

Ultimately, at runtime, it comes down to the same basic thing: every object is "a chunk of data, with a method-pointer table somehow associated with it." What's in that method-table determines exactly what will happen when you ask a particular object to do a particular thing. Inheritance derives the method-table strictly from the parent class; mix-ins inject more specific changes into it.

"There are other ways, obviously." I intended to simplify.