二级考试C++辅导-C++程序设计实践.pdf

《二级考试C++辅导-C++程序设计实践.pdf》由会员分享，可在线阅读，更多相关《二级考试C++辅导-C++程序设计实践.pdf（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、二级考试二级考试 C+C+辅导辅导:C+:C+程序设计实践程序设计实践1、Prefer const and inline to #define在 C+编程中应当尽量使用 const 和 inline 来代替#define，尽量做到能不用#define 就不用。#define 常见的用途有“定义常量”以及“定义宏” ，但其中存在诸多的弊病。第一，查错不直观，不利于调试。Define 的定义是由预处理程序处理的， 作的是完全的文本替换， 不做任何的类型检查。 在编译器处理阶段，define 定义的东西已经被完全替换了，这样在 debug 的时候就看不到任何的相关信息，即跟踪时不能 step int

2、o 宏。例如，把 ASPECT_RATIO 用define 定义成 1.653，编译器就看不到 ASPECT_RATIO 这个名字了。假如编译器报 1.653 错， 那么就无从知道此 1.653 来自于何处。 在真正编码的时候应当使用如下的语句来定义：static const double ASPECT_RATIO = 1.653;其次，没有任何类型信息，不是 type safe。由于它是文本级别的替换，这样不利于程序的维护。第三，define 的使用很简单造成污染。比方，假如有两个头文件都定义了 ASPECT_RATIO, 而一个 CPP 文件又同时包含了这两个头文件，那么就会造成冲突。更难

3、查的是另外一种错误，比方有如下的代码：/ in header file def.h#define Apple 1#define Orange 2#define Pineapple 3/ in some cpp file that includes the def.henum Colors White, Black, Purple, Orange;在.h 文件中 Orange 被定义成水果的一种，而在.cpp 文件中 Orange又成为了一种颜色，那么编译器就会把此处的 Orange 替换成 2，编译可能仍旧可以通过，程序也能够运行，但是这就成了一个bug，表现出奇怪的错误， 且很难查错。 再比

4、方定义了一个求 a 与 b 哪个数大的宏， #definemax(a,b) (a) (b) ? (a) : (b)int a = 5, b = 0;max(+ a, b);max(+ a, b + 10);在上面的操作中， max(+ a, b); 语句中 a 被+了两次， 而 max(+ a,b + 10); 语句中 a 只加了一次，这样在程序处理中就很有可能成为一个bug，且此 bug 也特别的难找。在实际编码时可以使用如下的语句来做：templateinline const T 2、Prefer C+-style casts在程序中常常会需要把一种类型转换成另外一种类型， 在 C+中应当

5、使用 static_cast、const_cast、dynamic_cast、reinterpret_cast 关键字来做类型转换。由于这有以下好处，一是其本身就是一种解释，在代码中看到上面这些关键字就可立刻知道此处是进展类型转换。 二是 C 语言中类型转换通常是很难进展搜寻的，而通过关键字 cast 则可以很简单的找到程序中消失类型转换的地方了。3、Distinguish between prefix and postfix forms of incrementand decrement operators通常对于操作系统或编译器自身支持的类型， prefix （前缀， 如+i）与 post

6、fix（后缀，如 i+）的效果是一样的。由于现在的编译器都很聪慧，它会自动做优化，这两者的汇编代码是一样的，性能不会有差异。但有时候也会有不同的，如一些重载了操作符的类型。下面是模拟 prefix与postfix的操作过程， 可以发觉在postfix操作中会生成一个临时变量，而这一临时变量是会占用额外的时间和开销的。/ prefix form: increment and fetchUPInt / incrementreturn *this; / fetch/ postfix form: fetch and incrementconst UPInt UPInt:operator+(int)UP

7、Int oldValue = *this; / fetch+(*this); / incrementreturn oldValue; / return what was fetched一般状况下不需要区分是先+， 还是后+， 但是我们在编写程序的时候能习惯性的将其写成+i 的形式，如在使用 STL 中的 iterator 时，prefix 与 postfix 会有相当大的性能差异。请不要小看这些细节，实际在编写程序的时候， 若不留意详细细节， 你会发觉程序的性能会特别的低。但要留意，虽然在大多数状况下可以用 prefix 来代替 postfix，但有一种状况例外，那就是有操作符时，比方 gzA

8、rray +index 是不等于gzArrayindex+的。4、Minimizing Compile-time Dependencies有些人在编写程序时， 往往喜爱将一个.h 文件包含到另一个.h 文件，而实践证明在做大型软件时这是一个特别不好的习惯， 因这样会造成许多依靠的问题，包含较多的.h 文件，别人又使用了这个 class，而在他的那个工程中可能并不存在这些.h 文件，这样很可能就编译不能通过。而且这样做，还可能造成很难去更新一个模块的状况。由于一个.h 文件被许多模块包含的话，假如修改了此.h 文件，在编译系统的时候，编译器会去查找哪些模块依靠于某个被修改正的.h 文件，那么就导

