5.2 数组

5.2.2 字符串文字量

         类似”this is a string.”这样一个字符串文字量，它是一个常量。正如代码中一个显式的数字0xff08一样，其值不可以被更改。如想修改，可以通过复制给一个变量来实现：

        

int a = 0xff08; a = 0xff18;

         对于字符串文字量则有一点要注意：

        

char* cp = “this is a string”;       //危险！赋值给一个普通字符指针； cp[4] = ‘e’;                     //未定义行为！不能给常量赋值； char p[] = “this is a string”;        //可以； p[4] = ‘e’;                      //正确执行；

         可以看出，用char *来引用字符串文字量是一个十分危险的地方。在上例中cp[4]=’e’;可以通过编译，但是在执行期间产生了一个Segmentation Fault。也就是说编译器并不能帮助程序员发现这类错误。

我个人是这样认为的：字符串文字量是一中很底层的数据，编译器把他放进汇编语言中的数据段；普通的char*指针也是一种很底层的指针，他可以指向内存空间中的任何地址；char* cp = “this is a string”;仅仅在栈空间生成一个指针，然后把他指向位于数据段的”this is a string”，初始化并不会导致错误。但是利用cp[4]更改数据段中的数据内容将会导致段错误，数据段是只读的。而利用char p[]形式的时候，意味着将在栈空间中生成一个字符数组，然后用”this is a string”来进行初始化，而后p指向这个栈空间中字符数组的首地址。此时p[4]=’e’;修改的是栈空间中的值，而不是数据段中的值。

但是p是什么类型呢？是char*么？他的大小是多少？是1么？为了使指针和数组首地址之间的区别更具普遍意义，我们用int类型来测试一下：

char p[] = "hello"; char* ptr = p; cout << sizeof(p) << ":" << sizeof(*p) << endl; cout << p << ":" << *p << endl; cout << sizeof(ptr) << ":" << sizeof(*ptr) << endl; cout << ptr << ":" << *ptr << endl;

这段代码在我的电脑上的输出是：

[/home/gavin/test]# ./test 6:1 hello:h 4:1 hello:h

ptr是真正的char*类型，其sizeof是4，但是p的sizeof却是6，也就是”hello”加一个‘\0’的长度。除此之外，ptr和p表现都一样。但我们最好认为p是字符数组类型，而ptr才是字符指针类型，因为他们的行为上存在差异。很多教师、教材都说：“数组名就是指向数组首地址的指针。”这其实并不完全正确。

再仔细看看，我们cout<<p和cout<<ptr的期望输出应该是p和ptr分别表示的地址。但事实上却是数组的内容。为了明显区分，再看下面这段代码：

int arr[4] = {0}; int* pa = arr; cout << sizeof(arr) << ":" << sizeof(*arr) << endl; cout << arr << ":" << *arr << endl; cout << sizeof(pa) << ":" << sizeof(*pa) << endl; cout << pa << ":" << *pa << endl;

在我的电脑上输出为：

[/home/gavin/test]# ./test 16:4 0xbfc26e5c:0 4:4 0xbfc26e5c:0

sizeof的输出刚才已经说过。这里可以看出，int数组名和char数组名的行为也不一样。事实上，cha数组名与标准类型数组名的行为都不一样。这也就是为什么C风格字符串为许多人诟病的地方。

C++在这方面提供了很好的改进：用一种更上层的类型string来代替C风格字符串。并强烈建议程序员在程序中尽量使用string来代替char *。这里是你需要做出选择的地方：

string str1("1"); string str2("1234567"); string str3("1234567890123456789012345678901234567890"); /* char str1[] = "1"; char str2[] = "1234567"; char str3[] = "1234567890123456789012345678901234567890"; */ cout << sizeof(str1) << endl; cout << sizeof(str2) << endl; cout << sizeof(str3) << endl;

当利用C风格字符串的输出为：

[/home/gavin/test]# ./test 2 8 41 [/home/gavin/test]# ls -l -rwxrwxr-x 1 863 863    6559 Dec  3 14:29 test -rw-rw-r-- 1 863 863     391 Dec  3 14:29 test.cpp

而当使用string时：

