C++程序设计最佳实践_C/C++_编程开发_程序员俱乐部

随着计算机语言的发展，我们现在编写一个程序越来越容易了。利用一些软件开发工具，往往只要通过鼠标的拖拖点点，计算机就会自动帮你生成许多代码。但在很多时候，计算机的这种能力被滥用了，我们往往只考虑把这个程序搭起来，而不去考虑程序的性能如何，程序是否足够的健壮。而此节课的目的主要是介绍一些编码的经验，让大家编写的程序更加健壮和高性能。 ? 　　1、Prefer const and inline to #define? ? 　　在C++编程中应该尽量使用const和inline来代替#define，尽量做到能不用#define就不用。#define常见的用途有“定义常量”以及“定义宏”，但其中存在诸多的弊病。? ? 　　第一，查错不直观，不利于调试。Define的定义是由预处理程序处理的，作的是完全的文本替换，不做任何的类型检查。在编译器处理阶段，define定义的东西已经被完全替换了，这样在debug的时候就看不到任何的相关信息，即跟踪时不能step into宏。例如，把ASPECT_RATIO用define定义成1.653，编译器就看不到ASPECT_RATIO这个名字了。如果编译器报1.653错，那么就无从知道此1.653来自于何处。在真正编码的时候应该使用如下的语句来定义： ? ? static const double ASPECT_RATIO = 1.653; ? 　　第二，没有任何类型信息，不是type safe。因为它是文本级别的替换，这样不利于程序的维护。 ? 　　第三，define的使用很容易造成污染。比如，如果有两个头文件都定义了ASPECT_RATIO, 而一个CPP文件又同时包含了这两个头文件，那么就会造成冲突。更难查的是另外一种错误，比如有如下的代码： [cpp]?view plaincopyprint?

1. //?in?header?file?def.h??
2. 　#define?Apple?1??
3. 　#define?Orange?2??
4. 　　?#define?Pineapple?3???
5. 　?…??
6. 　//?in?some?cpp?file?that?includes?the?def.h??
7. 　enum?Colors?{White,?Black,?Purple,?Orange};??

在.h文件中Orange被定义成水果的一种，而在.cpp文件中Orange又成为了一种颜色，那么编译器就会把此处的Orange替换成2，编译可能仍然可以通过，程序也能够运行，但是这就成了一个bug，表现出古怪的错误，且很难查错。再比如定义了一个求a与b哪个数大的宏，#define max(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也非常的难找。在实际编码时可以使用如下的语句来做： 　　template? 　　inline const T&? 　　max(const T& a, const T& b) { return a > b ? a : b; } ? 　　2、Prefer C++-style casts? ? 　　在程序中经常会需要把一种类型转换成另外一种类型，在C++中应该使用static_cast、const_cast、dynamic_cast、reinterpret_cast关键字来做类型转换。因为这有以下好处，一是其本身就是一种注释，在代码中看到上面这些关键字就可马上知道此处是进行类型转换。二是C语言中类型转换通常是很难进行搜索的，而通过关键字cast则可以很容易的找到程序中出现类型转换的地方了。 ? 　　3、Distinguish between prefix and postfix forms of increment and decrement operators? ? 　　通常对于操作系统或编译器自身支持的类型，prefix（前缀，如++i）与postfix（后缀，如i++）的效果是一样的。因为现在的编译器都很聪明，它会自动做优化，这两者的汇编代码是一样的，性能不会有差别。但有时候也会有不同的，如一些重载了caozuofu.html" target="_blank">操作符的类型。下面是模拟prefix与postfix的操作过程，可以发现在postfix操作中会生成一个临时变量，而这一临时变量是会占用额外的时间和开销的。 [cpp]?view plaincopyprint?

