第11章 其它編程經驗
11.1 使用const提高函數的健壯性看到const關鍵字，C++程式員首先想到的可能是const常量。這可不是良好的條件反射。如果只知道用const定義常量，那麼相當於把火藥僅用於製作鞭炮。const更大的魅力是它可以修飾函數的參數、傳回值，甚至函數的定義體。const是constant的縮寫，“恒定不變”的意思。被const修飾的東西都受到強制保護，可以預防意外的變動，能提高程式的健壯性。所以很多C++程式設計書籍建議：“Use const whenever you need”。
11.1.1
用const修飾函數的參數如果參數作輸出用，不論它是什麼資料類型，也不論它採用“指標傳遞”還是“引用傳遞”，都不能加const修飾，否則該參數將失去輸出功能。const只能修飾輸入參數：u 如果輸入參數採用“指標傳遞”，那麼加const修飾可以防止意外地改動該指標，起到保護作用。例如StringCopy函數： void StringCopy(char *strDestination, const char *strSource);其中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關鍵字只能放在函式宣告的尾部，大概是因為其它地方都已經被佔用了。
11.2 提高程式的效率程式的時間效率是指運行速度，空間效率是指程式佔用記憶體或者外存的狀況。全域效率是指站在整個系統的角度上考慮的效率，局部效率是指站在模組或函數角度上考慮的效率。 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 一些有益的建議²
【建議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、LogiScope等工具進行代碼審查。
參考文獻
[Cline] Marshall P. Cline and Greg A. Lomow, C++ FAQs, Addison-Wesley, 1995
[Eckel] Bruce Eckel, Thinking in C++（C++ 編程思想，劉宗田 等譯），機械工業出版社，2000
[Maguire] Steve Maguire, Writing Clean Code（編程精粹，薑靜波 等譯），電子工業出版社，1993
[Meyers] Scott Meyers, Effective C++, Addison-Wesley, 1992
[Murry] Robert B. Murry, C++ Strategies and Tactics, Addison-Wesley, 1993
[Summit] Steve Summit, C Programming FAQs, Addison-Wesley, 1996
