高质量C与C指南林锐博士

上传人:仙*** 文档编号:111271542 上传时间:2022-06-20 格式:DOC 页数:87 大小:505KB
收藏 版权申诉 举报 下载
高质量C与C指南林锐博士_第1页
第1页 / 共87页
高质量C与C指南林锐博士_第2页
第2页 / 共87页
高质量C与C指南林锐博士_第3页
第3页 / 共87页
资源描述:

《高质量C与C指南林锐博士》由会员分享,可在线阅读,更多相关《高质量C与C指南林锐博士(87页珍藏版)》请在装配图网上搜索。

1、- Back to man.ChinaUni*.net 高质量C+/C编程指南文件状态 草稿文件 正式文件 更改正式文件文件标识:当前版本:1.0 林锐博士完成日期:2001年7月24日版本历史版本/状态作者参与者起止日期备注V 0.9草稿文件林锐2001-7-1至2001-7-18林锐起草V 1.0正式文件林锐2001-7-18至2001-7-24朱洪海审查V 0.9,林锐修正草稿中的错误目录前言6第1章文件构造111.1 和版本的声明111.2 头文件的构造121.3 定义文件的构造131.4 头文件的作用131.5 目录构造14第2章程序的版式152.1 空行152.2 代码行162.3

2、 代码行的空格172.4 对齐182.5 长行拆分192.6 修饰符的位置192.7 注释202.8 类的版式21第3章命名规则223.1 共性规则223.2 简单的WINDOWS应用程序命名规则233.3 简单的UNI*应用程序命名规则25第4章表达式和根本语句264.1 运算符的优先级264.2 复合表达式274.3 IF 语句274.4 循环语句的效率294.5 FOR 语句的循环控制变量304.6 SWITCH语句304.7 GOTO语句31第5章常量335.1 为什么需要常量335.2 CONST 与 #DEFINE的比拟335.3 常量定义规则335.4 类中的常量34第6章函数设

3、计366.1 参数的规则366.2 返回值的规则376.3 函数部实现的规则396.4 其它建议406.5 使用断言416.6 引用与指针的比拟42第7章存管理447.1存分配方式447.2常见的存错误及其对策447.3指针与数组的比照457.4指针参数是如何传递存的?477.5 FREE和DELETE把指针怎么啦?507.6 动态存会被自动释放吗?507.7 杜绝野指针517.8 有了MALLOC/FREE为什么还要NEW/DELETE ?527.9 存耗尽怎么办?537.10 MALLOC/FREE 的使用要点547.11 NEW/DELETE 的使用要点557.12 一些心得体会56第8

4、章 C+函数的高级特性578.1 函数重载的概念578.2 成员函数的重载、覆盖与隐藏608.3 参数的缺省值638.4 运算符重载648.5 函数联658.6 一些心得体会68第9章类的构造函数、析构函数与赋值函数699.1 构造函数与析构函数的起源699.2 构造函数的初始化表709.3 构造和析构的次序729.4 例如:类STRING的构造函数与析构函数729.5 不要轻视拷贝构造函数与赋值函数739.6 例如:类STRING的拷贝构造函数与赋值函数739.7 偷懒的方法处理拷贝构造函数与赋值函数759.8 如何在派生类中实现类的根本函数759.9 一些心得体会77第10章类的继承与组合

5、7810.1 继承7810.2 组合80第11章其它编程经历8211.1 使用CONST提高函数的强健性8211.2 提高程序的效率8411.3 一些有益的建议85参考文献87附录A :C+/C代码审查表88附录B :C+/C试题93附录C :C+/C试题的答案与评分标准97前言软件质量是被大多数程序员挂在嘴上而不是放在心上的东西!除了完全外行和真正的编程高手外,初读本书,你最先的感受将是惊慌:哇!我以前捏造的C+/C程序怎么会有则多的毛病?别难过,作者只不过比你早几年、多几次惊慌而已。请花一两个小时认真阅读这本百页经书,你将会获益匪浅,这是前面N-1个读者的建议。一、编程老手与高手的误区自从

