Beyond that, the situation that I described is single-inheritance. Single inheritance is when each class directly inherits from one other class. Other things can inherit from the same class. The parent class itself may inherit from another class. The resulting mess of classes and inheritance will be a tree like this:
\n GrandDad\n | \\\n | \\\n | \\\n Dad UncleJim\n /| \\\n / | \\\n / | \\\n / | \\\n Me BrotherJohn CousinRobbie\n
(Where I've given classes names of plausible people.) Even though Dad has two children, and even though I have 2 ancestors, there is a simple chain of inheritance from each class to its parents. Every OO language allows you to set up class relationships like this. (Well, every OO language with classes...)
By contrast multiple inheritance is where you inherit directly from two different classes.
\n Mom Dad\n \\ /\n \\ /\n \\ /\n Me\n
With more realistic classes, Mom might decide what kind of I/O routines I have, while Dad decides how I perform key calculations. OO languages disagree on whether it is good to allow this, and disagree on how to handle the situation where you get the same method from both parents.
Of particular trouble is "the dreaded diamond". That is an inheritance relationship that looks like this:
\n GrandDad\n / \\\n / \\\n / \\\n Mom Dad\n \\ /\n \\ /\n \\ /\n Me\n
The problem arises because if some decision needs to visit every parent class, you're going to wind up visiting GrandDad's side of the family twice. This causes various subtle problems.
I don't want to go into exact details, but suffice it to say that incest is generally agreed to be as bad an idea in OO design as it is in real life.
Cheers,
Ben