[/home/gavin/test]# ./test 4 4 4 [/home/gavin/test]# ls -l -rwxrwxr-x 1 863 863    7578 Dec  3 14:30 test -rw-rw-r-- 1 863 863     390 Dec  3 14:30 test.cpp

我们也许可以得到如下结论：sting比char[]需要更少的运行时内存空间，但是char[]却比string占用更少的磁盘空间。你可以自己选择向左还是向右走。不过相比string的易用性、安全性、以及诸多的成员函数带来的实用功能来说，我个人并不认为char[]节省的磁盘空间是很突出的优点。

• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

4.8 枚举

         枚举是表示具有共同属性的整型常量集合的用户自定义类型。这其中包含这些含义：

1.         枚举的取值只能是整数，正负皆可；

2.         枚举的取值是常量，枚举初始化后，这些值不能被改变；

3.         枚举也是一种用户自定义类型，用户定义好枚举后，可以自定义该枚举类型自身的操作，如“++”，“<<”等；

枚举类型的取值隐含着这样的“潜规则”：

l  如果枚举中所有枚举值均非负，那么该枚举表示的范围，是包含这些枚举值的所有[0, 2^k-1]区间中最小的那个；

l  如果枚举中包含负枚举值，那么该枚举表示的范围，是包含这些枚举值的所有[-2^k, 2^k-1]区间中最小的那个；

l  枚举的sizeof，就是某个能容纳其范围的整型的sizeof，但不会大于sizeof(int)；

l  如果不显式的复制，那么默认枚举值将从0开始递增；

例如：

enum Flags { A=1, B=2, C=9，D=7};  //Flags的取值范围是[0, 15]； Flags f1 = 5;          //错误！没有定义从int到Flags的隐式类型转换； Flags f2 = Flags(14);    //可以，利用显式的类型转换，而且14在[0,15]中； //虽然在Flags的定义当中没有14这个值； Flags f3 = Flags(21)；   //错误！21不在[0, 15]当中；

第5章 指针、数组和结构

5.1 指针

5.1.1 零

“由于各种标准转换，0可以被用于作为任意整型、浮点类型、指针、还有指向成员的指针的常量。”[1]

“0的类型将由上下文确定”[2]

         为更好的保证类型安全，建议在C++中用0代替所有的NULL。如果不得不使用NULL，那么用下面的妥协方案：

        

#ifndef _DEF_NULL_ #define _DEF_NULL_ const int NULL = 0; #endif

• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师

这样，A的开发人员可以根据不同环境，开发不同的驱动版本A1， A2， ....；而这些A的不同实现，并不影响B、C的设计和实现人员；P1、P2的开发人员可以根据自己实际需要选择A的不同实现（或者根据A.h自己再开发），而应用B，C。

另外一个好处是更换A的驱动，并不需要重新编译B、C，只需要重新编译P1，P2，并重新链接B、C即可。结构如下图：

带箭头的线表示继承关系，带实心球的线表示包含关系。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师

	#include<string>
	#include<iostream>
	using namespace std;

	class B {
	public:
		B(const string& ss) { cout << "B constructor\n"; f(ss); }
		virtual void f(const string&) { cout << "B::f\n";}
	};

	class D : public B {
	public:
		D(const string & ss) :B(ss) { cout << "D constructor\n";}
		void f(const string& ss) { cout << "D::f\n"; s = ss; }
	private:
		string s;
	};

	int main()
	{
		D d("Hello");
	}

	B constructor
	B::f
	D constructor

注意，输出不是D::f 。 究竟发生了什么？f()是在B::B()中调用的。如果构造函数中调用虚函数的规则不是如前文所述那样，
而是如一些人希望的那样去调用D::f()。那么因为构造函数D::D()尚未运行，字符串s还未初始化，所以当D::f()试图将参数
赋给s时，结果多半是——立马当机。

析构则正相反，遵循从继承类到基类的顺序（拆房子总得从上往下拆吧？），所以其调用虚函数的行为和在构造函数中一样：虚函数此时此刻被绑定到哪里（当然应该是基类啦——因为继承类已经被“拆”了——析构了！），调用的就是哪个函数。

更多细节请见《The Design and Evolution of C++》，13.2.4.2 或者《The C++ Programming Language》第三版，15.4.3 。