6、计算机问世以来,程序设计就成了令人羡慕的职业,程序员在受人宠爱之后容易开展成为毛病特多却常能自我臭美的群体。如今在Internet上流传的真正的程序员据说是这样的:(1) (1)真正的程序员没有进度表,只有讨好领导的马屁精才有进度表,真正的程序员会让领导提心吊胆。(2) (2)真正的程序员不写使用说明书,用户应当自己去猜测程序的功能。(3) (3)真正的程序员几乎不写代码的注释,如果注释很难写,它理所当然也很难读。(4) (4)真正的程序员不画流程图,原始人和文盲才会干这事。(5) (5)真正的程序员不看参考手册,新手和胆小鬼才会看。(6) (6)真正的程序员不写文档也不需要文档,只有看不懂程

7、序的笨蛋才用文档。(7) (7)真正的程序员认为自己比用户更明白用户需要什么。(8) (8)真正的程序员不承受团队开发的理念,除非他自己是头头。(9) (9)真正的程序员的程序不会在第一次就正确运行,但是他们愿意守着机器进展假设干个30小时的调试改错。(10) (10)真正的程序员不会在上午9:00到下午5:00之间工作,如果你看到他在上午9:00工作,这说明他从昨晚一直干到现在。具备上述特征越多,越显得水平高,资格老。所以别奇怪,程序员的很多缺点竟然可以被当作优点来欣赏。就象在武侠小说中,那些独来独往、不受约束且带点邪气的高手最令人崇拜。我曾经也这样信奉,并且希望自己成为那样的真正的程序员,

8、结果没有得到好下场。我从读大学到博士毕业十年来一直勤奋好学,累计编写了数十万行C+/C代码。有这样的苦劳和疲劳,我应该称得上是编程老手了吧?我开发的软件都与科研相关集成电路CAD和3D图形学领域,动辄数万行程序,技术复杂,难度颇高。这些软件频频获奖,有一个软件获得首届中国大学生电脑大赛软件展示一等奖。在1995年开发的一套图形软件库到2000年还有人买。罗列出这些业绩,可以说明我算得上是编程高手了吧?可惜这种个人感觉不等于事实。读博期间我曾用一年时间开发了一个近10万行C+代码的3D图形软件产品,我心得意外表谦虚地向一位真正的软件高手请教。他虽然从未涉足过3D图形领域,却在几十分钟指出该软件多

9、处重大设计错误。让人感觉那套软件是用纸糊的华美衣服,扯一下掉一块,戳一下破个洞。我目瞪口呆地意识到这套软件毫无实用价值,一年的心血白化了,并且害死了自己的软件公司。人的顿悟通常发生在最心痛的时刻,在沮丧和心痛之后,我作了深刻反省,面壁半年,重新温习软件设计的根底知识。补修功之后,又觉得腰板硬了起来。博士毕业前半年,我曾到微软中国研究院找工作,承受微软公司一位资深软件工程师的面试。他让我写函数strcpy的代码。太容易了吧?错!这么一个小不点的函数,他从三个方面考察:1编程风格;2出错处理;3算法复杂度分析用于提高性能。在大学里从来没有人如此严格地考察过我的程序。我化了半个小时,修改了数次,他还

10、不尽满意,让我回家好好琢磨。我精神抖擞地进考场,大汗淋漓地出考场。这高手当得也太窝囊了。我又好好地反省了一次。我把反省后的心得体会写成文章放在网上传阅,引起了不少软件开发人员的共鸣。我因此有幸和国产大型IT企业如华为、贝尔、中兴等公司的同志们广泛交流。大家认为提高质量与生产率是软件工程要解决的核心问题。高质量程序设计是非常重要的环节,毕竟软件是靠编程来实现的。我们心目中的老手们和高手们能否编写出高质量的程序来?不见得都能!就我的经历与阅历来看,国大学的计算机教育压根就没有灌输高质量程序设计的观念,教师们和学生们也很少自觉关心软件的质量。勤奋好学的程序员长期在低质量的程序堆中滚爬,吃尽苦头之后才

