正在阅读：C++程序设计最佳实践C++程序设计最佳实践

2005-07-19 10:03 出处：作者：unknow 责任编辑：moningfeng

　　4、Minimizing Compile-time Dependencies

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

　　#include "a.h" // class A
　　#include "b.h" // class B
　　#include "c.h" // class C
　　#include "d.h" // class D
　　#include "e.h" // class E
　　class X : public A, private B
　　{
　　　public:
　　E SomeFunctionCall(E someParameter);
　　　private:
　　 D m_dInstance;
　　};

　　当类X从类A和类B中派生时，需要知道X在内存中都有哪些data，通常在内存中前面是基类的data，后面紧跟的是此派生类自身定义的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 D
　　class E;
　　class X : public A, private B
　　{
　　　public:
　　E SomeFunctionCall(E someParameter);
　　　private:
　　D m_dInstance;
　　};

　　5、Never treat arrays polymorphically

　　不要把数组和多态一起使用，请看下面的例子。

　　class BST { ... };
　　class BalancedBST: public BST { ... };
　　void printBSTArray(ostream& s, const BST array[], int numElements)
　　{
　　for (int i = 0; i < numElements; ++i)
　　{
　　 s << array[i];
　　// this assumes an operator<< is defined for BST
　　}
　　}

　　BalancedBST bBSTArray[10];
　　printBSTArray(cout, bBSTArray, 10);

　　数组在内存中是一个连续的内存空间，而在数组中应该如何来定位一个元素呢？过程是这样的，编译器可以知道每个数据类型的长度大小，如果数组的index是0，则会自动去取第一个元素；如果是指定了某个index，编译器则会根据此index与该数据类型的长度自动去算出该元素的位置。

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

　　6、Prevent exceptions from leaving destructors

　　析构函数中一定不要抛出异常。通常有两种情况会导致析构函数的调用，一种是当该类的对象离开了它的域，或delete表达式中一个该类对象的指针，另一种是由于异常而引起析构函数的调用。

　　如果析构函数被调用是由于exception引起，而此时在析构函数中又抛出了异常，程序会立即被系统终止，甚至都来不及进行内存释放。因此如果在析构函数中抛出异常的话，就很容易混淆引起异常的原因，且这样的软件也会让用户非常恼火。由于析构函数中很可能会调用其它的一些函数，所以在写析构函数的时候一定要注意，对这些函数是否会抛出异常要非常清楚，如果会的话，就一定要小心了。比如下面这段代码：

　　Session::~Session()
　 {
　　logDestruction(this);
　 }

　　比如logDestruction()函数可能会抛出异常，那么我们就应该采用下面这种代码的形式：

　　Session::~Session()
　 {
　　 try
　　{
　　　logDestruction(this);
　　 }
　　 catch (...)
　　{
　　 }
　}

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

　　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等。