If `Circle` is the base class and `Ellipse` is the derived class,
then you run into a whole new set of problems. For example, suppose
`Circle` has a `radius()` method. Then `Ellipse` will also
need to have a `radius()` method, but that doesn't make much sense: what
does it even mean for a possibly assymetric ellipse to have a radius?

If you get over that hurdle, such as by having `Ellipse::radius()`
return the average of the major and minor axes or whatever, then there is a
problem with the relationship between `radius()` and `area()`.
Suppose `Circle` has an `area()` method that promises to return
3.14159*[etc]* times the square whatever `radius()`
returns. Then either `Ellipse::area()` will not return the true area of
the ellipse, or you'll have to stand on your head to get `radius()` to
return something that matches the above formula.

Even if you get past that one, such as by having `Ellipse::radius()`
return the square root of the ellipse's area divided by pi, you'll get stuck
by the `circumference()` method. Suppose `Circle` has a
`circumference()` method that promises to return two times pi times
whatever is returned by `radius()`. Now you're stuck: there's no way to
make all those constraints work out for `Ellipse`: the `Ellipse`
class will have to lie about its area, its circumference, or both.

Bottom line: you can make anything inherit from anything *provided* the
methods in the derived class abide by the promises made in the base class.
But you ought not to use inheritance just because you feel like it, or just
because you want to get code reuse. You should use inheritance (a) only if
the derived class's methods can abide by all the promises made in the base
class, and (b) only if you don't think you'll confuse your users, and (c) only
if there's something to be gained by using the inheritance — some real,
measurable improvement in time, money or risk.