11、有一些心得体会,长进极慢,我就是一例。现在国IT企业拥有学士、硕士、博士文凭的软件开发人员比比皆是,但他们在承受大学教育时就先天缺乏,岂能一到企业就突然实现质的飞跃。试问有多少软件开发人员对正确性、强健性、可靠性、效率、易用性、可读性可理解性、可扩展性、可复用性、兼容性、可移植性等质量属性了如指掌?并且能在实践中运用自如?。高质量可不是干活小心点就能实现的!我们有充分的理由疑虑:1编程老手可能会长期用隐含错误的方式编程习惯成自然,发现毛病后都不愿相信那是真的!2编程高手可以在*一领域写出极有水平的代码,但未必能从全局把握软件质量的方方面面。事实证明如此。我到贝尔工作一年来,陆续面试或测试过近百

12、名新老程序员的编程技能,质量合格率大约是10。很少有人能够写出完全符合质量要求的if语句,很多程序员对指针、存管理一知半解,。领导们不敢相信这是真的。我做过现场试验:有一次部门新进14名硕士生,在开欢送会之前对他们进展C+/C编程技能摸底考试。我问大家试题难不难?所有的人都答复不难。结果没有一个人及格,有半数人得零分。竞争对手公司的朋友们也做过试验,同样一败涂地。真的不是我心狠手辣或者要求过高,而是很多软件开发人员对自己的要求不够高。要知道华为、贝尔、中兴等公司的员工素质在国IT企业中是比拟前列的,倘假设他们的编程质量都如此差的话,我们怎么敢期望中小公司拿出高质量的软件呢?连程序都编不好,还谈

13、什么振兴民族软件产业,岂不胡扯。我打算定义编程老手和编程高手,请您别见笑。定义1:能长期稳定地编写出高质量程序的程序员称为编程老手。定义2:能长期稳定地编写出高难度、高质量程序的程序员称为编程高手。根据上述定义,马上得到第一推论:我既不是高手也算不上是老手。在写此书前,我阅读了不少程序设计方面的英文著作,越看越羞惭。因为发现自己连编程根本技能都未能全面掌握,顶多算是二流水平,还好意思谈什么老手和高手。希望和我一样在国土生土长的程序员朋友们能够做到:1知错就改;2经常温故而知新;3坚持学习,天天向上。二、本书导读首先请做附录B的C+/C试题不要看答案,考察自己的编程质量终究如何。然后参照答案严格

14、打分。1如果你只得了几十分,请不要声,也不要太难过。编程质量差往往是由于不良习惯造成的,与人的智力、能力没有多大关系,还是有药可救的。成绩越差,可以进步的空间就越大,中国不就是在落后中赶超兴旺资本主义国家吗?只要你能下决心改掉不良的编程习惯,第二次考试就能及格了。2如果你考及格了,说明你的技术根底不错,希望你能虚心学习、不断进步。如果你还没有找到适宜的工作单位,不妨到贝尔试一试。3如果你考出85分以上的好成绩,你有义务和资格为你所在的团队作C+/C编程培训。希望你能和我们多多交流、相互促进。半年前我曾经发现一颗好苗子,就把他挖到我们小组来。4如果你在没有任何提示的情况下考了总分值,希望你能收我

15、做你的徒弟。编程考试完毕后,请阅读本书的正文。本书第一章至第六章主要论述C+/C编程风格。难度不高,但是细节比拟多。别小看了,提高质量就是要从这些点点滴滴做起。世上不存在最好的编程风格,一切因需求而定。团队开发讲究风格一致,如果制定了大家认可的编程风格,则所有组员都要遵守。如果读者觉得本书的编程风格比拟合你的工作,则就采用它,不要只看不做。人在小时候说话发音不准,写字潦草,如果不改正,总有懊悔的时候。编程也是同样道理。第七章至第十一章是专题论述,技术难度比拟高,看书时要积极思考。特别是第七章存管理,读了并不表示懂了,懂了并不表示就能正确使用。有一位同事看了第七章后觉得野指针写得不错,与我切磋了