有时，这条规则被解释为是由于编译器的实作造成的。[译注：从实作角度可以这样解释：在许多编译器中，直到构造函数调用完毕，vtable才被建立，此时虚函数才被动态绑定至继承类的同名函数。] 但事实上不是这么一回事——让编译器实作成“构造函数中调用虚函数也和从其他函数中调用一样”是很简单的[译注：只要把vtable的建立移至构造函数调用之前即可]。关键还在于语言设计时的考量——让虚函数可以求助于基类提供的通用代码。[译注：先有鸡还是先有蛋？Bjarne实际上是在告诉你，不是“先有实作再有规则”，而是“如此实作，因为规则如此”。]

原文地址：http://www.research.att.com/~bs/bs_faq2.html#vcall

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

 类似这样的问题千奇百怪。例如：

• 为什么我明明不想复制对象，而编译器却偏偏这么做了呢？
• 如何关闭复制机制？
• 如何防止隐式转换？
• 为何 int 自动转换成了复数？

        struct Point {
            int x,y;
            Point(int xx = 0, int yy = 0) :x(xx), y(yy) { }
        };

        Point p1(1,2);
        Point p2 = p1;

    至此，p2.x==p1.x 并且 p2.y==p1.y。这可能正是你想要的（而且也是为了和 C 兼容所必需的），但是，以下代码：

        class Handle {
        private:
            string name;
            X* p;
        public:
            Handle(string n)
                :name(n), p(0) { /* acquire X called "name" and let p point to it */ }
            ~Handle() { delete p; /* release X called "name" */ }
            // ...
        };

        void f(const string& hh)
        {
             Handle h1(hh);
             Handle h1 = h2; // 会引起灾难！
             // ...
        }

    在此，默认复制构造函数使得 h2.name==h1.name 并且 h2.p==h2.p。这将导致一场灾难：当函数 f() 运行结束时，会调用 h1 和 h2 的析构函数，这就导致 h1.p 和 h2.p 所指向的对象被 delete 了两次。

    如何避免这场灾难？最简单的办法是，将复制构造函数和赋值运算符声明为私有成员，从而关闭复制机制：

        class Handle {
        private:
            string name;
            X* p;

            Handle(const Handle&); // 阻止复制
            Handle& operator=(const Handle&);
        public:
            Handle(string n)
               :name(n), p(0) { /* acquire the X called "name" and let p point to it */ }
            ~Handle() { delete p; /* release X called "name" */ }
             // ...
        };

        void f(const string& hh)
        {
            Handle h1(hh);
            Handle h1 = h2; // 编译器报错
            // ...
        }

    如果需要复制机制，我们可以定义自己的复制构造函数和赋值运算符，让它们按我们期待的那样工作。

    现在回过头来再看看类 Point。对 Point 来说，可以使用默认的复制机制，但它的构造函数有点问题：

        struct Point {
            int x,y;
            Point(int xx = 0, int yy = 0) :x(xx), y(yy) { }
        };

        void f(Point);

        void g()
        {
            Point orig;  // 使用默认值 (0,0) 创建 orig 
            Point p1(2); // 使用 yy 的默认值 (0) 来创建 p1
            f(2);        // 调用 Point(2,0);
        }

    为了便于创建对象（如这里的 orig 和 p1），我们为 Point 的构造函数提供了默认参数。然后，有些人会感到惊讶的事情发生了：调用 f() 时，2 会转换成 Point(2,0)。当我们定义一个接受单个参数的构造函数时，同时亦定义了一种类型转换方式。默认情况下，类型转换是隐式进行的。若想把类型转换改成 显式进行，就要将构造函数声明为 explicit：

        struct Point {
            int x,y;
            explicit Point(int xx = 0, int yy = 0) :x(xx), y(yy) { }
        };

        void f(Point);

        void g()
        {
            Point orig;   // 使用默认值 (0,0) 创建 orig 
            Point p1(2);  // 使用 yy 的默认值 (0) 来创建 p1
                          // 显式调用构造函数
            f(2);         // 错误（试图进行隐式转换）
            Point p2 = 2; // 错误（试图进行隐式转换）
            Pont p3 = Point(2); // 正确（显式转换）
        }

原文地址：http://www.research.att.com/~bs/bs_faq2.html#explicit-ctor

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