1. //?prefix?form:?increment?and?fetch??
2. 　UPInt&?UPInt::operator++()???
3. 　　{???
4. 　　?*this?+=?1;?//?increment???
5. 　　return?*this;?//?fetch???
6. 　　}???
7. 　//?postfix?form:?fetch?and?increment???
8. 　　const?UPInt?UPInt::operator++(int)???
9. 　　{??
10. 　　?UPInt?oldValue?=?*this;?//?fetch??
11. 　　++(*this);?//?increment???
12. 　　?return?oldValue;?//?return?what?was?fetched??
13. 　?}??

?

一般情况下不需要区分是先++，还是后++，但是我们在编写程序的时候最好能习惯性的将其写成++i的形式，如在使用STL中的iterator时，prefix与postfix会有相当大的性能差异。请不要小看这些细节，实际在编写程序的时候，若不注意具体细节，你会发现程序的性能会非常的低。但要注意，虽然在大多数情况下可以用prefix来代替postfix，但有一种情况例外，那就是有[]操作符时，比如gzArray [++index] 是不等于 gzArray[index++]的。

4、Minimizing Compile-time Dependencies? ? 　　有些人在编写程序时，往往喜欢将一个.h文件包含到另一个.h文件，而实践证明在做大型软件时这是一个非常不好的习惯，因这样会造成很多依赖的问题，包含较多的.h文件，别人又使用了这个class，而在他的那个工程中可能并不存在这些.h文件，这样很可能就编译不能通过。而且这样做，还可能造成很难去更新一个模块的情况。因为一个.h文件被很多模块包含的话，如果修改了此.h文件，在编译系统的时候，编译器会去寻找哪些模块依赖于某个被修改过的.h文件，那么就导致了所有包含入此.h文件的模块全都要进行重新编译。在项目比较小的时候，大家可能还感觉不到差别，但是如果说是在大型的软件系统里，你可能编译一遍源码需要七、八个小时。如果你这个.h文件被很多模块包含的话，就算在.h文件中加了一行注释，在编译时编译器检查哪些文件被改动，那么所有包含入此.h文件的模块都会被重新编译，造成巨大的时间和精力负担。对于此问题，解决的方法就是让.h文件自包含，也就是说让它包含尽量少的东西。所谓尽量少是指如删掉任何一个它包含进来的.h文件，都将无法正常进行工作。其实在很多情况下，并不需要一个.h文件去包含另一个.h文件，完全可以通过class声明来解决依赖关系的这种问题。再来看下面这个例子： [cpp]?view plaincopyprint?

1. #include?"a.h"?//?class?A??
2. 　#include?"b.h"?//?class?B??
3. 　#include?"c.h"?//?class?C??
4. 　#include?"d.h"?//?class?D??
5. 　#include?"e.h"?//?class?E??
6. 　class?X?:?public?A,?private?B??
7. 　{??
8. 　　public:??
9. 　E?SomeFunctionCall(E?someParameter);???
10. 　　private:??
11. 　?D?m_dInstance;??
12. 　};??

?

当类X从类A和类B中派生时，需要知道X在内存中都有哪些data，通常在内存中前面是基类的data，后面紧跟的是此派生类自身定义的data，因此就必须知道类A与类B的内部细节，要不然编译器就无法来安排内存了。但是在处理参数以及参数返回值的时候，实际上并不需要知道这些信息，在此处定义的SomeFunctionCall()只需知道E是个class就足够了，并不需要知道类E中的data如长度等的具体细节。上面的代码应该改写成如下的形式，以减少依赖关系：

?

[cpp]?view plaincopyprint?