16、一把。可是过了两周,他告诉我,他忙了两天追查出一个Bug,想不到又是野指针出问题,只好重读第七章。光看本书对提高编程质量是有限的,建议大家阅读本书的参考文献,那些都是经典名著。如果你的编程质量已经过关了,不要就此满足。如果你想成为优秀的软件开发人员,建议你阅读并按照CMMI规做事,让自己的综合水平上升一个台阶。贝尔的员工可以向网络应用事业部软件工程研究小组索取CMMI有关资料,最好能参加培训。三、声明本书的大局部容取材于作者一年前的书籍手稿尚未出版,现整理汇编成为贝尔网络应用事业部的一个规化文件,同时作为培训教材。由于C+/C编程是众所周知的技术,没有什么可言。编程的好经历应该大家共享,我们自

17、己也是这么学来的。作者愿意公开本书的电子文档。声明如下:1读者可以任意拷贝、修改本书的容,但不可以篡改作者及所属单位。2未经作者许可,不得出版或大量印发本书。3如果竞争对手公司的员工得到本书,请勿公开使用,以免发生纠纷。预计到2002年7月,我们将建立切合中国国情的CMMI 3级解决方案。届时,包括本书在的约1000页规将严格受控。欢送读者对本书提出批评建议。林锐,2001年7月第1章文件构造每个C+/C程序通常分为两个文件。一个文件用于保存程序的声明declaration,称为头文件。另一个文件用于保存程序的实现implementation,称为定义definition文件。C+/C程序的头

18、文件以.h为后缀,C程序的定义文件以.c为后缀,C+程序的定义文件通常以.cpp为后缀也有一些系统以.cc或.c*为后缀。1.1 和版本的声明和版本的声明位于头文件和定义文件的开头参见例如1-1,主要容有:1信息。2文件名称,标识符,摘要。3当前版本号,作者/修改者,完成日期。4版本历史信息。/* Copyright (c) 2001,贝尔网络应用事业部* All rights reserved.* * 文件名称:filename.h* 文件标识:见配置管理方案书* 摘 要:简要描述本文件的容* * 当前版本:1.1* 作 者:输入作者或修改者名字* 完成日期:2001年7月20日* 取代版本

19、:1.0 * 原作者 :输入原作者或修改者名字* 完成日期:2001年5月10日*/例如1-1 和版本的声明1.2 头文件的构造头文件由三局部容组成:1头文件开头处的和版本声明参见例如1-1。2预处理块。3函数和类构造声明等。假设头文件名称为 graphics.h,头文件的构造参见例如1-2。l l【规则1-2-1】为了防止头文件被重复引用,应当用ifndef/define/endif构造产生预处理块。l l【规则1-2-2】用#include 格式来引用标准库的头文件编译器将从标准库目录开场搜索。l l【规则1-2-3】用#include filename.h 格式来引用非标准库的头文件编译

20、器将从用户的工作目录开场搜索。 【建议1-2-1】头文件中只存放声明而不存放定义在C+ 语法中,类的成员函数可以在声明的同时被定义,并且自动成为联函数。这虽然会带来书写上的方便,但却造成了风格不一致,弊大于利。建议将成员函数的定义与声明分开,不管该函数体有多么小。 【建议1-2-2】不提倡使用全局变量,尽量不要在头文件中出现象e*tern int value 这类声明。/ 和版本声明见例如1-1,此处省略。#ifndefGRAPHICS_H/ 防止graphics.h被重复引用#defineGRAPHICS_H#include / 引用标准库的头文件#include myheader.h /

