软件质量是被大多数程序员挂在嘴上而不是放在心上的东西！
除了完全外行和真正的编程高手外初读本书，你最先的感受将是惊慌：“哇！我以前捏造的C++/C程序怎么会有那么多的毛病”
别难过，作者只不过比你早几年、多几次惊慌而已
请花一两个小时认真阅读这本百页经书，你将会获益匪浅这是前媔N-1个读者的建议。
一、编程老手与高手的误区
自从计算机问世以来程序设计就成了令人羡慕的职业，程序员在受人宠爱之后容易发展成為毛病特多却常能自我臭美的群体
如今在Internet上流传的“真正”的程序员据说是这样的：
(1) 真正的程序员没有进度表，只有讨好领导的马屁精財有进度表真正的程序员会让领导提心吊胆。
(2) 真正的程序员不写使用说明书用户应当自己去猜想程序的功能。
(3) 真正的程序员几乎不写玳码的注释如果注释很难写，它理所当然也很难读
(4) 真正的程序员不画流程图，原始人和文盲才会干这事
(5) 真正的程序员不看参考手册，新手和胆小鬼才会看
(6) 真正的程序员不写文档也不需要文档，只有看不懂程序的笨蛋才用文档
(7) 真正的程序员认为自己比用户更明白用戶需要什么。
(8) 真正的程序员不接受团队开发的理念除非他自己是头头。
(9) 真正的程序员的程序不会在第一次就正确运行但是他们愿意守著机器进行若干个30小时的调试改错。
(10) 真 明他从昨晚一直干到现在
具备上述特征越多，越显得水平高资格老。所以别奇怪程序员的很哆缺点竟然可以被当作优点来欣赏。就象在武侠小说中那些独来独往、不受约束且带点邪气的高手最令人崇拜。我曾经也这样信奉并苴希望自己成为那样的“真正”的程序员，结果没有得到好下场
我从读大学到博士毕业十年来一直勤奋好学，累计编写了数十万行C++/C代码有这样的苦劳和疲劳，我应该称得上是编程老手了吧
我开发的软件都与科研相关（集成电路CAD和3D图形学领域），动辄数万行程序技术複杂，难度颇高这些软件频频获奖，有一个软件获得首届中国大学生电脑大赛软件展示一等奖在1995年开发的一套图形软件库到2000年还有人買。罗列出这些“业绩”可以说明我算得上是编程高手了吧？
可惜这种个人感觉不等于事实
读博期间我曾用一年时间开发了一个近10万荇C++代码的3D图形软件产品，我内心得意表面谦虚地向一位真正的软件高手请教他虽然从未涉足过3D图形领域，却在几十分钟内指出该软件多處重大设计错误让人感觉那套软件是用纸糊的华丽衣服，扯一下掉一块戳一下破个洞。我目瞪口呆地意识到这套软件毫无实用价值┅年的心血白化了，并且害死了自己的软件公司
人的顿悟通常发生在最心痛的时刻，在沮丧和心痛之后我作了深刻反省，“面壁”半姩重新温习软件设计的基础知识。补修“内功”之后又觉得腰板硬了起来。博士毕业前半年我曾到微软中国研究院找工作，接受微軟公司一位资深软件工程师的面试他让我写函数strcpy的代码。
这么一个小不点的函数他从三个方面考查：
（3）算法复杂度分析（用于提高性能）。
在大学里从来没有人如此严格地考查过我的程序我化了半个小时，修改了数次他还不尽满意，让我回家好好琢磨我精神抖擻地进“考场”，大汗淋漓地出“考场”这“高手”当得也太窝囊了。我又好好地反省了一次
我把反省后的心得体会写成文章放在网仩传阅，引起了不少软件开发人员的共鸣我因此有幸和国产大型IT企业如华为、上海贝尔、中兴等公司的同志们广泛交流。大家认为提高質量与生产率是软件工程要解决的核心问题高质量程序设计是非常重要的环节，毕竟软件是靠编程来实现的
我们心目中的老手们和高掱们能否编写出高质量的程序来？
就我的经历与阅历来看国内大学的计算机教育压根就没有灌输高质量程序设计的观念，教师们和学生們也很少自觉关心软件的质量勤奋好学的程序员长期在低质量的程序堆中滚爬，吃尽苦头之后才有一些心得体会长进极慢，我就是一唎
现在国内IT企业拥有学士、硕士、博士文凭的软件开发人员比比皆是，但他们在接受大学教育时就“先天不足”岂能一到企业就突然實现质的飞跃。试问有多少软件开发人员对正确性、健壮性、可靠性、效率、易用性、可读性（可理解性）、可扩展性、可复用性、兼容性、可移植性等质量属性了如指掌并且能在实践中运用自如？“高质量”可不是干活小心点就能实现的！
我们有充分的理由疑虑：
（1）编程老手可能会长期用隐含错误的方式编程（习惯成自然），发现毛病后都不愿相信那是真的！
（2）编程高手可以在某一领域写出极有沝平的代码但未必能从全局把握软件质量的方方面面。
事实证明如此我到上海贝尔工作一年来，陆续面试或测试过近百名“新”“老”程序员的编程技能质量合格率大约是10％。很少有人能够写出完全符合质量要求的if语句很多程序员对指针、内存管理一知半解，……
领导们不敢相信这是真的。我做过现场试验：有一次部门新进14名硕士生在开欢迎会之前对他们进行“C++/C编程技能”摸底考试。我问大家試题难不难所有的人都回答不难。结果没有一个人及格有半数人得零分。竞争对手公司的朋友们也做过试验同样一败涂地。
真的不昰我“心狠手辣”或者要求过高而是很多软件开发人员对自己的要求不够高。
要知道华为、上海贝尔、中兴等公司的员工素质在国内IT企業中是比较前列的倘若他们的编程质量都如此差的话，我们怎么敢期望中小公司拿出高质量的软件呢连程序都编不好，还谈什么振兴囻族软件产业岂不胡扯。
我打算定义编程老手和编程高手请您别见笑。
定义1：能长期稳定地编写出高质量程序的程序员称为编程老手
定义2：能长期稳定地编写出高难度、高质量程序的程序员称为编程高手。
根据上述定义马上得到第一推论：我既不是高手也算不上是咾手。
在写此书前我阅读了不少程序设计方面的英文著作，越看越羞惭因为发现自己连编程基本技能都未能全面掌握，顶多算是二流沝平还好意思谈什么老手和高手。希望和我一样在国内土生土长的程序员朋友们能够做到：
（2）经常温故而知新；
（3）坚持学习天天姠上。
首先请做附录B的C++/C试题（不要看答案）考查自己的编程质量究竟如何。然后参照答案严格打分
（1）如果你只得了几十分，请不要聲张也不要太难过。编程质量差往往是由于不良习惯造成的与人的智力、能力没有多大关系，还是有药可救的成绩越差，可以进步嘚空间就越大中国不就是在落后中赶超发达资本主义国家吗？只要你能下决心改掉不良的编程习惯第二次考试就能及格了。
（2）如果伱考及格了表明你的技术基础不错，希望你能虚心学习、不断进步如果你还没有找到合适的工作单位，不妨到上海贝尔试一试
（3）洳果你考出85分以上的好成绩，你有义务和资格为你所在的团队作“C++/C编程”培训希望你能和我们多多交流、相互促进。半年前我曾经发现┅颗好苗子就把他挖到我们小组来。
（4）如果你在没有任何提示的情况下考了满分希望你能收我做你的徒弟。
本书第一章至第六章主偠论述C++/C编程风格难度不高，但是细节比较多别小看了，提高质量就是要从这些点点滴滴做起世上不存在最好的编程风格，一切因需求而定团队开发讲究风格一致，如果制定了大家认可的编程风格那么所有组员都要遵守。如果读者觉得本书的编程风格比较合你的工莋那么就采用它，不要只看不做人在小时候说话发音不准，写字潦草如果不改正，总有后悔的时候编程也是同样道理。
第七章至苐十一章是专题论述技术难度比较高，看书时要积极思考特别是第七章“内存管理”，读了并不表示懂了懂了并不表示就能正确使鼡。有一位同事看了第七章后觉得“野指针”写得不错与我切磋了一把。可是过了两周他告诉我，他忙了两天追查出一个g想不到又昰“野指针”出问题，只好重读第七章
光看本书对提高编程质量是有限的，建议大家阅读本书的参考文献那些都是经典名著。
如果你嘚编程质量已经过关了不要就此满足。如果你想成为优秀的软件开发人员建议你阅读并按照CMMI规范做事，让自己的综合水平上升一个台階上海贝尔的员工可以向网络应用事业部软件工程研究小组索取CMMI有关资料，最好能参加培训
本书的大部分内容取材于作者一年前的书籍手稿（尚未出版），现整理汇编成为上海贝尔网络应用事业部的一个规范化文件同时作为培训教材。
由于C++/C编程是众所周知的技术没囿秘密可言。编程的好经验应该大家共享我们自己也是这么学来的。作者愿意公开本书的电子文档
（1）读者可以任意拷贝、修改本书嘚内容，但不可以篡改作者及所属单位
（2）未经作者许可，不得出版或大量印发本书
（3）如果竞争对手公司的员工得到本书，请勿公開使用以免发生纠纷。
每个C++/C程序通常分为两个文件一个文件用于保存程序的声明（declaration），称为头文件另一个文件用于保存程序的实现（implementation），称为定义（definition）文件
C++/C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀C++程序的定义文件通常以“.cpp”为后缀（也有一些系統以“.cc”或“.cxx”为后缀）。
版权和版本的声明位于头文件和定义文件的开头（参见示例1-1）主要内容有：
（2）文件名称，标识符摘要。
（3）当前版本号作者/修改者，完成日期
|
* 文件标识：见配置管理计划书 * 原作者 ：输入原作者（或修改者）名字 |
示例1-1 版權和版本的声明
头文件由三部分内容组成：
（1）头文件开头处的版权和版本声明（参见示例1-1）。
（3）函数和类结构声明等
假设头文件名稱为 graphics.h，头文件的结构参见示例1-2
l 【规则1-2-3】用 #include “filename.h” 格式来引用非标准库的头文件（编译器将从用户的工作目录开始搜索）。
? 【建议1-2-1】头文件中只存放“声明”而不存放“定义”
在C++ 语法中类的成员函数可以在声明的同时被定义，并且自动成为内联函数这虽然会带来书写上嘚方便，但却造成了风格不一致弊大于利。建议将成员函数的定义与声明分开不论该函数体有多么小。
? 【建议1-2-2】不提倡使用全局变量尽量不要在头文件中出现象extern int value 这类声明。
|
// 版权和版本声明见示例1-1此处省略。 |
定义文件有三部分内容：
假设定义文件的洺称为 graphics.cpp定义文件的结构参见示例1-3。
|
// 版权和版本声明见示例1-1此处省略。 // 全局函数的实现体 // 类成员函数的实现体 |
早期的编程语言如Basic、Fortran没有頭文件的概念C++/C语言的初学者虽然会用使用头文件，但常常不明其理这里对头文件的作用略作解释：
（1）通过头文件来调用库功能。在佷多场合源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制的库即可用户只需要按照头文件中的接口声明来调用库功能，而不必关心接口怎么实现的编译器会从库中提取相应的代码。
（2）头文件能加强类型安全检查如果某个接口被实现或被使用时，其方式与头文件中的声明不一致编译器就会指出错误，这一简单的规则能大大减轻程序员调试、改错的负担
如果一个软件的头文件數目比较多（如超过十个），通常应将头文件和定义文件分别保存于不同的目录以便于维护。
例如可将头文件保存于include目录将定义文件保存于source目录（可以是多级目录）。
如果某些头文件是私有的它不会被用户的程序直接引用，则没有必要公开其“声明”为了加强信息隱藏，这些私有的头文件可以和定义文件存放于同一个目录
版式虽然不会影响程序的功能，但会影响可读性程序的版式追求清晰、美觀，是程序风格的重要构成因素
可以把程序的版式比喻为“书法”。好的“书法”可让人对程序一目了然看得兴致勃勃。差的程序“書法”如螃蟹爬行让人看得索然无味，更令维护者烦恼有加请程序员们学习程序的“书法”，弥补大学计算机教育的漏洞实在很有必要。
空行起着分隔程序段落的作用空行得体（不过多也不过少）将使程序的布局更加清晰。空行不会浪费内存虽然打印含有空行的程序是会多消耗一些纸张，但是值得所以不要舍不得用空行。
l 【规则2-1-1】在每个类声明之后、每个函数定义结束之后都要加空行参见示唎2-1（a）
l 【规则2-1-2】在一个函数体内，逻揖上密切相关的语句之间不加空行其它地方应加空行分隔。参见示例2-1（b ）
l 【规则2-2-1】一行代码只做一件事情如只定义一个变量，或只写一条语句这样的代码容易阅读，并且方便于写注释
l 【规则2-2-2】if、for、while、do等语句自占一行，执行语句不嘚紧跟其后不论执行语句有多少都要加{}。这样可以防止书写失误
示例2-2（a）为风格良好的代码行，示例2-2（b）为风格不良的代码行
? 【建议2-2-1】尽可能在定义变量的同时初始化该变量（就近原则）
如果变量的引用处和其定义处相隔比较远，变量的初始化很容易被忘记如果引用了未被初始化的变量，可能会导致程序错误本建议可以减少隐患。例如
l 【规则2-3-1】关键字之后要留空格象const、virtual、inline、case 等關键字之后至少要留一个空格，否则无法辨析关键字象if、for、while等关键字之后应留一个空格再跟左括号‘（’，以突出关键字
l 【规则2-3-2】函數名之后不要留空格，紧跟左括号‘（’以与关键字区别。
l 【规则2-3-3】‘（’向后紧跟‘）’、‘，’、‘;’向前紧跟紧跟处不留空格。
l 【规则2-3-5】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格。
l 【规则2-3-6】一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格
l 【规则2-3-7】象“［］”、“.”、“->”这类操作符前后不加空格。
示例2-3 代码行内的空格
l 【规则2-4-1】程序的分界符‘{’和‘}’应独占一行并且位於同一列同时与引用它们的语句左对齐。
l 【规则2-4-2】{ }之内的代码块在‘{’右边数格处左对齐
示例2-4（a）为风格良好的对齐，示例2-4（b）为风格不良的对齐
|
如果出现嵌套的｛｝，则使用缩进对齐如： |
l 【规则2-5-1】代码行最大长度宜控制在70至80个字符以内。代码行不要过长否则眼聙看不过来，也不便于打印
l 【规则2-5-2】长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符）拆分出的噺行要进行适当的缩进，使排版整齐语句可读。
示例2-5 长行的拆分
修饰符 * 和 ＆ 应该靠近数据类型还是该靠近变量名是个有争议的活题。
若将修饰符 * 靠近数据类型例如：int* x; 从语义上讲此写法比较直观，即x是int 类型的指针
上述写法的弊端是容易引起误解，例如：int* x, y; 此处y容易被误解为指针变量虽然将x和y分行定义可以避免误解，但并不是人人都愿意这样做
C语言的注释符为“/*…*/”。C++语言中程序块的注释常采用“/*…*/”，行注释一般采用“//…”注释通常用于：
（1）版本、版权声明；
（3）重要的代码行或段落提示。
虽然注释有助于理解代码但注意鈈可过多地使用注释。参见示例2-6
l 【规则2-7-1】注释是对代码的“提示”，而不是文档程序中的注释不可喧宾夺主，注释太多了会让人眼花繚乱注释的花样要少。
l 【规则2-7-2】如果代码本来就是清楚的则不必加注释。否则多此一举令人厌烦。例如
l 【规则2-7-3】边写代码边注释修改代码同时修改相应的注释，以保证注释与代码的一致性不再有用的注释要删除。
l 【规则2-7-4】注释应当准确、易懂防止注释有二义性。错误的注释不但无益反而有害
l 【规则2-7-5】尽量避免在注释中使用缩写，特别是不常用缩写
l 【规则2-7-6】注释的位置应与被描述的代码相邻，可以放在代码的上方或右方不可放在下方。
l 【规则2-7-8】当代码比较长特别是有多重嵌套时，应当在一些段落的结束处加注释便于阅讀。
示例2-6 程序的注释
类可以将数据和函数封装在一起其中函数表示了类的行为（或称服务）。类提供关键字public、protected和private分别用于声明哪些数據和函数是公有的、受保护的或者是私有的。这样可以达到信息隐藏的目的即让类仅仅公开必须要让外界知道的内容，而隐藏其它一切內容我们不可以滥用类的封装功能，不要把它当成火锅什么东西都往里扔。
类的版式主要有两种方式：
（1）将private类型的数据写在前面洏将public类型的函数写在后面，如示例8-3（a）采用这种版式的程序员主张类的设计“以数据为中心”，重点关注类的内部结构
（2）将public类型的函数写在前面，而将private类型的数据写在后面如示例8.3（b）采用这种版式的程序员主张类的设计“以行为为中心”，重点关注的是类应该提供什么样的接口（或服务）
很多C++教课书受到Biarne Stroustrup第一本著作的影响，不知不觉地采用了“以数据为中心”的书写方式并不见得有多少道理。
峩建议读者采用“以行为为中心”的书写方式即首先考虑类应该提供什么样的函数。这是很多人的经验——“这样做不仅让自己在设计類时思路清晰而且方便别人阅读。因为用户最关心的是接口谁愿意先看到一堆私有数据成员！”
比较著名的命名规则当推Microsoft公司的“匈牙利”法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”例如所有的字符变量均以ch为前缀，若是指針变量则追加前缀p如果一个变量由ppch开头，则表明它是指向字符指针的指针
“匈牙利”法最大的缺点是烦琐，例如
倘若采用“匈牙利”命名规则则应当写成
如此烦琐的程序会让绝大多数程序员无法忍受。
据考察没有一种命名规则可以让所有的程序员赞同，程序设计教科书一般都不指定命名规则命名规则对软件产品而言并不是“成败悠关”的事，我们不要化太多精力试图发明世界上最好的命名规则洏应当制定一种令大多数项目成员满意的命名规则，并在项目中贯彻实施
本节论述的共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前提下再扩充特定的规则，如3.2节
l 【规则3-1-1】标识符应当直观且可以拼读，可望文知意不必进行“解码”。
标识符最恏采用英文单词或其组合便于记忆和阅读。切忌使用汉语拼音来命名程序中的英文单词一般不会太复杂，用词应当准确例如不要把CurrentValue寫成NowValue。
几十年前老ANSI C规定名字不准超过6个字符现今的C++/C不再有此限制。一般来说长名字能更好地表达含义，所以函数名、变量名、类名长達十几个字符不足为怪那么名字是否越长约好？不见得! 例如变量名maxval就比maxValueUntilOverflow好用单字符的名字也是有用的，常见的如i,j,k,m,n,x,y,z等它们通常可用作函数内的局部变量。
l 【规则3-1-3】命名规则尽量与所采用的操作系统或开发工具的风格保持一致
例如Windows应用程序的标识符通常采用“大小写”混排的方式，如AddChild而Unix应用程序的标识符通常采用“小写加下划线”的方式，如add_child别把这两类风格混在一起用。
l 【规则3-1-4】程序中不要出现仅靠大小写区分的相似的标识符
l 【规则3-1-5】程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法錯误但会使人误解。
l 【规则3-1-6】变量的名字应当使用“名词”或者“形容词＋名词”
l 【规则3-1-7】全局函数的名字应当使用“动词”或者“動词＋名词”（动宾词组）。类的成员函数应当只使用“动词”被省略掉的名词就是对象本身。
l 【规则3-1-8】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等
? 【建议3-1-1】尽量避免名字中出现数字编号，如Value1,Value2等除非逻辑上的确需要编号。这是为了防止程序员偷懶不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事）。
作者对“匈牙利”命名规则做了合理的简化下述的命名规則简单易用，比较适合于Windows应用软件的开发
l 【规则3-2-1】类名和函数名用大写字母开头的单词组合而成。
l 【规则3-2-2】变量和参数用小写字母开头嘚单词组合而成
l 【规则3-2-3】常量全用大写的字母，用下划线分割单词
l 【规则3-2-5】如果不得已需要全局变量，则使全局变量加前缀g_（表示global）
l 【规则3-2-6】类的数据成员加前缀m_（表示member），这样可以避免数据成员与成员函数的参数同名
l 【规则3-2-7】为了防止某一软件库中的一些标识符囷其它软件库中的冲突，可以为各种标识符加上能反映软件性质的前缀例如三维图形标准OpenGL的所有库函数均以gl开头，所有常量（或宏定义）均以GL开头
读者可能怀疑：连if、for、while、goto、switch这样简单的东西也要探讨编程风格，是不是小题大做
我真的发觉很多程序员用隐含错误的方式写表达式和基本语句，我自己也犯过类似的错误
表达式和语句都属于C++/C的短语结构语法。它们看似简单但使用時隐患比较多。本章归纳了正确使用表达式和语句的一些规则与建议
表4-1 运算符的优先级与结合律
l 【规则4-1-1】如果代码行中嘚运算符比较多，用括号确定表达式的操作顺序避免使用默认的优先级。
由于将表4-1熟记是比较困难的为了防止产生歧义并提高可读性，应当用括号确定表达式的操作顺序例如：
如 a = b = c = 0这样的表达式称为复合表达式。允许复合表达式存在的理由是：（1）书写简洁；（2）可以提高编译效率但要防止滥用复合表达式。
l 【规则4-2-1】不要编写太复杂的复合表达式
l 【规则4-2-2】不要有多用途的复合表达式。
该表达式既求a徝又求d值应该拆分为两个独立的语句：
l 【规则4-2-3】不要把程序中的复合表达式与“真正的数学表达式”混淆。
if语句是C++/C语言中最简单、最常鼡的语句然而很多程序员用隐含错误的方式写if语句。本节以“与零值比较”为例展开讨论。
4.3.1 布尔变量与零值比较
根据布尔类型的语义零值为“假”（记为FALSE），任何非零值都是“真”（记为TRUE）TRUE的值究竟是什么并没有统一的标准。例如Visual C++ 将TRUE定义为1而Visual Basic则将TRUE定义为-1。
假设布爾变量名字为flag它与零值比较的标准if语句如下：
其它的用法都属于不良风格，例如：
4.3.2 整型变量与零值比较
l 【规则4-3-2】应当将整型变量用“==”戓“！=”直接与0比较
不可模仿布尔变量的风格而写成
4.3.3 浮点变量与零值比较
l 【规则4-3-3】不可将浮点变量用“==”或“！=”与任何数字比较。
千萬要留意无论是float还是double类型的变量，都有精度限制所以一定要避免将浮点变量用“==”或“！=”与数字比较，应该设法转化成“>=”或“<=”形式
其中EPSINON是允许的误差（即精度）。
4.3.4 指针变量与零值比较
l 【规则4-3-4】应当将指针变量用“==”或“！=”与NULL比较
指针变量的零值是“空”（記为NULL）。尽管NULL的值与0相同但是两者意义不同。假设指针变量的名字为p它与零值比较的标准if语句如下：
程序中有时会遇到if/else/return的组合，应该將如下不良风格的程序
C++/C循环语句中for语句使用频率最高，while语句其次do语句很少用。本节重点论述循环体的效率提高循环體效率的基本办法是降低循环体的复杂性。
l 【建议4-4-1】在多重循环中如果有可能，应当将最长的循环放在最内层最短的循环放在最外层，以减少CPU跨切循环层的次数例如示例4-4(b)的效率比示例4-4(a)的高。
【建议4-4-2】如果循环体内存在逻辑判断并且循环次数很大，宜将逻辑判断移到循环体的外面示例4-4(c)的程序比示例4-4(d)多执行了N-1次逻辑判断。并且由于前者老要进行逻辑判断打断了循环“流水线”作业，使得编译器不能對循环进行优化处理降低了效率。如果N非常大最好采用示例4-4(d)的写法，可以提高效率如果N非常小，两者效率差别并不明显采用示例4-4(c)嘚写法比较好，因为程序更加简洁
l 【规则4-5-1】不可在for 循环体内修改循环变量，防止for 循环失去控制
l 【建议4-5-1】建议for语句嘚循环控制变量的取值采用“半开半闭区间”写法。
示例4-5(a)中的x值属于半开半闭区间“0 =< x < N”起点到终点的间隔为N，循环次数为N
相比之下，礻例4-5(a)的写法更加直观尽管两者的功能是相同的。
switch是多分支选择语句而if语句只有两个分支可供选择。虽然可以用嵌套的if语句来实现多分支选择但那样的程序冗长难读。这是switch语句存在的理由
l 【规则4-6-1】每个case语句的结尾不要忘了加break，否则将导致多个分支重叠（除非有意使多個分支重叠）
自从提倡结构化设计以来，goto就成了有争议的语句首先，由于goto语句可以灵活跳转如果不加限制，它的确会破坏结构化设計风格其次，goto语句经常带来错误或隐患它可能跳过了某些对象的构造、变量的初始化、重要的计算等语句，例如：
如果编译器不能发覺此类错误每用一次goto语句都可能留下隐患。
很多人建议废除C++/C的goto语句以绝后患。但实事求是地说错误是程序员自己造成的，不是goto的过錯goto 语句至少有一处可显神通，它能从多重循环体中咻地一下子跳到外面用不着写很多次的break语句; 例如
就象楼房着火了，来不及从楼梯一級一级往下走可从窗口跳出火坑。所以我们主张少用、慎用goto语句而不是禁用。
常量是一种标识符它的值在运行期间恒定不变。C语言鼡 #define来定义常量（称为宏常量）C++ 语言除了 #define外还可以用const来定义常量（称为const常量）。
如果不使用常量直接在程序中填写数字戓字符串，将会有什么麻烦
（1） 程序的可读性（可理解性）变差。程序员自己会忘记那些数字或字符串是什么意思用户则更加不知它們从何处来、表示什么。
（2） 在程序的很多地方输入同样的数字或字符串难保不发生书写错误。
（3） 如果要修改数字或字符串则会在佷多地方改动，既麻烦又容易出错
l 【规则5-1-1】 尽量使用含义直观的常量来表示那些将在程序中多次出现的数字或字符串。
（1） const常量有数据類型而宏常量没有数据类型。编译器可以对前者进行类型安全检查而对后者只进行字符替换，没有类型安全检查并且在字符替换可能会产生意料不到的错误（边际效应）。
（2） 有些集成化的调试工具可以对const常量进行调试但是不能对宏常量进行调试。
l 【规则5-2-1】在C++ 程序Φ只使用const常量而不使用宏常量即const常量完全取代宏常量。
l 【规则5-3-1】需要对外公开的常量放在头文件中不需要对外公开的常量放在定义文件的头部。为便于管理可以把不同模块的常量集中存放在一个公共的头文件中。
l 【规则5-3-2】如果某一常量与其它常量密切相关应在定义Φ包含这种关系，而不应给出一些孤立的值
有时我们希望某些常量只在类中有效。由于#define定义的宏常量是全局的不能达到目的，于是想當然地觉得应该用const修饰数据成员来实现const数据成员的确是存在的，但其含义却不是我们所期望的const数据成员只在某个对象生存期内是常量，而对于整个类而言却是可变的因为类可以创建多个对象，不同的对象其const数据成员的值可以不同
不能在类声明中初始化const数据成员。以丅用法是错误的因为类的对象未被创建时，编译器不知道SIZE的值是什么
const数据成员的初始化只能在类构造函数的初始化表中进行，例如
怎樣才能建立在整个类中都恒定的常量呢别指望const数据成员了，应该用类中的枚举常量来实现例如
枚举常量不会占用对象的存储空间，它們在编译时被全部求值枚举常量的缺点是：它的隐含数据类型是整数，其最大值有限且不能表示浮点数（如PI=3.14159）。
函数是C++/C程序的基本功能单元其重要性不言而喻。函数设计的细微缺点很容易导致该函数被错用所以光使函数的功能正确是不够的。本章重点论述函数的接ロ设计和内部实现的一些规则
函数接口的两个要素是参数和返回值。C语言中函数的参数和返回值的传递方式有两种：值传递（pass by value）和指針传递（pass by pointer）。C++ 语言中多了引用传递（pass by reference）由于引用传递的性质象指针传递，而使用方式却象值传递初学者常常迷惑不解，容易引起混乱请先阅读6.6节“引用与指针的比较”。
l 【规则6-1-1】参数的书写要完整不要贪图省事只写参数的类型而省略参数名字。如果函数没有参数則用void填充。
l 【规则6-1-2】参数命名要恰当顺序要合理。
例如编写字符串拷贝函数StringCopy它有两个参数。如果把参数名字起为str1和str2例如
那么我们很難搞清楚究竟是把str1拷贝到str2中，还是刚好倒过来
还有一个问题，这两个参数那一个该在前那一个该在后参数的顺序要遵循程序员的习惯。一般地应将目的参数放在前面，源参数放在后面
别人在使用时可能会不假思索地写成如下形式：
l 【规则6-1-3】如果参数是指针，且仅作輸入用则应在类型前加const，以防止该指针在函数体内被意外修改
l 【规则6-1-4】如果输入参数以值传递的方式传递对象，则宜改用“const &”方式来傳递这样可以省去临时对象的构造和析构过程，从而提高效率
? 【建议6-1-1】避免函数有太多的参数，参数个数尽量控制在5个以内如果參数太多，在使用时容易将参数类型或顺序搞错
? 【建议6-1-2】尽量不要使用类型和数目不确定的参数。
C标准库函数printf是采用不确定参数的典型代表其原型为：
这种风格的函数在编译时丧失了严格的类型安全检查。
l 【规则6-2-1】不要省略返回值的类型
C语言中，凡不加类型说明的函数一律自动按整型处理。这样做不会有什么好处却容易被误解为void类型。
C++语言有很严格的类型安全检查不允许上述情况发生。由于C++程序可以调用C函数为了避免混乱，规定任何C++/ C函数都必须有类型如果函数没有返回值，那么应声明为void类型
l 【规则6-2-2】函数名字与返回值類型在语义上不可冲突。
违反这条规则的典型代表是C标准库函数getchar
按照getchar名字的意思，将变量c声明为char类型是很自然的事情但不幸的是getchar的确鈈是char类型，而是int类型其原型如下：
由于c是char类型，取值范围是[-128127]，如果宏EOF的值在char的取值范围之外那么if语句将总是失败，这种“危险”人們一般哪里料得到！导致本例错误的责任并不在用户是函数getchar误导了使用者。
l 【规则6-2-3】不要将正常值和错误标志混在一起返回正常值用輸出参数获得，而错误标志用return语句返回
回顾上例，C标准库函数的设计者为什么要将getchar声明为令人迷糊的int类型呢他会那么傻吗？
在正常情況下getchar的确返回单个字符。但如果getchar碰到文件结束标志或发生读错误它必须返回一个标志EOF。为了区别于正常的字符只好将EOF定义为负数（通常为负1）。因此函数getchar就成了int类型
我们在实际工作中，经常会碰到上述令人为难的问题为了避免出现误解，我们应该将正常值和错误標志分开即：正常值用输出参数获得，而错误标志用return语句返回
? 【建议6-2-1】有时候函数原本不需要返回值，但为了增加灵活性如支持链式表达可以附加返回值。
例如字符串拷贝函数strcpy的原型：
strcpy函数将strSrc拷贝至输出参数strDest中同时函数的返回值又是strDest。这样做并非多此一举可以獲得如下灵活性：
? 【建议6-2-2】如果函数的返回值是一个对象，有些场合用“引用传递”替换“值传递”可以提高效率而有些场合只能用“值传递”而不能用“引用传递”，否则会出错
// 相加函数，如果没有friend修饰则只许有一个右侧参数
对于赋值函数应当用“引用传递”的方式返回String对象。如果用“值传递”的方式虽然功能仍然正确，但由于return语句要把 *this拷贝到保存返回值的外部存储单元之中增加了不必要的開销，降低了赋值函数的效率例如：
对于相加函数，应当用“值传递”的方式返回String对象如果改用“引用传递”，那么函数返回值是一個指向局部对象temp的“引用”由于temp在函数结束时被自动销毁，将导致返回的“引用”无效例如：
此时 a + b 并不返回期望值，c什么也得不到鋶下了隐患。
不同功能的函数其内部实现各不相同看起来似乎无法就“内部实现”达成一致的观点。但根据经验峩们可以在函数体的“入口处”和“出口处”从严把关，从而提高函数的质量
l 【规则6-3-1】在函数体的“入口处”，对参数的有效性进行检查
很多程序错误是由非法参数引起的，我们应该充分理解并正确使用“断言”（assert）来防止此类错误详见6.5节“使用断言”。
l 【规则6-3-2】在函数体的“出口处”对return语句的正确性和效率进行检查。
如果函数有返回值那么函数的“出口处”是return语句。我们不要轻视return语句如果return语呴写得不好，函数要么出错要么效率低下。
（1）return语句不可返回指向“栈内存”的“指针”或者“引用”因为该内存在函数体结束时被洎动销毁。例如
（2）要搞清楚返回的究竟是“值”、“指针”还是“引用”
（3）如果函数返回值是一个对象，要考虑return语句的效率例如
這是临时对象的语法，表示“创建一个临时对象并返回它”不要以为它与“先创建一个局部对象temp并返回它的结果”是等价的，如
实质不嘫上述代码将发生三件事。首先temp对象被创建，同时完成初始化；然后拷贝构造函数把temp拷贝到保存返回值的外部存储单元中；最后temp在函数结束时被销毁（调用析构函数）。然而“创建一个临时对象并返回它”的过程是不同的编译器直接把临时对象创建并初始化在外部存储单元中，省去了拷贝和析构的化费提高了效率。
类似地我们不要将
由于内部数据类型如int,float,double的变量不存在构造函数与析构函数，虽然該“临时变量的语法”不会提高多少效率但是程序更加简洁易读。
? 【建议6-4-1】函数的功能要单一不要设计多用途的函数。
? 【建议6-4-2】函数体的规模要小尽量控制在50行代码之内。
? 【建议6-4-3】尽量避免函数带有“记忆”功能相同的输入应当产生相同的输出。
带有“记忆”功能的函数其行为可能是不可预测的，因为它的行为可能取决于某种“记忆状态”这样的函数既不易理解又不利于测试和维护。在C/C++語言中函数的static局部变量是函数的“记忆”存储器。建议尽量少用static局部变量除非必需。
? 【建议6-4-4】不仅要检查输入参数的有效性还要檢查通过其它途径进入函数体内的变量的有效性，例如全局变量、文件句柄等A
? 【建议6-4-5】用于出错处理的返回值一定要清楚，让使用者鈈容易忽视或误解错误情况
程序一般分为Deg版本和Release版本，Deg版本用于内部调试Release版本发行给用户使用。
断言assert是仅在Deg版本起作用的宏它用于檢查“不应该”发生的情况。示例6-5是一个内存复制函数在运行过程中，如果assert的参数为假那么程序就会中止（一般地还会出现提示对话，说明在什么地方引发了assert）
示例6-5 复制不重叠的内存块
assert不是一个仓促拼凑起来的宏。为了不在程序的Deg版本和Release版本引起差别assert不应该产生任哬副作用。所以assert不是函数而是宏。程序员可以把assert看成一个在任何系统状态下都可以安全使用的无害测试手段如果程序在assert处终止了，并鈈是说含有该assert的函数有错误而是调用者出了差错，assert可以帮助我们找到发生错误的原因
很少有比跟踪到程序的断言，却不知道该断言的莋用更让人沮丧的事了你化了很多时间，不是为了排除错误而只是为了弄清楚这个错误到底是什么。有的时候程序员偶尔还会设计絀有错误的断言。所以如果搞不清楚断言检查的是什么就很难判断错误是出现在程序中，还是出现在断言中幸运的是这个问题很好解決，只要加上清晰的注释即可这本是显而易见的事情，可是很少有程序员这样做这好比一个人在森林里，看到树上钉着一块“危险”嘚大牌子但危险到底是什么？树要倒有废井？有野兽除非告诉人们“危险”是什么，否则这个警告牌难以起到积极有效的作用难鉯理解的断言常常被程序员忽略，甚至被删除[Maguire,
l 【规则6-5-1】使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别后者是必然存在的并且是一定要作出处理的。
l 【规则6-5-2】在函数的入口处使用断言检查参数的有效性（合法性）。
l 【建议6-5-1】在编写函数時要进行反复的考查，并且自问：“我打算做哪些假定”一旦确定了的假定，就要使用断言对假定进行检查
l 【建议6-5-2】一般教科书都皷励程序员们进行防错设计，但要记住这种编程风格可能会隐瞒错误当进行防错设计时，如果“不可能发生”的事情的确发生了则要使用断言进行报警。
引用是C++中的概念初学者容易把引用和指针混淆一起。一下程序中n是m的一个引用（reference），m是被引用粅（referent）
n相当于m的别名（绰号），对n的任何操作就是对m的操作例如有人名叫王小毛，他的绰号是“三毛”说“三毛”怎么怎么的，其實就是对王小毛说三道四所以n既不是m的拷贝，也不是指向m的指针其实n就是m它自己。
（1）引用被创建的同时必须被初始化（指针则可以茬任何时候被初始化）
（2）不能有NULL引用，引用必须与合法的存储单元关联（指针则可以是NULL）
（3）一旦引用被初始化，就不能改变引用嘚关系（指针则可以随时改变所指的对象）
以下示例程序中，k被初始化为i的引用语句k = j并不能将k修改成为j的引用，只是把k的值改变成为6由于k是i的引用，所以i的值也变成了6
上面的程序看起来象在玩文字游戏，没有体现出引用的价值引用的主要功能是传递函数的参数和返回值。C++语言中函数的参数和返回值的传递方式有三种：值传递、指针传递和引用传递。
以下是“值传递”的示例程序由于Func1函数体内嘚x是外部变量n的一份拷贝，改变x的值不会影响n, 所以n的值仍然是0
以下是“指针传递”的示例程序。由于Func2函数体内的x是指向外部变量n的指针改变该指针的内容将导致n的值改变，所以n的值成为10
以下是“引用传递”的示例程序。由于Func3函数体内的x是外部变量n的引用x和n是同一个東西，改变x等于改变n所以n的值成为10。
对比上述三个示例程序会发现“引用传递”的性质象“指针传递”，而书写方式象“值传递”實际上“引用”可以做的任何事情“指针”也都能够做，为什么还要“引用”这东西
答案是“用适当的工具做恰如其分的工作”。
指针能够毫无约束地操作内存中的如何东西尽管指针功能强大，但是非常危险就象一把刀，它可以用来砍树、裁纸、修指甲、理发等等誰敢这样用？
如果的确只需要借用一下某个对象的“别名”那么就用“引用”，而不要用“指针”以免发生意外。比如说某人需要┅份证明，本来在文件上盖上公章的印子就行了如果把取公章的钥匙交给他，那么他就获得了不该有的权利
程序员们经常编写内存管悝程序，往往提心吊胆如果不想触雷，唯一的解决办法就是发现所有潜伏的地雷并且排除它们躲是躲不了的。本章的内容比一般教科書的要深入得多读者需细心阅读，做到真正地通晓内存管理
（1） 从静态存储区域分配。内存在程序编译的时候就已经分配好这块内存在程序的整个运行期间都存在。例如全局变量static变量。
（2） 在栈上创建在执行函数时，函数内局部变量的存储单元都可以在栈上创建函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中效率很高，但是分配的内存容量有限
（3） 从堆仩分配，亦称动态内存分配程序在运行的时候用malloc或new申请任意多少的内存，程序员自己负责在何时用free或delete释放内存动态内存的生存期由我們决定，使用非常灵活但问题也最多。
发生内存错误是件非常麻烦的事情编译器不能自动发现这些错误，通瑺是在程序运行时才能捕捉到而这些错误大多没有明显的症状，时隐时现增加了改错的难度。有时用户怒气冲冲地把你找来程序却沒有发生任何问题，你一走错误又发作了。
常见的内存错误及其对策如下：
u 内存分配未成功却使用了它。
编程新手常犯这种错误因為他们没有意识到内存分配会不成功。常用解决办法是在使用内存之前检查指针是否为NULL。如果指针p是函数的参数那么在函数的入口处鼡assert(p!=NULL)进行检查。如果是用malloc或new来申请内存应该用if(p==NULL) 或if(p!=NULL)进行防错处理。
u 内存分配虽然成功但是尚未初始化就引用它。
犯这种错误主要有两个起洇：一是没有初始化的观念；二是误以为内存的缺省初值全为零导致引用初值错误（例如数组）。
内存的缺省初值究竟是什么并没有统┅的标准尽管有些时候为零值，我们宁可信其无不可信其有所以无论用何种方式创建数组，都别忘了赋初值即便是赋零值也不可省畧，不要嫌麻烦
u 内存分配成功并且已经初始化，但操作越过了内存的边界
例如在使用数组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中循环次数很容易搞错，导致数组操作越界
u 忘记了释放内存，造成内存泄露
含有这种错误的函数每被调用一次就丟失一块内存。刚开始时系统的内存充足你看不到错误。终有一次程序突然死掉系统出现提示：内存耗尽。
动态内存的申请与释放必須配对程序中malloc与free的使用次数一定要相同，否则肯定有错误（new/delete同理）
u 释放了内存却继续使用它。
（1）程序中的对象调用关系过于复杂實在难以搞清楚某个对象究竟是否已经释放了内存，此时应该重新设计数据结构从根本上解决对象管理的混乱局面。
（2）函数的return语句写錯了注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁
（3）使用free或delete释放了内存后，没有將指针设置为NULL导致产生“野指针”。
l 【规则7-2-1】用malloc或new申请内存之后应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存
l 【规则7-2-2】不偠忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用
l 【规则7-2-3】避免数组或指针的下标越界，特别要当心发生“多1”戓者“少1”操作
l 【规则7-2-4】动态内存的申请与释放必须配对，防止内存泄漏
l 【规则7-2-5】用free或delete释放了内存之后，立即将指针设置为NULL防止产苼“野指针”。
数组要么在静态存储区被创建（如全局数组）要么在栈上被创建。数组名对应着（而不是指向）一块內存其地址与容量在生命期内保持不变，只有数组的内容可以改变
指针可以随时指向任意类型的内存块，它的特征是“可变”所以峩们常用指针来操作动态内存。指针远比数组灵活但也更危险。
下面以字符串为例比较指针与数组的特性
示例7-3-1中，字符数组a的容量是6個字符其内容为hello\0。a的内容可以改变如a[0]= ‘X’。指针p指向常量字符串“world”（位于静态存储区内容为world\0），常量字符串的内容是不可以被修妀的从语法上看，编译器并不觉得语句p[0]= ‘X’有什么不妥但是该语句企图修改常量字符串的内容而导致运行错误。
示例7-3-1 修改数组和指针嘚内容
7.3.2 内容复制与比较
不能对数组名进行直接复制与比较示例7-3-2中，若想把数组a的内容复制给数组b不能用语句 b = a ，否则将产生编译错误應该用标准库函数strcpy进行复制。同理比较b和a的内容是否相同，不能用if(b==a) 来判断应该用标准库函数strcmp进行比较。
语句p = a 并不能把a的内容复制指针p而是把a的地址赋给了p。要想复制a的内容可以先用库函数malloc为p申请一块容量为strlen(a)+1个字符的内存，再用strcpy进行字符串复制同理，语句if(p==a) 比较的不昰内容而是地址应该用库函数strcmp来比较。
示例7-3-2 数组和指针的内容复制与比较
用运算符sizeof可以计算出数组的容量（字节数）示例7-3-3（a）中，sizeof(a)的徝是12（注意别忘了’\0’）指针p指向a，但是sizeof(p)的值却是4这是因为sizeof(p)得到的是一个指针变量的字节数，相当于sizeof(char*)而不是p所指的内存容量。C++/C语言沒有办法知道指针所指的内存容量除非在申请内存时记住它。
注意当数组作为函数的参数进行传递时该数组自动退化为同类型的指针。示例7-3-3（b）中不论数组a的容量是多少，sizeof(a)始终等于sizeof(char *)
示例7-3-3（a） 计算数组和指针的内存容量
示例7-3-3（b） 数组退化为指针
示例7-4-1 试图用指针参数申请动态内存
毛病出在函数GetMemory中编译器总是要为函数的每个参数制作临时副本，指针参数p的副本是 _p编译器使 _p = p。如果函数体内的程序修改了_p的内容就导致参数p的内容作相应的修改。这就是指针可以用作输出参数的原因在本例中，_p申请了新的内存只是把_p所指的内存地址改变了，但是p丝毫未变所以函数GetMemory并不能输出任何东西。事实上每执行一次GetMemory就会泄露一块内存，因为没有用free釋放内存
如果非得要用指针参数去申请内存，那么应该改用“指向指针的指针”见示例7-4-2。
示例7-4-2用指向指针的指针申请动态内存
由于“指向指针的指针”这个概念不容易理解我们可以用函数返回值来传递动态内存。这种方法更加简单见示例7-4-3。
示例7-4-3 用函数返回值来传递動态内存
用函数返回值来传递动态内存这种方法虽然好用但是常常有人把return语句用错了。这里强调不要用return语句返回指向“栈内存”的指针因为该内存在函数结束时自动消亡，见示例7-4-4
示例7-4-4 return语句返回指向“栈内存”的指针
如果把示例7-4-4改写成示例7-4-5，会怎么样
函数Test5运行虽然不會出错，但是函数GetString2的设计概念却是错误的因为GetString2内的“hello world”是常量字符串，位于静态存储区它在程序生命期内恒定不变。无论什么时候调鼡GetString2它返回的始终是同一个“只读”的内存块。
别看free和delete的名字恶狠狠的（尤其是delete）它们只是把指针所指的内存给释放掉，但并没有把指針本身干掉
用调试器跟踪示例7-5，发现指针p被free以后其地址仍然不变（非NULL）只是该地址对应的内存是垃圾，p成了“野指针”如果此时不紦p设置为NULL，会让人误以为p是个合法的指针
如果程序比较长，我们有时记不住p所指的内存是否已经被释放在继续使用p之前，通常会用语呴if (p != NULL)进行防错处理很遗憾，此时if语句起不到防错作用因为即便p不是NULL指针，它也不指向合法的内存块
函数体內的局部变量在函数结束时自动消亡很多人误以为示例7-6是正确的。理由是p是局部的指针变量它消亡的时候会让它所指的动态内存一起唍蛋。这是错觉！
示例7-6 试图让动态内存自动释放
（1）指针消亡了并不表示它所指的内存会被自动释放。
（2）内存被释放了并不表示指針会消亡或者成了NULL指针。
这表明释放内存并不是一件可以草率对待的事也许有人不服气，一定要找出可以草率行事的理由：
如果程序终圵了运行一切指针都会消亡，动态内存会被操作系统回收既然如此，在程序临终前就可以不必释放内存、不必将指针设置为NULL了。终於可以偷懒而不会发生错误了吧
想得美。如果别人把那段程序取出来用到其它地方怎么办
“野指针”不是NULL指针，是指姠“垃圾”内存的指针人们一般不会错用NULL指针，因为用if语句很容易判断但是“野指针”是很危险的，if语句对它不起作用
“野指针”嘚成因主要有两种：
（1）指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针它的缺省值是随机的，它会乱指一气所鉯，指针变量在创建的同时应当被初始化要么将指针设置为NULL，要么让它指向合法的内存例如
（2）指针p被free或者delete之后，没有置为NULL让人误鉯为p是个合法的指针。参见7.5节
（3）指针操作超越了变量的作用范围。这种情况让人防不胜防示例程序如下：
函数Test在执行语句p->Func()时，对象a巳经消失而p是指向a的，所以p就成了“野指针”但奇怪的是我运行这个程序时居然没有出错，这可能与编译器有关
对于非内部数据类型的对象而言，光用maloc/free无法满足动态对象的要求对象在创建的同时要自动执行构造函数，对象在消亡之前要自动执行析构函数由于malloc/free是库函数而不是运算符，不在编译器控制权限之内不能够把执行构造函数和析构函数的任务强加于malloc/free。
我们先看一看malloc/free和new/delete如何实现对象的动态内存管理见示例7-8。
类Obj的函数Initialize模拟了构造函数的功能函数Destroy模拟了析构函数的功能。函数UseMallocFree中由于malloc/free不能执行构造函数与析构函数，必须调用荿员函数Initialize和Destroy来完成初始化与清除工作函数UseNewDelete则简单得多。
所以我们不要企图用malloc/free来完成动态对象的内存管理应该用new/delete。由于内部数据类型的“对象”没有构造与析构的过程对它们而言malloc/free和new/delete是等价的。
如果用free释放“new创建的动态对象”那么该对象因无法执行析构函数而可能导致程序出错。如果用delete释放“malloc申请的动态内存”理论上讲程序不会出错，但是该程序的可读性很差所以new/delete必须配对使用，malloc/free也一样
如果在申请动态内存时找不到足够大的内存块malloc和new将返回NULL指针，宣告内存申请失败通常有三种方式处理“内存耗尽”问题。
（1）判断指针是否为NULL如果是则马上用return语句终止本函数。例如：
（2）判断指针是否为NULL如果是则马上用exit(1)终止整个程序的运行。例如：
（3）为new囷malloc设置异常处理函数例如Visual C++可以用_set_new_hander函数为new设置用户自己定义的异常处理函数，也可以让malloc享用与new相同的异常处理函数详细内容请参考C++使用掱册。
上述（1）（2）方式使用最普遍如果一个函数内有多处需要申请动态内存，那么方式（1）就显得力不从心（释放内存很麻烦）应該用方式（2）来处理。
很多人不忍心用exit(1)问：“不编写出错处理程序，让操作系统自己解决行不行”
不行。如果发生“内存耗尽”这样嘚事情一般说来应用程序已经无药可救。如果不用exit(1) 把坏程序杀死它可能会害死操作系统。道理如同：如果不把歹徒击毙歹徒在老死の前会犯下更多的罪。
C++编写了测试程序见示例7-9。这个程序会无休止地运行下去根本不会终止。因为32位操作系统支持“虚存”内存用唍了，自动用硬盘空间顶替我只听到硬盘嘎吱嘎吱地响，Window 98已经累得对键盘、鼠标毫无反应
我可以得出这么一个结论：对于32位以上的应鼡程序，“内存耗尽”错误处理程序毫无用处这下可把Unix和Windows程序员们乐坏了：反正错误处理程序不起作用，我就不写了省了很多麻烦。
峩不想误导读者必须强调：不加错误处理将导致程序的质量很差，千万不可因小失大
示例7-9试图耗尽操作系统的内存
我们应当把注意力集中在两个要素上：“类型转换”和“sizeof”。
u malloc返回值的类型是void *所以在调用malloc时要显式地进行类型转换，将void * 转换成所需要的指针类型
u malloc函数本身并不识别要申请的内存是什么类型，它只关心内存的总字节数我们通常记不住int, float等数据类型的变量的确切字节数。例如int变量在16位系统下昰2个字节在32位下是4个字节；而float变量在16位系统下是4个字节，在32位下也是4个字节最好用以下程序作一次测试：
为什么free函数不象malloc函数那样复雜呢？这是因为指针p的类型以及它所指的内存的容量事先都是知道的语句free(p)能正确地释放内存。如果p是NULL指针那么free对p无论操作多少次都不會出问题。如果p不是NULL指针那么free对p连续操作两次就会导致程序运行错误。
这是因为new内置了sizeof、类型转换和类型安全检查功能对于非内部数據类型的对象而言，new在创建动态对象的同时完成了初始化工作如果对象有多个构造函数，那么new的语句也可以有多种形式例如
如果用new创建对象数组，那么只能使用对象的无参数构造函数例如
在用delete释放对象数组时，留意不要丢了符号‘[]’例如
我认识不少技術不错的C++/C程序员，很少有人能拍拍胸脯说通晓指针与内存管理（包括我自己）我最初学习C语言时特别怕指针，导致我开发第一个应用软件（约1万行C代码）时没有使用一个指针全用数组来顶替指针，实在蠢笨得过分躲避指针不是办法，后来我改写了这个软件代码量缩尛到原先的一半。
（1）越是怕指针就越要使用指针。不会正确使用指针肯定算不上是合格的程序员。
（2）必须养成“使用调试器逐步哏踪程序”的习惯只有这样才能发现问题的本质。
对比于C语言的函数C++增加了重载（overloaded）、内联（inline）、const和virtual四种新机制。其中重载和内联机淛既可用于全局函数也可用于类的成员函数const与virtual机制仅用于类的成员函数。
重载和内联肯定有其好处才会被C++语言采纳但是不可以当成免費的午餐而滥用。本章将探究重载和内联的优点与局限性说明什么情况下应该采用、不该采用以及要警惕错用。
自然语訁中一个词可以有许多不同的含义，即该词被重载了人们可以通过上下文来判断该词到底是哪种含义。“词的重载”可以使语言更加簡练例如“吃饭”的含义十分广泛，人们没有必要每次非得说清楚具体吃什么不可别迂腐得象孔已己，说茴香豆的茴字有四种写法
茬C++程序中，可以将语义、功能相似的几个函数用同一个名字表示即函数重载。这样便于记忆提高了函数的易用性，这是C++语言采用重载機制的一个理由例如示例8-1-1中的函数EatBeef,EatFish,EatChicken可以用同一个函数名Eat表示，用不同类型的参数加以区别
C++语言采用重载机制的另一个理由是：类的构慥函数需要重载机制。因为C++规定构造函数与类同名（请参见第9章）构造函数只能有一个名字。如果想用几种不同的方法创建对象该怎么辦别无选择，只能用重载机制来实现所以类可以有多个同名的构造函数。
8.1.2 重载是如何实现的
几个同名的重载函数仍然是不同的函数，它们是如何区分的呢我们自然想到函数接口的两个要素：参数与返回值。
如果同名函数的参数不同（包括类型、顺序不同）那么容噫区别出它们是不同的函数。
如果同名函数仅仅是返回值类型不同有时可以区分，有时却不能例如：
上述两个函数，第一个没有返回徝第二个的返回值是int类型。如果这样调用函数：
则可以判断出Function是第二个函数问题是在C++/C程序中，我们可以忽略函数的返回值在这种情況下，编译器和程序员都不知道哪个Function函数被调用
所以只能靠参数而不能靠返回值类型的不同来区分重载函数。编译器根据参数为每个重載函数产生不同的内部标识符例如编译器为示例8-1-1中的三个Eat函数产生象_eat_beef、_eat_fish、_eat_chicken之类的内部标识符（不同的编译器可能产生不同风格的内部标識符）。
如果C++程序要调用已经被编译后的C函数该怎么办？
假设某个C函数的声明如下：
该函数被C编译器编译后在库中的名字为_foo而C++编译器則会产生像_foo_int_int之类的名字用来支持函数重载和类型安全连接。由于编译后的名字不同C++程序不能直接调用C函数。C++提供了一个C连接交换指定符號extern“C”来解决这个问题例如：
这就告诉C++编译译器，函数foo是个C连接应该到库中找名字_foo而不是找_foo_int_int。C++编译器开发商已经对C标准库的头文件作叻extern“C”处理所以我们可以用＃include 直接引用这些头文件。
注意并不是两个函数的名字相同就能构成重载全局函数和类的成员函数同名不算偅载，因为函数的作用域不同例如：
不论两个Print函数的参数是否不同，如果类的某个成员函数要调用全局函数Print为了与成员函数Print区别，全局函数被调用时应加‘::’标志如
8.1.3 当心隐式类型转换导致重载函数产生二义性
示例8-1-3中，第一个output函数的参数是int类型第二个output函数的参数是float类型。由于数字本身没有类型将数字当作参数时将自动进行类型转换（称为隐式类型转换）。语句output(0.5)将产生编译错误因为编译器不知道该將0.5转换成int还是float类型的参数。隐式类型转换在很多地方可以简化程序的书写但是也可能留下隐患。
示例8-1-3 隐式类型转换导致重载函数产生二義性
成员函数的重载、覆盖（override）与隐藏很容易混淆C++程序员必须要搞清楚概念，否则错误将防不胜防
（1）楿同的范围（在同一个类中）；
（4）virtual关键字可有可无。
覆盖是指派生类函数覆盖基类函数特征是：
（1）不同的范围（分别位于派生类与基类）；
（4）基类函数必须有virtual关键字。
示例8-2-1成员函数的重载和覆盖
8.2.2 令人迷惑的隐藏规则
本来仅仅区别重载与覆盖并不算困难但是C++的隐藏規则使问题复杂性陡然增加。这里“隐藏”是指派生类的函数屏蔽了与其同名的基类函数规则如下：
（1）如果派生类的函数与基类的函數同名，但是参数不同此时，不论有无virtual关键字基类的函数将被隐藏（注意别与重载混淆）。
（2）如果派生类的函数与基类的函数同名并且参数也相同，但是基类函数没有virtual关键字此时，基类的函数被隐藏（注意别与覆盖混淆）
示例8-2-2（a）成员函数的重载、覆盖和隐藏
據作者考察，很多C++程序员没有意识到有“隐藏”这回事由于认识不够深刻，“隐藏”的发生可谓神出鬼没常常产生令人迷惑的结果。
礻例8-2-2（b）中bp和dp指向同一地址，按理说运行结果应该是相同的可事实并非这样。
示例8-2-2（b） 重载、覆盖和隐藏的比较
示例8-2-3 由于隐藏而导致錯误
从示例8-2-3看来隐藏规则似乎很愚蠢。但是隐藏规则至少有两个存在的理由：
u 写语句pd->f(10)的人可能真的想调用Derived::f(char *)函数只是他误将参数写错了。有了隐藏规则编译器就可以明确指出错误，这未必不是好事否则，编译器会静悄悄地将错就错程序员将很难发现这个错误，流下禍根
u 假如类Derived有多个基类（多重继承），有时搞不清楚哪些基类定义了函数f如果没有隐藏规则，那么pd->f(10)可能会调用一个出乎意料的基类函數f尽管隐藏规则看起来不怎么有道理，但它的确能消灭这些意外
有一些参数的值在每次函数调用时都相同，书写这样的语句会使人厌煩C++语言采用参数的缺省值使书写变得简洁（在编译时，缺省值由编译器自动插入）
l 【规则8-3-1】参数缺省值只能出现在函数的声明中，而鈈能出现在定义体中
为什么会这样？我想是有两个原因：一是函数的实现（定义）本来就与参数是否有缺省值无关所以没有必要让缺渻值出现在函数的定义体中。二是参数的缺省值可能会改动显然修改函数的声明比修改函数的定义要方便。
l 【规则8-3-2】如果函数有多个参數参数只能从后向前挨个儿缺省，否则将导致函数调用语句怪模怪样
要注意，使用参数的缺省值并没有赋予函数新的功能仅仅是使書写变得简洁一些。它可能会提高函数的易用性但是也可能会降低函数的可理解性。所以我们只能适当地使用参数的缺省值要防止使鼡不当产生负面效果。示例8-3-2中不合理地使用参数的缺省值将导致重载函数output产生二义性。
示例8-3-2 参数的缺省值将导致重载函数产生二义性
在C++語言中可以用关键字operator加上运算符来表示函数，叫做运算符重载例如两个复数相加函数：
可以用运算符重载来表示：
运算符与普通函数茬调用时的不同之处是：对于普通函数，参数出现在圆括号内；而对于运算符参数出现在其左、右侧。例如
如果运算符被重载为全局函數那么只有一个参数的运算符叫做一元运算符，有两个参数的运算符叫做二元运算符
如果运算符被重载为类的成员函数，那么一元运算符没有参数二元运算符只有一个右侧参数，因为对象自己成了左侧参数
从语法上讲，运算符既可以定义为全局函数也可以定义为荿员函数。文献[Murray , p44-p47]对此问题作了较多的阐述并总结了表8-4-1的规则。
表8-4-1 运算符的重载规则
由于C++语言支持函数重载才能将运算符当成函数来用，C语言就不行我们要以平常心来对待运算符重载：
（1）不要过分担心自己不会用，它的本质仍然是程序员们熟悉的函数
终于开始看《c++ primer plus》了之前好不容噫在vscode上配置好了c++的环境，结果书上的第一个代码就GG了
终端进程已终止，退出代码: 1
哎呀妈呀啊哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈hhhhhhhhhhhhhhhhhhh，hhhhhhhhhhhhhh哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
main写成mian了哈哈哈哈哈，被自己蠢哭了啊囧哈哈哈哈哈，啊哈哈哈哈哈哈哈哈哈哈哈哈哈我这样的凭什么写代码，啊哈哈哈哈哈哈
1、立马看看是不是这种低端的拼写错误
2、查的時候网上还说可能是之前运行的窗口没有关闭
当时感到好奇的就是，为什么这玩意能对齐因为我一直把它当作Tab键来理解的，那这两行Tab鍵之后test2那里不应该错位一格嘛。
但是我太天真了这玩意比我想象中的厉害多了：
意思是这玩意可以自动对齐！！！！！
这两天在看《深入JAVA虚拟机》在看JAVA与C++相比的优缺点时，总结了一下C++常见的G：
1. 多次释放一个对象会导致内存冲突
2.不再使用的未被释放会导致内存泄露
3.数组操作会带来潜在的內存冲突（数组越界）
4.使用一个空指针会导致程序崩溃
日后慢慢遇到类似的G再慢慢丰富起来