1. #include?"a.h"?//?class?A??
2. 　　#include?"b.h"?//?class?B??
3. 　　#include?"c.h"?//?class?C??
4. 　　#include?"d.h"?//?class?D??
5. 　　class?E;??
6. 　　class?X?:?public?A,?private?B??
7. 　　{??
8. 　　　public:??
9. 　　E?SomeFunctionCall(E?someParameter);???
10. 　　　private:??
11. 　　D?m_dInstance;??
12. 　　};???
13. ???
14. 　　5、Never?treat?arrays?polymorphically???
15. ???
16. 　　不要把数组和多态一起使用，请看下面的例子。??
17. 　　class?BST?{?...?};???
18. 　　class?BalancedBST:?public?BST?{?...?};???
19. 　　void?printBSTArray(ostream&?s,?const?BST?array[],?int?numElements)???
20. 　　{???
21. 　　for?(int?i?=?0;?i?<?numElements;?++i)???
22. 　　{???
23. 　　?s?<<?array[i];???
24. 　　//?this?assumes?an?operator<<?is?defined?for?BST??
25. 　　}???
26. 　　}??
27. ???
28. 　　BalancedBST?bBSTArray[10];???
29. 　　printBSTArray(cout,?bBSTArray,?10);???

在printBSTArray()函数中，尽管传入的参数是BalancedBST类型，但由于其本来定义的类型是BST，那么它依然会根据BST来计算类型的长度。而通常派生类实例所占的内存要比基类实例所占的内存大一些，因此该程序在编译时会报错。请记住，永远不要把数组和C++的多态性放在一起使用。

?

? 　　6、Prevent exceptions from leaving destructors? ? 　　析构函数中一定不要抛出异常。通常有两种情况会导致析构函数的调用，一种是当该类的对象离开了它的域，或delete表达式中一个该类对象的指针，另一种是由于异常而引起析构函数的调用。 ? 　　如果析构函数被调用是由于exception引起，而此时在析构函数中又抛出了异常，程序会立即被系统终止，甚至都来不及进行内存释放。因此如果在析构函数中抛出异常的话，就很容易混淆引起异常的原因，且这样的软件也会让用户非常恼火。由于析构函数中很可能会调用其它的一些函数，所以在写析构函数的时候一定要注意，对这些函数是否会抛出异常要非常清楚，如果会的话，就一定要小心了。比如下面这段代码： [cpp]?view plaincopyprint?

1. Session::~Session()???
2. 　?{???
3. 　　logDestruction(this);??
4. 　?}???
5. ???
6. 　　比如logDestruction()函数可能会抛出异常，那么我们就应该采用下面这种代码的形式：???
7. 　　Session::~Session()???
8. 　?{???
9. 　　?try???
10. 　　{??
11. 　　　logDestruction(this);???
12. 　　?}??
13. 　　?catch?(...)???
14. 　　{???
15. 　　?}???
16. 　}???

?

这样程序出错的时候不会被立即关掉，可以给用户一些其它的选择，至少先让他把目前在做的工作保存下来。

? 　　7、Optimization:Remember the 80-20 rule? ? 　　在软件界有一个20-80法则，其实这是一个很有趣的现象，比如一个程序中20%的代码使用了该程序所占资源的80%；一个程序中20%的代码占用了总运行时间的80%；一个程序中20%的代码使用了该程序所占内存的80%；在20%的代码上面需要花费80%的维护力量，等等。这个规律还可以被继续推广下去，不过这个规律无法被证明，它是人们在实践中观察得出的结果。从这个规律出发，我们在做程序优化的时候，就有了针对性。比如想提高代码的运行速度，根据这个规律可以知道其中20%的代码占用了80%的运行时间，因此我们只要找到这20%的代码，并进行相应的优化，那么我们程序的运行速度就可以有较大的提高。再如有一个函数，占用了程序80%的运行时间，如果把这个函数的执行速度提高10倍，那么对程序整体性能的提高，影响是非常巨大的。如果有一个函数运行时间只占总时间的1%，那就算把这个函数的运行速度提高1000倍，对程序整体性能的提高也是影响不大的。所以我们的基本思想就是找到占用运行时间最大的那个函数，然后去优化它，哪怕只是改进了一点点，程序的整体性能也可以被提高很多。 ? 　　要想找出那20%的代码，我们的方法就是使用Profiler，它实际上是一些公司所开发的工具，可以检查程序中各个模块所分配内存的使用情况，以及每个函数所运行的时间等。常见的Profiler有Intel公司开发的VTune，微软公司开发的Visual Studio profiler，DevPartner from Compuware等。