“继承”可以是单一继承或多重继承，每一个继承连接可以是public，protected或private，也可以是virtual或non-virtual。然后是成员函数的各个选项：virtual？non-virtual？pure virtual？以及成员函数和其他语言特性的交互影响：缺省参数值与virtual函数有什么交互影响？继承如何影响C++的名称查找规则？设计选项有哪些？若class的行为需要修改，virtual函数是最佳选择吗？

以C++面向对象编程，最重要的一个规则是：public inheritance（公开继承）意味"is-a"（是一种）关系。

is-a的解释

若你令class D（"Derived"）以public形式继承class B("Base"），你便是告诉编译器（以及你的代码读者）说，每一个类型为D的对象同时也是一个类型为B的对象，反之不成立。即，B比D表现出更一般化的概念，而D比B表现出更特殊化的概念。你主张“B对象可派上用场的任何地方，D对象一样可以派上用场”（此即所谓Liskov Subdtitution Principle），因为每一个D对象都是一种（是一个）B对象。反之若你需要一个D对象，B对象无法效劳，因为虽然每个D对象都是一个B对象，反之并不成立。

考虑下面的例子：

class Person{/*...*/};
class Student: public Person{/*...*/};

根据生活经验知道，每个学生都是人，但并非每个人都是学生。这便是这个继承体系的主张。我们预期，对人可以成立的每一件事——例如每个人都有生日——对学生也都成立。但我们并不预期对学生可成立的每一件事——例如他或她注册于某所学校——对人也成立。

于是，承上所述，在C++领域中，任何函数若期望获得一个类型为Person（或pointer-to-Person或reference-to-Person）的实参，都也愿意接受一个Student对象（或pointer-to-Student或reference-to-Student）：

void eat(const Person& p);//任何人都会吃
void study(const Student& s);//只有学生才到校学校
Person p;//p是人
Student s;//s是学生
eat(p);//没问题，p是人
eat(s);//没问题，s是学生，而学生也是（is-a）人
study(s);//没问题，s是学生
//study(p);//错误，p不是学生

这个论点只对public继承才成立。只有当Student以public方式继承Person，C++的行为才会如上所述。

再来看另一个例子，

企鹅是一种鸟，而鸟可以飞。

因此，用C++表示这层关系：

class Bird {
public:virtual void fly();//鸟可以飞//...
};
class Penguin :public Bird {//企鹅是一种鸟//...
};

但这个代码是不对的，因为企鹅实际上不会飞。

当说鸟会飞时，真正的意思并不是说所有的鸟都会飞，要说的只是一般的鸟都有飞行能力。

因此，将上述代码进行修改：

class Bird {//...//没有声明fly函数
};
class FlyingBird {
public:virtual void fly();//...
};
class Penguin :public Bird {//...//没有声明fly函数
};

即便如此，我们仍未能完全处理好上述关系，因为对某些软件系统而言，可能不需要区分会飞的鸟和不会飞的鸟。若你的程序忙着处理鸟喙和鸟翅，完全不在乎飞行，原先的“双class继承体系”或许就相当令人满足了。

这反映出一个事实，世界上并不存在一个“适用于所有软件”的完美设计。所谓最佳设计，取决于系统希望做什么事，包括现在与未来。若你的程序对飞行一无所知，而且也不打算未来对飞行“有所知”，那么不去区分会飞的鸟和不会飞的鸟，不失为一个完美而有效的设计。

另一种修改上述代码的方法为：为企鹅重新定义fly函数，令它产生一个运行期错误：

void error(const std::string& msg);//定义于某处
class Penguin :public Bird {virtual void fly() { error("Attempt to make a penguin fly!"); }//...
};

注意，你必须认知这里所说的某些东西可能和你所想的不同。这里并不是说“企鹅不会飞”，而是说“企鹅会飞，但尝试那么做是一种错误”。

如何描述其间的差异？从错误被侦测出来的时间点观之，“企鹅不会飞”这一限制可由编译器强制实施，但若违反“企鹅尝试飞行，是一种错误”这一条规则，只有运行期才能检测出来。

为了表现“企鹅不会飞，就这样”的限制，你不可以为Penuguin定义fly函数：

class Bird {//...//没有声明fly函数
};
class Penguin :public Bird {//...//没有声明fly函数
};

现在，若你试图让企鹅飞，编译器会对你的背信加以谴责：

Penguin p;
//p.fly();//错误

这和采取“令程序与运行期发生错误”的解法不同，若以那种做法，编译器不会对p.fly调用式发出任何抱怨。

public继承常见的错误

现在再来看个例子，正方形与矩形之间有什么关系？

或许你会认为class Square应该以public继承class Rectangle。

但这样的认知可能是错的。

考虑这段代码：

class Rectangle {
public:virtual void setHeight(int newHeight);virtual void setWidth(int newWidth);virtual int height() const;//返回当前值virtual int width() const;//...
};
void makeBigger(Rectangle& r)//这个函数用以增加r的面积
{int oldHeight = r.height();r.setWidth(r.width() + 10);//为r的宽度加10assert(r.height() == oldHeight);//判断r的高度是否未曾改变
}

显然，上述的assert结果永远为真。因为makeBigger只改变r的宽度；r的高度从未被改变。

现在考虑这段代码。其中使用public继承，允许正方形被视为一种矩形：

class Square :public Rectangle {//...
};
//...
Square s;
assert(s.width() == s.height());//对所有正方形来说一定为真
makeBigger(s);//由于是public继承，所以可以增加其面积
assert(s.width() == s.height());//对所有正方形来说应该仍然为真，但是为假

很明显，上述代码中的第二个assert结果也应该永远为真。因为根据定义，正方形的宽度和其高度相同。

但现在我们遇上了一个问题。我们如何调解下面各个assert判断式：

1.调用makeBigger之前，s的高度和宽度相同

2.在makeBigger函数内，s的宽度改变，但高度不变

3.makeBigger返回之后，s的高度本应和其宽度相同，但现在不同。（注意s是以by reference方式传给makeBigger，所以makeBigger修改的是s自身，不是s的副本）

本例的根本困难是，某些可施行于矩形身上的事情（例如宽度可独立于其高度被外界修改）却不可施行于正方形身上（宽度总是应该和高度一样）。但public继承主张，能够施行于base class对象身上的每件事情，也可施行于derived class对象身上。

但这样的主张，在正方形和矩形身上无法保持，所以以public塑膜它们之间的关系并不正确。

is-a并非是唯一存在于class之间的关系。另两个常见的关系是has-a（有一个）和is-implemented-in-terms-of（根据某物实现出）。