21、引用非标准库的头文件void Function1();/ 全局函数声明class Bo* / 类构造声明;#endif例如1-2 C+/C头文件的构造1.3 定义文件的构造定义文件有三局部容:(1) 1定义文件开头处的和版本声明参见例如1-1。(2) 2对一些头文件的引用。(3) 3程序的实现体包括数据和代码。假设定义文件的名称为 graphics.cpp,定义文件的构造参见例如1-3。/ 和版本声明见例如1-1,此处省略。#include graphics.h/ 引用头文件/ 全局函数的实现体void Function1()/ 类成员函数的实现体void Bo*:Draw()例如1-3 C+

22、/C定义文件的构造1.4 头文件的作用早期的编程语言如Basic、Fortran没有头文件的概念,C+/C语言的初学者虽然会用使用头文件,但常常不明其理。这里对头文件的作用略作解释:1通过头文件来调用库功能。在很多场合,源代码不便或不准向用户公布,只要向用户提供头文件和二进制的库即可。用户只需要按照头文件中的接口声明来调用库功能,而不必关心接口怎么实现的。编译器会从库中提取相应的代码。2头文件能加强类型平安检查。如果*个接口被实现或被使用时,其方式与头文件中的声明不一致,编译器就会指出错误,这一简单的规则能大大减轻程序员调试、改错的负担。1.5 目录构造如果一个软件的头文件数目比拟多如超过十个

23、,通常应将头文件和定义文件分别保存于不同的目录,以便于维护。例如可将头文件保存于include目录,将定义文件保存于source目录可以是多级目录。如果*些头文件是私有的,它不会被用户的程序直接引用,则没有必要公开其声明。为了加强信息隐藏,这些私有的头文件可以和定义文件存放于同一个目录。第2章程序的版式版式虽然不会影响程序的功能,但会影响可读性。程序的版式追求清晰、美观,是程序风格的重要构成因素。可以把程序的版式比喻为书法。好的书法可让人对程序一目了然,看得兴致勃勃。差的程序书法如螃蟹爬行,让人看得索然无味,更令维护者烦恼有加。请程序员们学习程序的书法,弥补大学计算机教育的漏洞,实在很有必要。

24、2.1 空行空行起着分隔程序段落的作用。空行得体不过多也不过少将使程序的布局更加清晰。空行不会浪费存,虽然打印含有空行的程序是会多消耗一些纸,但是值得。所以不要舍不得用空行。l l【规则2-1-1】在每个类声明之后、每个函数定义完毕之后都要加空行。参见例如2-1al l【规则2-1-2】在一个函数体,逻揖上密切相关的语句之间不加空行,其它地方应加空行分隔。参见例如2-1b / 空行void Function1()/ 空行void Function2()/ 空行void Function3()/ 空行while (condition)statement1;/ 空行if (condition) s

25、tatement2;elsestatement3;/ 空行statement4; 例如2-1(a) 函数之间的空行 例如2-1(b) 函数部的空行2.2 代码行l l【规则2-2-1】一行代码只做一件事情,如只定义一个变量,或只写一条语句。这样的代码容易阅读,并且方便于写注释。l l【规则2-2-2】if、for、while、do等语句自占一行,执行语句不得紧跟其后。不管执行语句有多少都要加。这样可以防止书写失误。例如2-2a为风格良好的代码行,例如2-2b为风格不良的代码行。int width;/ 宽度int height;/ 高度int depth;/ 深度int width, heigh

