高質量C++/C程式設計指南(第11章 其它程式設計經驗) (轉)[@more@] 

章 其它

使用const提高的健壯性

看到const關鍵字，C++員首先想到的可能是const常量。這可不是良好的條件反射。如果只知道用const定義常量，那麼相當於把火藥僅用於製作鞭炮。const更大的魅力是它可以修飾函式的引數、返回值，甚至函式的定義體。

const是constant的縮寫，“恆定不變”的意思。被const修飾的東西都受到強制保護，可以預防意外的變動，能提高程式的健壯性。所以很多C++書籍建議：“Use const whenever you need”。

 :namespace prefix = o ns = "urn:schemas--com::office" />

11.1.1 用const修飾函式的引數

如果引數作輸出用，不論它是什麼資料型別，也不論它採用“指標傳遞”還是“引用傳遞”，都不能加const修飾，否則該引數將失去輸出功能。

const只能修飾輸入引數：

u  如果輸入引數採用“指標傳遞”，那麼加const修飾可以防止意外地改動該指標，起到保護作用。

例如StringCopy函式：

  void StringCopy(char *strDestination, const char *str);

其中strSource是輸入引數，strDestination是輸出引數。給strSource加上const修飾後，如果函式體內的語句試圖改動strSource的內容，將指出錯誤。

 

u  如果輸入引數採用“值傳遞”，由於函式將自動產生臨時變數用於複製該引數，該輸入引數本來就無需保護，所以不要加const修飾。

例如不要將函式void Func1(int x) 寫成void Func1(const int x)。同理不要將函式void Func2(A a) 寫成void Func2(const A a)。其中A為自定義的資料型別。

 

u  對於非內部資料型別的引數而言，象void Func(A a) 這樣宣告的函式註定比較底。因為函式體內將產生A型別的臨時用於複製引數a，而臨時物件的構造、複製、析構過程都將消耗時間。

為了提高效率，可以將函式宣告改為void Func(A &a)，因為“引用傳遞”僅借用一下引數的別名而已，不需要產生臨時物件。但是函式void Func(A &a) 存在一個缺點：“引用傳遞”有可能改變引數a，這是我們不期望的。解決這個問題很容易，加const修飾即可，因此函式最終成為void Func(const A &a)。

以此類推，是否應將void Func(int x) 改寫為void Func(const int &x)，以便提高效率？完全沒有必要，因為內部資料型別的引數不存在構造、析構的過程，而複製也非常快，“值傳遞”和“引用傳遞”的效率幾乎相當。

  問題是如此的纏綿，我只好將“const &”修飾輸入引數的用法總結一下，如表11-1-1所示。

 

對於非內部資料型別的輸入引數，應該將“值傳遞”的方式改為“const引用傳遞”，目的是提高效率。例如將void Func(A a) 改為void Func(const A &a)。

 

對於內部資料型別的輸入引數，不要將“值傳遞”的方式改為“const引用傳遞”。否則既達不到提高效率的目的，又降低了函式的可理解性。例如void Func(int x) 不應該改為void Func(const int &x)。

 

表11-1-1 “const &”修飾輸入引數的規則

 

11.1.2 用const修飾函式的返回值

u  如果給以“指標傳遞”方式的函式返回值加const修飾，那麼函式返回值（即指標）的內容不能被修改，該返回值只能被賦給加const修飾的同型別指標。

例如函式

  const char * GetString(void);

如下語句將出現編譯錯誤：

  char *str = GetString();

正確的用法是

  const char *str = GetString();

 

u  如果函式返回值採用“值傳遞方式”，由於函式會把返回值複製到外部臨時的單元中，加const修飾沒有任何價值。

  例如不要把函式int GetInt(void) 寫成const int GetInt(void)。

  同理不要把函式A GetA(void) 寫成const A GetA(void)，其中A為使用者自定義的資料型別。

  如果返回值不是內部資料型別，將函式A GetA(void) 改寫為const A & GetA(void)的確能提高效率。但此時千萬千萬要小心，一定要搞清楚函式究竟是想返回一個物件的“複製”還是僅返回“別名”就可以了，否則程式會出錯。見6.2節“返回值的規則”。

 

u  函式返回值採用“引用傳遞”的場合並不多，這種方式一般只出現在類的賦值函式中，目的是為了實現鏈式表達。

