C + +程序设计语言(特别版)【忠告】.pdfVIP

C + +程序设计语言 （特别版） 第1章 忠告 这里是一组在你学习 C + + 的过程中或许应该考虑的“规则”。随着你变得更加熟练，你将能 把它转化为某种更适合你的那类应用系统或者你自己的程序设计风格的东西。它们有意被写得 很简单，因此都缺乏细节。请不要太拘泥于它们的字面意义。要写出一个好程序需要智慧、品 味和耐性。你不会第一次就能把它搞好的。试验！ [1] 在编程序时，你是在为你针对某个问题的解决方案中的思想建立起一种具体表示。让程 序的结构尽可能地直接反映这些思想： [a] 如果你能把“它”看成一个独立的概念，就把它做成一个类。 [b] 如果你能把“它”看成一个独立的实体，就把它做成某个类的一个对象。 [c] 如果两个类有共同的界面，将此界面做成一个抽象类。 [d] 如果两个类的实现有某些显著的共同东西，将这些共性做成一个基类。 [e] 如果一个类是一种对象的容器，将它做成一个模板。 [f] 如果一个函数实现对某容器的一个算法，将它实现为对一族容器可用的模板函数。 [g] 如果一组类、模板等互相之间有逻辑联系，将它们放进一个名字空间里。 [2] 在你定义一个并不是实现某个像矩阵或复数这样的数学对象的类时，或者定义一个低层 的类型如链接表的时候： [a] 不要使用全局数据（使用成员）。 [b] 不要使用全局函数。 [c] 不要使用公用数据成员。 [d] 不要使用友元，除非为了避免 [a] 或 [ c ]。 [e] 不要在一个类里面放“类型域”；采用虚函数。 [f] 不要使用在线函数，除非作为效果显著的优化。 更特殊或更详尽的实用规则可以在每章最后的“忠告”一节里找到。请记住，这些忠告只是粗 略的实用规则，而不是万古不变的定律。它们只应使用在“合理的地方”。从来就没有任何东西 能够替代智慧、经验、常识和好的鉴赏力。 我发现具有“绝不要做这个”形式的规则不大有帮助。因此，大部分忠告被写成应该做什 么的建议，而否定性的建议也倾向于不采用绝对禁止的短语。据我所知，没有任何一种主要的 C + +特征没有被良好地使用过。在有关“忠告”的节里不包括解释，相反，每条忠告都引用了本 书中某些适当的章节。在给出否定性的忠告时，对应章节里通常都提供了有关其他替代方式的 建议。 第2章 忠告 [1] 不用害怕，一切都会随着时间的推移而逐渐明朗起来； 2 . 1节。 [2] 你并不需要在知道了C + + 的所有细节之后才能写出好的C + +程序； 1 . 7节。 [3] 请特别关注程序设计技术，而不是各种语言特征； 2 . 1节。 第3章 忠告 [1] 不要像重新发明车轮那样企图做每件事；去使用库。 [2] 不要相信奇迹；要理解你的库能做什么，它们如何做，它们做时需要多大的代价。 [3] 当你遇到一个选择时，应该优先选择标准库而不是其他的库。 [4] 不要认为标准库对于任何事情都是最理想的。 [5] 切记 # i n c l u d e你所用到的功能的头文件； 3 . 3节。 [6] 记住，标准库的功能定义在名字空间 s t d 之中；3 . 3节。 [7] 请用s t r i n g ，而不是c h a r *；3 . 5节、3 . 6节。 [8] 如果怀疑，就用一个检查区间范围的向量（例如 Ve c ）；3 . 7 . 2节。 [9] v e c t o r T 、l i s t T 和m a pk e y, value 都比T[ ] 好；3 . 7 . 1节、3 . 7 . 3节、3 . 7 . 4节。 [10] 如要向一个容器中添加一个元素，用p u s h _ b a c k ( ) 或b a c k _ i n s e r t e r( ) ；3 . 7 . 3节、3 . 8节。 [ 11] 采用对v e c t o r 的p u s h _ b a c k ( ) ，而不是对数组的r e a l l o c( ) ；3 . 8节。 [12] 在m a i n( ) 中捕捉公共的异常；3 . 7 . 2节。 第4 章 忠告 [1] 保持较小的作用域；4 . 9 . 4节。 [2] 不要在一个作用域和它外围的作用域里采用同样的名字； 4 . 9 . 4节。 [3] 在一个声明中（只）声明一个名字； 4 . 9 . 2节。 [4] 让常用的和局部的名字比较短，让不常用的和全局的名字比较长； 4 . 9 . 3节