26、t, depth; / 宽度高度深度* = a + b;y = c + d;z = e + f;* a + b; y = c + d; z = e + f;if (width height) dosomething();if (width =、=、+、*、%、&、|、这类操作符前后不加空格。 【建议2-3-1】对于表达式比拟长的for语句和if语句,为了紧凑起见可以适当地去掉一些空格,如for (i=0; i10; i+)和if (a=b) & (c= 2000) / 良好的风格if(year=2000) / 不良的风格if (a=b) & (c=b&c=d) / 不良的风格for (i=0;

27、 i10; i+) / 良好的风格for(i=0;i10;i+) / 不良的风格for (i = 0; I 10; i +) / 过多的空格* = a b a : b; / 良好的风格*=aFunction(); / 不要写成 b - Function();例如2-3 代码行的空格2.4 对齐l l【规则2-4-1】程序的分界符和应独占一行并且位于同一列,同时与引用它们的语句左对齐。l l【规则2-4-2】 之的代码块在右边数格处左对齐。例如2-4a为风格良好的对齐,例如2-4b为风格不良的对齐。void Function(int *) / program codevoid Function(

28、int *) / program codeif (condition) / program codeelse / program codeif (condition) / program codeelse / program codefor (initialization; condition; update) / program codefor (initialization; condition; update) / program codeWhile (condition) / program codewhile (condition) / program code如果出现嵌套的,则使用

29、缩进对齐,如: 例如2-4(a) 风格良好的对齐 例如2-4(b) 风格不良的对齐2.5 长行拆分l l【规则2-5-1】代码行最大长度宜控制在70至80个字符以。代码行不要过长,否则眼睛看不过来,也不便于打印。l l【规则2-5-2】长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首以便突出操作符。拆分出的新行要进展适当的缩进,使排版整齐,语句可读。if (very_longer_variable1 = very_longer_variable12)& (very_longer_variable3 = very_longer_variable14)& (very_longer_var

30、iable5 Draw();/ 类的成员函数l l【规则3-1-8】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。例如:intminValue;intma*Value;intSetValue();intGetValue(); 【建议3-1-1】尽量防止名字中出现数字编号,如Value1,Value2等,除非逻辑上确实需要编号。这是为了防止程序员偷懒,不肯为命名动脑筋而导致产生无意义的名字因为用数字编号最省事。3.2 简单的Windows应用程序命名规则作者对匈牙利命名规则做了合理的简化,下述的命名规则简单易用,比拟适合于Windows应用软件的开发。l l【规则3-2-1】类名和函

31、数名用大写字母开头的单词组合而成。例如:class Node;/ 类名class LeafNode;/ 类名void Draw(void);/ 函数名void SetValue(int value);/ 函数名l l【规则3-2-2】变量和参数用小写字母开头的单词组合而成。例如:BOOL flag;int drawMode;l l【规则3-2-3】常量全用大写的字母,用下划线分割单词。例如:const int MA* = 100;const int MA*_LENGTH = 100;l l【规则3-2-4】静态变量加前缀s_表示static。例如:void Init()static int s

32、_initValue;/ 静态变量l l【规则3-2-5】如果不得已需要全局变量,则使全局变量加前缀g_表示global。例如:int g_howManyPeople;/ 全局变量int g_howMuchMoney;/ 全局变量l l【规则3-2-6】类的数据成员加前缀m_表示member,这样可以防止数据成员与成员函数的参数同名。例如:void Object:SetValue(int width, int height)m_width = width;m_height = height;l l【规则3-2-7】为了防止*一软件库中的一些标识符和其它软件库中的冲突,可以为各种标识符加上能反映

33、软件性质的前缀。例如三维图形标准OpenGL的所有库函数均以gl开头,所有常量或宏定义均以GL开头。3.3 简单的Uni*应用程序命名规则第4章表达式和根本语句读者可能疑心:连if、for、while、goto、switch这样简单的东西也要探讨编程风格,是不是小题大做?我真的觉察很多程序员用隐含错误的方式写表达式和根本语句,我自己也犯过类似的错误。表达式和语句都属于C+/C的短语构造语法。它们看似简单,但使用时隐患比拟多。本章归纳了正确使用表达式和语句的一些规则与建议。4.1 运算符的优先级C+/C语言的运算符有数十个,运算符的优先级与结合律如表4-1所示。注意一元运算符 + - * 的优先

34、级高于对应的二元运算符。优先级运算符结合律从高到低排列( ) - .从左至右! + - 类型 sizeof+ - * &从右至左* / %从左至右+ -从左至右从左至右 =从左至右= !=从左至右&从左至右从左至右|从左至右&从左至右|从右至左:从右至左= += -= *= /= %= &= =|= =从左至右表4-1 运算符的优先级与结合律l l【规则4-1-1】如果代码行中的运算符比拟多,用括号确定表达式的操作顺序,防止使用默认的优先级。由于将表4-1熟记是比拟困难的,为了防止产生歧义并提高可读性,应当用括号确定表达式的操作顺序。例如:word = (high = b & c d & c

35、+ f = g + h ;/ 复合表达式过于复杂l l【规则4-2-2】不要有多用途的复合表达式。例如:d = (a = b + c) + r ; 该表达式既求a值又求d值。应该拆分为两个独立的语句:a = b + c;d = a + r;l l【规则4-2-3】不要把程序中的复合表达式与真正的数学表达式混淆。例如:if (a b c)/ a b c是数学表达式而不是程序表达式并不表示if (ab) & (bc)而是成了令人费解的if ( (ab)=或=-EPSINON) & (*=EPSINON)其中EPSINON是允许的误差即精度。4.3.4 指针变量与零值比拟l l【规则4-3-4】应当

36、将指针变量用=或!=与NULL比拟。指针变量的零值是空记为NULL。尽管NULL的值与0一样,但是两者意义不同。假设指针变量的名字为p,它与零值比拟的标准if语句如下:if (p = NULL)/ p与NULL显式比拟,强调p是指针变量if (p != NULL)不要写成if (p = 0) / 容易让人误解p是整型变量if (p != 0) 或者if (p)/ 容易让人误解p是布尔变量if (!p)4.3.5 对if语句的补充说明有时候我们可能会看到 if (NULL = p) 这样乖僻的格式。不是程序写错了,是程序员为了防止将 if (p = NULL) 误写成 if (p = NULL)

37、,而有意把p和NULL颠倒。编译器认为 if (p = NULL) 是合法的,但是会指出 if (NULL = p)是错误的,因为NULL不能被赋值。程序中有时会遇到if/else/return的组合,应该将如下不良风格的程序if (condition)return *;return y;改写为if (condition)return *;elsereturn y;或者改写成更加简练的 return (condition * : y);4.4 循环语句的效率C+/C循环语句中,for语句使用频率最高,while语句其次,do语句很少用。本节重点论述循环体的效率。提高循环体效率的根本方法是降低循

38、环体的复杂性。l l【建议4-4-1】在多重循环中,如果有可能,应当将最长的循环放在最层,最短的循环放在最外层,以减少CPU跨切循环层的次数。例如例如4-4(b)的效率比例如4-4(a)的高。for (row=0; row100; row+)for ( col=0; col5; col+ )sum = sum + arowcol;for (col=0; col5; col+ )for (row=0; row100; row+) sum = sum + arowcol;例如4-4(a) 低效率:长循环在最外层 例如4-4(b) 高效率:长循环在最层l l【建议4-4-2】如果循环体存在逻辑判断,

39、并且循环次数很大,宜将逻辑判断移到循环体的外面。例如4-4(c)的程序比例如4-4(d)多执行了N-1次逻辑判断。并且由于前者老要进展逻辑判断,打断了循环流水线作业,使得编译器不能对循环进展优化处理,降低了效率。如果N非常大,最好采用例如4-4(d)的写法,可以提高效率。如果N非常小,两者效率差异并不明显,采用例如4-4(c)的写法比拟好,因为程序更加简洁。for (i=0; iN; i+)if (condition) DoSomething();else DoOtherthing();if (condition)for (i=0; iN; i+) DoSomething();else for (i=0; iN; i+) DoOtherthing();表4-4(c) 效率低但程序简洁 表4-4(d) 效率高但程序不简洁4.5 for 语句的循环控制变量l l【规则4-5-

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!