9、致了全部包含入此.h 文件的模块全都要进展重新编译。在工程比拟小的时候，大家可能还感觉不到差异， 但是假如说是在大型的软件系统里， 你可能编译一遍源码需要七、八个小时。假如你这个.h 文件被许多模块包含的话，就算在.h 文件中加了一行解释，在编译时编译器检查哪些文件被改动，那么全部包含入此.h 文件的模块都会被重新编译，造成巨大的时间和精力负担。对于此问题，解决的方法就是让.h 文件自包含，也就是说让它包含尽量少的东西。所谓尽量少是指如删掉任何一个它包含进来的.h 文件，都将无法正常进展工作。其实在许多状况下，并不需要一个.h 文件去包含另一个.h文件， 完全可以通过class声明来解决依靠关

10、系的这种问题。再来看下面这个例子：#include “a.h“ / class A#include “b.h“ / class B#include “c.h“ / class C#include “d.h“ / class D#include “e.h“ / class Eclass X : public A, private Bpublic:E SomeFunctionCall(E someParameter);private:D m_dInstance;当类 X 从类 A 和类 B 中派生时， 需要知道 X 在内存中都有哪些 data，通常在内存中前面是基类的data，后面紧跟的是此派生类

11、自身定义的data， 因此就必需知道类 A 与类 B 的内部细节， 要不然编译器就无法来安排内存了。 但是在处理参数以及参数返回值的时候， 实际上并不需要知道这些信息，在此处定义的 SomeFunctionCall()只需知道 E 是个 class 就足够了，并不需要知道类 E 中的 data 如长度等的详细细节。上面的代码应当改写成如下的形式，以削减依靠关系：#include “a.h“ / class A#include “b.h“ / class B#include “c.h“ / class C#include “d.h“ / class Dclass E;class X : publ

12、ic A, private Bpublic:E SomeFunctionCall(E someParameter);private:D m_dInstance;5、Never treat arrays polymorphically不要把数组和多态一起使用，请看下面的例子。class BST . ;class BalancedBST: public BST . ;void printBSTArray(ostream i numElements; +i)s arrayi;/ this assumes an operator is defined for BSTBalancedBST bBSTAr

13、ray10;printBSTArray(cout, bBSTArray, 10);数组在内存中是一个连续的内存空间， 而在数组中应当如何来定位一个元素呢？过程是这样的， 编译器可以知道每个数据类型的长度大小， 假如数组的index是0， 则会自动去取第一个元素； 假如是指定了某个index，编译器则会依据此 index 与该数据类型的长度自动去算出该元素的位置。在 printBSTArray()函数中，尽管传入的参数是 BalancedBST 类型，但由于其原来定义的类型是 BST，那么它依旧会依据 BST 来计算类型的长度。 而通常派生类实例所占的内存要比基类实例所占的内存大一些， 因此该程

14、序在编译时会报错。请记住，永久不要把数组和C+的多态性放在一起使用。6、Prevent exceptions from leaving destructors析构函数中肯定不要抛出特别。 通常有两种状况会导致析构函数的调用，一种是当该类的对象离开了它的域，或 delete 表达式中一个该类对象的指针，另一种是由于特别而引起析构函数的调用。假如析构函数被调用是由于 exception 引起， 而此时在析构函数中又抛出了特别，程序会马上被系统终止，甚至都来不及进展内存释放。因此假如在析构函数中抛出特别的话， 就很简单混淆引起特别的缘由， 且这样的软件也会让用户特别恼火。 由于析构函数中很可能会调用

15、其它的一些函数， 所以在写析构函数的时候肯定要留意， 对这些函数是否会抛出特别要特别清晰，假如会的话，就肯定要当心了。比方下面这段代码：Session:Session()logDestruction(this);比方 logDestruction()函数可能会抛出特别，那么我们就应当采纳下面这种代码的形式：Session:Session()trylogDestruction(this);catch (.)这样程序出错的时候不会被马上关掉，可以给用户一些其它的选择，至少先让他把目前在做的工作保存下来。7、Optimization:Remember the 80-20 rule在软件界有一个 20

16、-80 法则， 其实这是一个很好玩的现象， 比方一个程序中 20%的代码使用了该程序所占资源的 80%；一个程序中 20%的代码占用了总运行时间的 80%；一个程序中 20%的代码使用了该程序所占内存的 80%；在 20%的代码上面需要花费 80%的维护力气，等等。这个规律还可以被连续推广下去， 不过这个规律无法被证明， 它是人们在实践中观看得出的结果。 从这个规律动身， 我们在做程序优化的时候， 就有了针对性。比方想提高代码的运行速度，依据这个规律可以知道其中 20%的代码占用了 80%的运行时间， 因此我们只要找到这 20%的代码， 并进展相应的优化，那么我们程序的运行速度就可以有较大的提

17、高。 再如有一个函数， 占用了程序 80%的运行时间，假如把这个函数的执行速度提高 10 倍，那么对程序整体性能的提高， 影响是特别巨大的。 假如有一个函数运行时间只占总时间的 1%，那就算把这个函数的运行速度提高1000 倍，对程序整体性能的提高也是影响不大的。 所以我们的根本思想就是找到占用运行时间的那个函数，然后去优化它，哪怕只是改良了一点点，程序的整体性能也可以被提高许多。要想找出那 20%的代码， 我们的方法就是使用 Profiler， 它实际上是一些公司所开发的工具， 可以检查程序中各个模块所安排内存的使用状况，以及每个函数所运行的时间等。常见的 Profiler 有 Intel 公司开发的VTune，微软公司开发的Visual Studio profiler ，DevPartner fromCompuware 等。