| 订阅 | 在线投稿
分享
 
 
 

C++程序设计最佳实践

2008-06-01 02:05:04 编辑來源:互联网 国际版 评论
 
 
  随着计算机语言的发展,我们现在编写一个程序越来越轻易了。利用一些软件开发工具,往往只要通过鼠标的拖拖点点,计算机就会自动帮你生成许多代码。但在很多时候,计算机的这种能力被滥用了,我们往往只考虑把这个程序搭起来,而不去考虑程序的性能如何,程序是否足够的健壮。

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  而此节课的目的主要是介绍一些编码的经验,让大家编写的程序更加健壮和高性能。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文件又同时包含了这两个头文件,那么就会造成冲突。更难查的是另外一种错误,比如有如下的代码:

  // in header file def.h

  #define Apple 1

  #define Orange 2

  #define Pineapple 3

  …

  // in some cpp file that includes the def.h

  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<class T>

  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++)的效果是一样的。因为现在的编译器都很聪明,它会自动做优化,这两者的汇编代码是一样的,性能不会有差别。但有时候也会有不同的,如一些重载了操作符的类型。下面是模拟prefix与postfix的操作过程,可以发现在postfix操作中会生成一个临时变量,而这一临时变量是会占用额外的时间和开销的。

  

   // prefix form: increment and fetch

  UPInt& UPInt::operator++()

  {

  *this += 1; // increment

  return *this; // fetch

  }

  // postfix form: fetch and increment

  const UPInt UPInt::operator++(int)

  {

  UPInt oldValue = *this; // fetch

  ++(*this); // increment

  return oldValue; // return what was fetched

  }

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

  

C++程序设计最佳实践
更多内容请看C/C++技术专题 C/C++进阶技术文档 C/C++相关文章专题,或

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

C++程序设计最佳实践
更多内容请看C/C++技术专题 C/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文件又同时包含了这两个头文件,那么就会造成冲突。更难查的是另外一种错误,比如有如下的代码:   // in header file def.h   #define Apple 1   #define Orange 2     #define Pineapple 3    …   // in some cpp file that includes the def.h   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<class T>   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++)的效果是一样的。因为现在的编译器都很聪明,它会自动做优化,这两者的汇编代码是一样的,性能不会有差别。但有时候也会有不同的,如一些重载了操作符的类型。下面是模拟prefix与postfix的操作过程,可以发现在postfix操作中会生成一个临时变量,而这一临时变量是会占用额外的时间和开销的。   // prefix form: increment and fetch   UPInt& UPInt::operator++()    {     *this += 1; // increment    return *this; // fetch    }   // postfix form: fetch and increment    const UPInt UPInt::operator++(int)    {     UPInt oldValue = *this; // fetch    ++(*this); // increment     return oldValue; // return what was fetched    }   一般情况下不需要区分是先++,还是后++,但是我们在编写程序的时候最好能习惯性的将其写成++i的形式,如在使用STL中的iterator时,prefix与postfix会有相当大的性能差异。请不要小看这些细节,实际在编写程序的时候,若不注重具体细节,你会发现程序的性能会非常的低。但要注重,虽然在大多数情况下可以用prefix来代替postfix,但有一种情况例外,那就是有[]操作符时,比如gzArray [++index] 是不等于 gzArray[index++]的。 [url=http://www.wangchao.net.cn/bbsdetail_1785335.html][img]http://image.wangchao.net.cn/it/1323423846557.gif[/img][/url] 更多内容请看C/C++技术专题 C/C++进阶技术文档 C/C++相关文章专题,或   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等。 [url=http://www.wangchao.net.cn/bbsdetail_1785335.html][img]http://image.wangchao.net.cn/it/1323423846605.gif[/img][/url] 更多内容请看C/C++技术专题 C/C++进阶技术文档 C/C++相关文章专题,或
󰈣󰈤
日版宠物情人插曲《Winding Road》歌词

日版宠物情人2017的插曲,很带节奏感,日语的,女生唱的。 最后听见是在第8集的时候女主手割伤了,然后男主用嘴帮她吸了一下,插曲就出来了。 歌手:Def...

兄弟共妻,我成了他们夜里的美食

老钟家的两个儿子很特别,就是跟其他的人不太一样,魔一般的执着。兄弟俩都到了要结婚的年龄了,不管自家老爹怎么磨破嘴皮子,兄弟俩说不娶就不娶,老父母为兄弟两操碎了心...

网络安全治理:国家安全保障的主要方向是打击犯罪,而不是处置和惩罚受害者

来源:中国青年报 新的攻击方法不断涌现,黑客几乎永远占据网络攻击的上风,我们不可能通过技术手段杜绝网络攻击。国家安全保障的主要方向是打击犯罪,而不是处置和惩罚...

 
 
 
>>返回首页<<
 为你推荐
 
 
 
 转载本文
 UBB代码 HTML代码
复制到剪贴板...
 
 
 热帖排行
 
单纯美女 迷人女孩
校园甜美少女
忍辱负重
大学校园
 
 
王朝网络微信公众号
微信扫码关注本站公众号wangchaonetcn
 
  免责声明:本文仅代表作者个人观点,与王朝网络无关。王朝网络登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
©2005- 王朝网络 版权所有