如果你想得到一个可用于常量表达式中的常量，例如数组大小的定义，那么你有两种选择：

	class X {
		static const int c1 = 7;
		enum { c2 = 19 };

		char v1[c1];
		char v2[c2];

		// ...
	};

一眼望去，c1的定义似乎更加直截了当，但别忘了只有static const的整型或枚举型量才能如此初始化。这就很有局限性，例如：

	class Y {
		const int c3 = 7;		// error: not static
		static int c4 = 7;		// error: not const
		static const float c5 = 7;	// error not integral
	};

我还是更喜欢玩“enum戏法”，因为这种定义可移植性好，而且不会引诱我去使用非标准的“类内初始化”扩展语法。

那么，为何要有这些不方便的限制？因为类通常声明在头文件中，而头文件往往被许多单 元所包含。但是，为了避免链接器设计的复杂化，C++要求每个对象都只能被定义一次。如果C++允许类内定义要作为对象被存在内存中的实体，那么这项要求 就无法满足了。关于C++设计时的一些折衷，参见《The Design and Evolution of C++》。

如果这个常量不需要被用于常量表达式，那么你的选择余地就比较大了：

	class Z {
		static char* p;		// initialize in definition
		const int i;		// initialize in constructor
	public:
		Z(int ii) :i(ii) { }
	};

	char* Z::p = "hello, there";

	class AE {
		// ...
	public:
		static const int c6 = 7;
		static const int c7 = 31;
	};

	const int AE::c7;	// definition

	int f()
	{
		const int* p1 = &AE::c6;	// error: c6 not an lvalue
		const int* p2 = &AE::c7;	// ok
		// ...
	}

原文地址：http://www.research.att.com/~bs/bs_faq2.html#in-class

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

	class Empty { };

	void f()
	{
		Empty a, b;
		if (&a == &b) cout << "impossible: report error to compiler supplier";

		Empty* p1 = new Empty;
		Empty* p2 = new Empty;
		if (p1 == p2) cout << "impossible: report error to compiler supplier";
	}	

	struct X : Empty {
		int a;
		// ...
	};

	void f(X* p)
	{
		void* p1 = p;
		void* p2 = &p->a;
		if (p1 == p2) cout << "nice: good optimizer";
	}

• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

	#include<vector>
	#include<string>
	#include<iostream>
	#include<algorithm>
	using namespace std;

	int main()	// small program messing around with strings
	{
		cout << "enter some whitespace-separated words:\n";
		vector<string> v;
		string s;
		while (cin>>s) v.push_back(s);

		sort(v.begin(),v.end());

		string cat;
		typedef vector<string>::const_iterator Iter;
		for (Iter p = v.begin(); p!=v.end(); ++p) cat += *p+"+";
		cout << cat << '\n';
	}

请注意这里没有显式的内存管理代码。没有宏，没有类型转换，没有溢出检测，没有强制的大小限制，也没有指针。如果使用function object和标准算法[译注：指标准库中提供的泛型算法]，我连Iterator也可以不用。不过这毕竟只是一个小程序，杀鸡焉用牛刀？

当然，这些方法也并非无懈可击，而且说起来容易做起来难，要系统地使用它们 也并不总是很简单。不过，无论如何，它们的广泛适用性令人惊讶，而且通过移去大量的显式内存分配/释放代码，它们确实增强了代码的可读性和可管理性。早在 1981年，我就指出通过大幅度减少需要显式加以管理的对象数量，使用C++“将事情做对”将不再是一件极其费神的艰巨任务。

如果你的应用领域没有能在内存管理方面助你一臂之力的类库，那么如果你还想让你的软件开发变得既快捷又能轻松得到正确结果，最好是先建立这样一个库。

