Re: inheriting from std::vector bad practice?

Steve Chow wrote:


There are a few possible objections I can think of -- although I don't
think labelling code as "disgusting and wrong" is in any way productive.
(It's much better to explain the issues.)

1) Public inheritance usually models an IS-A relationship. For instance:

class Animal
{
    //... (stuff, likely including a virtual destructor)
};

class Dog : public Animal
{
    //...
};

Here, a Dog IS-AN Animal. Slightly more usefully, this satisfies what's
called the Liskov Substitution Principle (LSP) -- you can substitute a
Dog anywhere you'd expect to see an Animal. For instance:

void f(const Animal& a)
{
    //...
}

....

Dog rover;
f(rover);

In your example above, a Path might be represented by a
std::vector<Point2D>, but whether the IS-A relationship (or LSP) is
valid is questionable. By pinning down the representation of a Path so
concretely, you make it harder to change the interface later on.

One might also question whether there is any logical reason why a Path
IS-A std::vector<Point2D> any more than it IS-A std::list<Point2D>, for
example.

2) You have inherited the entire interface of std::vector<Point2D>,
whether you wanted to or not. Were you to want to impose any invariants
on Path (for example, say you wanted to guarantee that any valid Path
was of non-zero length), inheriting publicly would make that impossible.

3) (Minor issue, since it probably won't happen) std::vector doesn't
have a virtual destructor, so if you do anything like this it will go
horribly wrong:

std::vector<Point2D> *p = new Path;
delete p;

The chances of you doing this are probably quite low, but it compiles
without any errors and then invokes undefined behaviour at runtime --
which is worrying.

***

The simplest alternative approach is probably composition (i.e. have
your Path contain a private std::vector<Point2D> and then define your
interface for Path however you like, forwarding things to the internal
vector where necessary). If done well, this can give you a somewhat more
encapsulated design (making it easier to change the internal
representation later if you want).

Another possible solution is to use private inheritance to model the
fact that Path is "implemented in terms of" std::vector<Point2D>. You
can then use "using" to give public access to the relevant member
functions inherited from vector. This has some downsides, e.g. see:

http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.3

***

A few concluding remarks, then:

- Your approach does "work", but the design is questionable for (at
least) the reasons mentioned. If you're using it for a toy program,
you'll probably get away with it (but should strive to improve your
design skills nonetheless). If you're using it on a team project, expect
others to ask you to change it. The key issue is that you're essentially
abusing a language feature in order to save yourself some typing -- that
has a habit of coming back and biting you on the butt in larger
projects, particularly when your class is going to be publicly
available/widely used.

- C++ is a multi-paradigm language -- it doesn't just support OO
programming.

- Regarding findGreatestDistance(), it's somewhat hard to say where it
should go because you haven't specified precisely what it does (in
particular, the Point2D it returns doesn't seem like a distance). The
idea of moving it into Point2D doesn't sound that great -- but then
without a specification for what the function does, it's hard to comment.

Hope that helps a bit, anyway,
Stu