高品質C++/C編程指南-第11章-其它編程經驗(2)

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 一些有益的建議
2 【建議11-3-1】當心那些視覺上不易分辨的操作符發生書寫錯誤。

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

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

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

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

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

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

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

2 【建議11-3-8】避免編寫技巧性很高代碼。

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

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

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

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

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

2 【建議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