如果你无法让内存分配和释放成为对象的“自然行为”，那么至少你可以通过使 用资源句柄来尽量避免内存泄漏。这里是一个示例：假设你需要从函数返回一个对象，这个对象是在自由内存堆上分配的；你可能会忘记释放那个对象——毕竟我们 无法通过检查指针来确定其指向的对象是否需要被释放，我们也无法得知谁应该负责释放它。那么，就用资源句柄吧。比如，标准库中的auto_ptr就可以帮 助澄清：“释放对象”责任究竟在谁。我们来看：

	#include<memory>
	#include<iostream>
	using namespace std;

	struct S {
		S() { cout << "make an S\n"; }
		~S() { cout << "destroy an S\n"; }
		S(const S&) { cout << "copy initialize an S\n"; }
		S& operator=(const S&) { cout << "copy assign an S\n"; }
	};

	S* f()
	{
		return new S;	// who is responsible for deleting this S?
	};

	auto_ptr<S> g()
	{
		return auto_ptr< S >(new S);	// explicitly transfer responsibility for deleting this S
	}

	int main()
	{
		cout << "start main\n";
		S* p = f();
		cout << "after f() before g()\n";
	//	S* q = g();	// caught by compiler
		auto_ptr< S > q = g();
		cout << "exit main\n";
		// leaks *p
		// implicitly deletes *q
	}

这里只是内存资源管理的例子；至于其它类型的资源管理，可以如法炮制。

如果在你的开发环境中无法系统地使用这种方法（比方说，你使用了第三方提供的古董代码，或者远古“穴居人”参与了你的项目开发），那么你在开发过程中可千万要记住使用内存防漏检测程序，或者干脆使用垃圾收集器（Garbage Collector）。

原文地址：http://www.research.att.com/~bs/bs_faq2.html#memory-leaks

• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛

   C++ 代码编写标准的要点是：根据使用 C++ 的具体的环境和具体目的制定一套规则。因此，没有哪一种代码编写标准是符合所有需要和所有用户的。对于一个特定的应用程序（或者公司、应用领域，等等）来 说，一种好的代码编写标准当然比没有标准要好得多。话说回来，我看到过很多例子表明一种差劲的代码编写标准比没有标准还要更糟糕。

    选择规则时，请切记细心，而且你必须对该应用领域有过硬的知识。一些最差劲的代码编写标准（“为了保护罪犯”，我不会提及这些 名字）的作者既没有过硬的 C++ 知识，而且对其应用领域也相对无知（他们是“专家”，而非开发人员），更误以为约束总是多比少好。针对前面这种误解的一个反例是：某些特性的存在会导致程 序员不得不使用甚至更糟糕的特性。怎么都好，请牢记，安全性、生产率等是设计和开发过程的所有部分的总和——而非各种语言特性的总和，更不是所有语言的总 和。

    基于以上原因，我的推荐有三：

• 看 Sutter 和 Alexandrescu 合著的《C++ 代码编写标准（C++ Coding Standards）》。Addison-Wesley 出版，ISBN 0-321-11358-。这本书里有很多好的规则，但请把这些规则看作一套元规则（meta-rules）。更明确地说，就是把这本书当作一本关于“一 套优秀的代码编写规则应该是怎么样的”的指南。如果你正在写代码编写标准，不看这本书将是一大损失。
• 看 JSF 航空器 C++ 代码编写标准。 我认为这是一套关于编写对安全性和性能要求苛刻的代码的优秀规则。如果你从事嵌入式系统编程，那你应该考虑看一下这份标准。告诫：我参与了这些规则的制 定，所以你可以认为我带有偏心。话说回来，请将你对这份标准的建设性意见发给我。这些意见可能会推动这份标准的改进——所有优秀的标准都会定期地被重新审 视，并且根据经验和工作环境的变化而更新。如果你不是在构建苛刻的实时系统或者对安全性要求苛刻的系统，那你会觉得这些规则过于严格——毕竟这些规则并非 为你而设（至少并非所有这些规则都是为你而设的）。
• 不要使用 C 语言代码编写标准（即使已将其修改为 C++ 版），也不要使用 10 年前的 C++ 代码编写标准（即使在那时来说是很优秀的标准）。C++ 并非（仅仅）是 C，而标准 C++ 也并非（仅仅）是标准前的 C++。

• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师

    你的编译器可能有问题。也许它太老了，也许你安装它的时候出了错，也许你用的计算机已经是个古董。在诸如此类的问题上，我无法帮助你。 

    但是，这也是很可能的：你要编译的程序设计得非常糟糕，以至于编译器不得不检查数以百计的头文件和数万行代码。理论上来说，这是可以避免的。如果这是你购 买的库的设计问题，你对它无计可施（除了换一个更好的库），但你可以将你自己的代码组织得更好一些，以求得将修改代码后的重新编译工作降到最少。这样的设 计会更好，更有可维护性，因为它们展示了更好的概念上的分离。 

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

        class Shape {
        public:     // 使用Shapes的用户的接口
             virtual void draw() const;
            virtual void rotate(int degrees);
            // ...
        protected:  // common data (for implementers of Shapes)
            Point center;
            Color col;
            // ...
        }; 

        class Circle : public Shape {
        public: 
            void draw() const;
            void rotate(int) { }
            // ...
        protected:
            int radius;
            // ...
        };

        class Triangle : public Shape {
        public: 
            void draw() const;
            void rotate(int);
            // ...
        protected:
            Point a, b, c;
            // ...
        }; 

    设计思想是，用户通过Shape的public接口来操纵它们，而派生类（例如Circle和Triangle）的实现部分则共享由protected成员表现的那部分实现（implementation）。

    然而，这个简单的设计理念里却隐含着三个严重的问题：

• 这不是一件容易的事情：确定哪些实现部分是对所有的派生类都有用的，并将之共享出来。因此，与public接口相比，protected成员往往要做多得多的改动。举例来说，虽然理论上“中心”(center)对所有的图形都是一个有效的概念，但当你要维护一个三角形的“中心”的时候，是一件非常麻烦的事情——对于三角形，当且仅当它确实被需要的时候，计算这个中心才是有意义的。 
• protected成员很可能要依赖于实现部分的细节，而Shape的用户（译注：user此处译为用户，指使用Shape类的代码，下同）却不见得必须依赖它们。举例来说，很多（大多数？）使用Shape的代码在逻辑上是与“颜色”无关的，但是由于Shape中“颜色”这个定义的存在，却可能需要一堆复杂的头文件，来结合操作系统的颜色概念。 
• 当protected部分发生了改变时，使用Shape的代码必须重新编译——即使只有派生类的实现部分才能够访问protected成员。

    于是，基类中的“实现相关的信息”(information helpful to implementers)对用户来说变成了象接口一样敏感的东西，它的存在导致了实现部分的不稳定，用户代码的无谓的重编译（当实现部分发生改变时），以及将头文件无节制地包含进用户代码中（因为“实现相关的信息”需要它们）。有时这被称为“脆弱的基类问题”(brittle base class problem)。 

    一个很明显的解决方案就是，忽略基类中那些象接口一样被使用的“实现相关的信息”。换句话说，使用接口，纯粹的接口。也就是说，用抽象基类的方式来表示接口： 

        class Shape {
        public:     //使用Shapes的用户的接口
            virtual void draw() const = 0;
            virtual void rotate(int degrees) = 0;
            virtual Point center() const = 0;
            // ...
            // 没有数据
        };

        class Circle : public Shape {
        public: 
            void draw() const;
            void rotate(int) { }
            Point center() const { return center; }
            // ...
        protected:
            Point cent;
            Color col;
            int radius;
            // ...
        }; 

        class Triangle : public Shape {
        public: 
            void draw() const;
            void rotate(int);
            Point center() const;
            // ...
        protected:
            Color col;
            Point a, b, c;
            // ...
        };   

    现在，用户代码与派生类的实现部分的变化之间的关系被隔离了。我曾经见过这种技术使得编译的时间减少了几个数量级。 

    但是，如果确实存在着对所有派生类（或仅仅对某些派生类）都有用的公共信息时怎么办呢？可以简单把这些信息封装成类，然后从它派生出实现部分的类： 

    class Shape {
    public:     //使用Shapes的用户的接口
        virtual void draw() const = 0;
        virtual void rotate(int degrees) = 0;
        virtual Point center() const = 0;
        // ...
        // no data
    }; 

    struct Common {
        Color col;
        // ...
    };       

    class Circle : public Shape, protected Common {
    public: 
        void draw() const;
        void rotate(int) { }
        Point center() const { return center; }
        // ...
    protected:
        Point cent;
        int radius;
    }; 

    class Triangle : public Shape, protected Common {
    public: 
        void draw() const;
        void rotate(int);
        Point center() const;
        // ...
    protected:
        Point a, b, c;
    }; 

原文地址：http://www.research.att.com/~bs/bs_faq2.html#abstract-class