例如

  class A

  {…

  A & operate = (const A &other);  // 賦值函式

  };

  A a, b, c;   // a, b, c 為A的物件

  …

  a = b = c;    // 正常的鏈式賦值

  (a = b) = c;  // 不正常的鏈式賦值，但合法

如果將賦值函式的返回值加const修飾，那麼該返回值的內容不允許被改動。上例中，語句 a = b = c仍然正確，但是語句 (a = b) = c 則是的。

 

11.1.3 const成員函式

  任何不會修改資料成員的函式都應該宣告為const型別。如果在編寫const成員函式時，不慎修改了資料成員，或者了其它非const成員函式，編譯器將指出錯誤，這無疑會提高程式的健壯性。

以下程式中，類stack的成員函式GetCount僅用於計數，從邏輯上講GetCount應當為const函式。編譯器將指出GetCount函式中的錯誤。

  class Stack

{

    public:

  void   Push(int elem);

  int   Pop(void);

  int   GetCount(void)  const;  // const成員函式

    private:

  int   m_num;

  int   m_data[100];

};

 

  int Stack::GetCount(void)  const

{
  ++ m_num;  // 編譯錯誤，企圖修改資料成員m_num

  Pop();    // 編譯錯誤，企圖呼叫非const函式

  return m_num;

  }

  const成員函式的宣告看起來怪怪的：const關鍵字只能放在函式宣告的尾部，大概是因為其它地方都已經被佔用了。

提高程式的效率

程式的時間效率是指執行速度，空間效率是指程式佔用或者外存的狀況。

全域性效率是指站在整個的角度上考慮的效率，區域性效率是指站在模組或函式角度上考慮的效率。

 

l  【規則11-2-1】不要一味地追求程式的效率，應當在滿足正確性、可靠性、健壯性、可讀性等質量因素的前提下，設法提高程式的效率。

 

l  【規則11-2-2】以提高程式的全域性效率為主，提高區域性效率為輔。

 

l  【規則11-2-3】在程式的效率時，應當先找出限制效率的“瓶頸”，不要在無關緊要之處最佳化。

 

l  【規則11-2-4】先最佳化資料結構和演算法，再最佳化程式碼。

 

l  【規則11-2-5】有時候時間效率和空間效率可能對立，此時應當分析那個更重要，作出適當的折衷。例如多花費一些記憶體來提高。

 

l  【規則11-2-6】不要追求緊湊的程式碼，因為緊湊的程式碼並不能產生高效的機器碼。

 

一些有益的建議

²  【建議11-3-1】當心那些視覺上不易分辨的運算子發生書寫錯誤。

我們經常會把“＝＝”誤寫成“＝”，象“||”、“&&”、“<=”、“>=”這類符號也很容易發生“丟1”失誤。然而編譯器卻不一定能自動指出這類錯誤。

 

²  【建議11-3-2】變數（指標、陣列）被建立之後應當及時把它們初始化，以防止把未被初始化的變數當成右值使用。

 

²  【建議11-3-3】當心變數的初值、預設值錯誤，或者精度不夠。

 

²  【建議11-3-4】當心資料型別轉換髮生錯誤。儘量使用顯式的資料型別轉換（讓人們知道發生了什麼事），避免讓編譯器輕悄悄地進行隱式的資料型別轉換。

 

²  【建議11-3-5】當心變數發生上溢或下溢，陣列的下標越界。

 

²  【建議11-3-6】當心忘記編寫錯誤處理程式，當心錯誤處理程式本身有誤。

 

²  【建議11-3-7】當心I/O有錯誤。

 

²  【建議11-3-8】避免編寫技巧性很高程式碼。

 

²  【建議11-3-9】不要設計面面俱到、非常靈活的資料結構。

 

²  【建議11-3-10】如果原有的程式碼質量比較好，儘量複用它。但是不要修補很差勁的程式碼，應當重新編寫。

 

²  【建議11-3-11】儘量使用標準庫函式，不要“發明”已經存在的庫函式。

 

²  【建議11-3-12】儘量不要使用與具體或環境關係密切的變數。

 

²  【建議11-3-13】把編譯器的選擇項設定為最嚴格狀態。

 

²  【建議11-3-14】如果可能的話，使用PC-Lint、Logipe等工具進行程式碼審查。