Section 21:
 21.1 Should I hide member functions that were public in my base class? 21.2 Errors trying to convert Derived** → Base**? 21.3 Is a parking-lot-of-Car a kind-of parking-lot-of-Vehicle? 21.4 Is an array of Derived a kind-of array of Base? 21.5 Does array-of-Derived is-not-a-kind-of array-of-Base mean arrays are bad? 21.6 Is a Circle a kind-of an Ellipse? 21.7 Are there other options to the "Circle is/isnot kind-of Ellipse" dilemma? 21.8 Why does this Circle-kind-of-Ellipse problem seem confusing? 21.9 Perhaps Ellipse should inherit from Circle then? 21.1 But my problem doesn't have anything to do with circles and ellipses, so what good is that silly example to me? 21.11 How could "it depend"??!? Aren't terms like "Circle" and "Ellipse" defined mathematically? 21.12 Is SortedList a kind-of List?
[21.11] How could "it depend"??!? Aren't terms like "Circle" and "Ellipse" defined mathematically?

It's irrelevant that those terms are defined mathematically. That irrelevance is why "it depends."

The first step in any rational discussion is to define terms. In this case, the first step is to define the terms Circle and Ellipse. Believe it or not, most heated disagreements over whether class Circle should/shouldn't inherit from class Ellipse are caused by incompatible definitions of those terms.

The key insight is to forget mathematics and "the real world," and instead accept as final the only definitions that are relevant for answering the question: the classes themselves. Take Ellipse. You created a class with that name, so the one and only final arbiter of what you meant by that term is your class. People who try to mix "the real world" into the discussion get hopelessly confused, and often get into heated (and, sadly, meaningless) arguments.

Since so many people just don't get it, here's an example. Suppose your program says class Foo : public Bar { ... }. This defines what you mean by the term Foo: the one, final, unambiguous, precise definition of Foo is given by unioning the public parts of Foo with the public parts of its base class, Bar. Now suppose you decide to rename Bar to Ellipse and Foo to Circle. This means that you (yes you; not "mathematics"; not "history"; not "precedence" nor Euclid nor Euler nor any other famous mathematician; little old you) have defined the meaning of the term Circle within your program. If you defined it in a way that didn't correspond to people's intuitive notion of circles, then you probably should have chosen a better label for your class, but nonetheless your definition is the one, final, unambiguous, precise definition of the term Circle in your program. If somebody else outside your program defines the same term differently, that other definition is irrelevant to questions about your program, even if the "somebody else" is Euclid. Within your program, you define the terms, and the term Circle is defined by your class named Circle.