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.10] But my problem doesn't have anything to do with circles and ellipses, so what good is that silly example to me?

Ahhh, there's the rub. You think the Circle/Ellipse example is just a silly example. But in reality, your problem is an isomorphism to that example.

I don't care what your inheritance problem is, but all —yes all— bad inheritances boil down to the Circle-is-not-a-kind-of-Ellipse example.

Here's why: Bad inheritances always have a base class with an extra capability (often an extra member function or two; sometimes an extra promise made by one or a combination of member functions) that a derived class can't satisfy. You've either got to make the base class weaker, make the derived class stronger, or eliminate the proposed inheritance relationship. I've seen lots and lots and lots of these bad inheritance proposals, and believe me, they all boil down to the Circle/Ellipse example.

Therefore, if you truly understand the Circle/Ellipse example, you'll be able to recognize bad inheritance everywhere. If you don't understand what's going on with the Circle/Ellipse problem, the chances are high that you'll make some very serious and very expensive inheritance mistakes.