Bjarne：为什么编译要花这么长的时间

Bje Stroustrup博士，1950年出生于丹麦，毕业于丹麦阿鲁斯大学和英国健保大学，曾任美国电话电报公司大规模程序设计研究部主任，美国电话电报公司贝尔实验室和ACM成员。1979年，B.S .开始开发一种语言，当时叫“带类的C”，后来演变成C++。1998年，ANSI/ISO C++标准制定，同年，B.S .出版了其经典之作《C++编程语言》的第三版。

您的编译器可能有问题。可能是太旧了，可能是你装的时候弄错了，也可能是你用的电脑是古董。在这种问题上我帮不了你。

但是，也有可能:你要编译的程序设计得太差，编译器要检查上百个头文件，上万行代码。理论上这是可以避免的。如果这是你购买的库的设计问题，你也无能为力(除了换一个更好的库)，但是你可以更好的组织自己的代码，尽量减少代码修改后的重新编译。这样的设计会更好，更容易维护，因为它们显示了更好的概念分离。

看看这个面向对象程序的典型例子:

class {
public://使用Shapes的用户接口
virtual void draw()const；
虚拟void旋转(int度)；
//...
protected: // common data(针对形状的实施者)
Point center；
Color col；
//...
}；

类圆:public Shape {
public:
void draw()const；
void rotate(int){ }
//...
protected:
int radius；
//...
}；

类三角形:public Shape {
public:
void draw()const；
void rotate(int)；
//...
受保护:
点a、b、c；
//...
}；

设计思想是用户通过自己的公共接口操纵形状，而派生类的实现部分(如圆形和三角形)共享受保护成员所表示的实现部分。

这不是一项容易的任务:确定哪些实现部分对所有派生类都有用，并共享它们。因此，与公共接口相比，受保护的成员通常需要做更多的更改。举个例子，虽然理论上“中心”对于所有图形都是一个有效的概念，但是当你想要维持一个三角形的“中心”时，这是一件非常麻烦的事情——对于一个三角形来说，当且仅当真正需要时，计算这个中心才有意义。

受保护的成员可能依赖于实现部分的细节，但是Shape的用户不一定必须依赖它们。比如很多(大多数？)使用Shape的代码在逻辑上是独立于“颜色”的，但是由于Shape中对“颜色”的定义，可能需要一堆复杂的头文件来组合操作系统的颜色概念。

当受保护部分更改时，使用Shape的代码必须重新编译，即使只有派生类的实现部分可以访问受保护成员。

因此，基类中的“对实现者有帮助的信息”变得和接口一样对用户敏感，它的存在导致了实现部分的不稳定，用户代码不必要的重新编译(当实现部分改变时)，以及用户代码中不受控制的包含头文件(因为“实现相关信息”需要它们)。这有时被称为“脆弱的基类问题”。