程式設計修養（三） (轉)

程式設計修養（三） (轉)[@more@]

6、if 語句對出錯的處理
———————————
我看見你說了，這有什麼好說的。還是先看一段程式碼吧。

  if ( ch >= '0' && ch <= '9' ){
  /* 正常處理程式碼 */
  }else{
  /* 輸出錯誤資訊 */
  printf("error ...... ");
  return ( FALSE );
  }

這種結構很不好，特別是如果“正常處理程式碼”很長時，對於這種情況，最好不要用else。先判斷錯誤，如：

  if ( ch < '0' || ch > '9' ){
  /* 輸出錯誤資訊 */
  printf("error ...... ");
  return ( FALSE );
  }
 
  /* 正常處理程式碼 */
  ......

這樣的結構，不是很清楚嗎？突出了錯誤的條件，讓別人在使用你的的時候，第一眼就能看到不合法的條件，於是就會更下意識的避免。

 

7、頭中的#ifndef
——————————
千萬不要忽略了頭件的中的#ifndef，這是一個很關鍵的東西。比如你有兩個C檔案，這兩個C檔案都include了同一個標頭檔案。而編譯時，這兩個C檔案要一同編譯成一個可執行檔案，於是問題來了，大量的宣告衝突。

還是把標頭檔案的內容都放在#ifndef和#endif中吧。不管你的標頭檔案會不會被多個檔案引用，你都要加上這個。一般格式是這樣的：

  #ifndef 
  #define
 
  ......
  ......
 
  #endif
 
在理論上來說可以是自由命名的，但每個標頭檔案的這個“標識”都應該是唯一的。標識的命名規則一般是標頭檔案名全大寫，前後加下劃線，並把檔名中的“.”也變成下劃線，如：stdio.h

  #ifndef _STDIO_H_
  #define _STDIO_H_
 
  ......
 
  #endif
 
（BTW：預編譯有多很有用的功能。你會用預編譯嗎？） 
 

 

8、在堆上分配
—————————
可能許多人對記憶體分配上的“棧 stack”和“堆 heap”還不是很明白。包括一些科班出身的人也不明白這兩個概念。我不想過多的說這兩個東西。簡單的來講，stack上分配的記憶體自動釋放，heap上分配的記憶體，系統不釋放，哪怕程式退出，那一塊記憶體還是在那裡。stack一般是靜態分配記憶體，heap上一般是動態分配記憶體。

由malloc系統函式分配的記憶體就是從堆上分配記憶體。從堆上分配的記憶體一定要自己釋放。用free釋放，不然就是術語——“記憶體洩露”（或是“記憶體”）—— Memory Leak。於是，系統的可分配記憶體會隨malloc越來越少，直到系統崩潰。還是來看看“棧記憶體”和“堆記憶體”的差別吧。

  棧記憶體分配
  —————
  char*
  AllocStrFromStack()
  {
  char pstr[100];
  return pstr;
  }
 
 
  堆記憶體分配
  —————
  char*
  AllocStrFromHeap(int len)
  {
  char *pstr;
 
  if ( len <= 0 ) return NULL;
  return ( char* ) malloc( len );
  }

對於第一個函式，那塊pstr的記憶體在函式返回時就被系統釋放了。於是所返回的char*什麼也沒有。而對於第二個函式，是從堆上分配記憶體，所以哪怕是程式退出時，也不釋放，所以第二個函式的返回的記憶體沒有問題，可以被使用。但一定要free釋放，不然就是Memory Leak！

在堆上分配記憶體很容易造成記憶體洩漏，這是C/C++的最大的“剋星”，如果你的程式要穩定，那麼就不要出現Memory Leak。所以，我還是要在這裡千叮嚀萬囑付，在使用malloc系統函式（包括calloc，realloc）時千萬要小心。

記得有一個上的服務應用程式，大約有幾百的C檔案編譯而成，執行測試良好，等使用時，每隔三個月系統就是down一次，搞得許多人焦頭爛額，查不出問題所在。只好，每隔兩個月人工手動重啟系統一次。出現這種問題就是Memery Leak在做怪了，在C/C++中這種問題總是會發生，所以你一定要小心。一個Rational的檢測工作——Purify，可以幫你測試你的程式有沒有記憶體洩漏。

我保證，做過許多C/C++的工程的程式設計師，都會對malloc或是new有些感冒。當你什麼時候在使用malloc和new時，有一種輕度的緊張和惶恐的感覺時，你就具備了這方面的修養了。
 
對於malloc和free的操作有以下規則：

1) 配對使用，有一個malloc，就應該有一個free。（C++中對應為new和delete）
2) 儘量在同一層上使用，不要像上面那種，malloc在函式中，而free在函式外。最好在同一呼叫層上使用這兩個函式。
3) malloc分配的記憶體一定要初始化。free後的指標一定要設定為NULL。 

注：雖然現在的（如：UNIX和/NT）都有程式記憶體跟蹤機制，也就是如果你有沒有釋放的記憶體，作業系統會幫你釋放。但作業系統依然不會釋放你程式中所有產生了Memory Leak的記憶體，所以，最好還是你自己來做這個工作。（有的時候不知不覺就出現Memory Leak了，而且在幾百萬行的程式碼中找無異於海底撈針，Rational有一個工具叫Purify，可能很好的幫你檢查程式中的Memory Leak）

 

9、變數的初始化
————————
接上一條，變數一定要被初始化再使用。C/C++在這個方面不會像一樣幫你初始化，這一切都需要你自己來，如果你使用了沒有初始化的變數，結果未知。好的程式設計師從來都會在使用變數前初始化變數的。如：

  1) 對malloc分配的記憶體進行memset清零操作。（可以使用calloc分配一塊全零的記憶體）
  2) 對一些棧上分配的struct或陣列進行初始化。（最好也是清零）
 
不過話又說回來了，初始化也會造成系統執行時間有一定的開銷，所以，也不要對所有的變數做初始化，這個也沒有意義。好的程式設計師知道哪些變數需要初始化，哪些則不需要。如：以下這種情況，則不需要。
 
  char *pstr;  /* 一個字串 */
  pstr = ( char* ) malloc( 50 );
  if ( pstr == NULL ) exit(0);
  strcpy( pstr, "Hello Wrold" );

但如果是下面一種情況，最好進行記憶體初始化。（指標是一個危險的東西，一定要初始化）

  char **pstr;  /* 一個字串陣列 */
  pstr = ( char** ) malloc( 50 );
  if ( pstr == NULL ) exit(0);
 
  /* 讓陣列中的指標都指向NULL */
  memset( pstr, 0, 50*sizeof(char*) );
 
而對於全域性變數，和靜態變數，一定要宣告時就初始化。因為你不知道它第一次會在哪裡被使用。所以使用前初始這些變數是比較不現實的，一定要在宣告時就初始化它們。如：

  Links *plnk = NULL;  /* 對於全域性變數plnk初始化為NULL */

 

 

10、h和c檔案的使用
—————————
H檔案和C檔案怎麼用呢？一般來說，H檔案中是declare（宣告），C檔案中是define（定義）。因為C檔案要編譯成庫檔案（下是.obj/.lib，UNIX下是.o/.a），如果別人要使用你的函式，那麼就要引用你的H檔案，所以，H檔案中一般是變數、宏定義、列舉、結構和函式介面的宣告，就像一個介面說明檔案一樣。而C檔案則是實現細節。

H檔案和C檔案最大的用處就是宣告和實現分開。這個特性應該是公認的了，但我仍然看到有些人喜歡把函式寫在H檔案中，這種習慣很不好。（如果是C++話，對於其模板函式，在VC中只有把實現和宣告都寫在一個檔案中，因為VC不支援export關鍵字）。而且，如果在H檔案中寫上函式的實現，你還得在makefile中把標頭檔案的依賴關係也加上去，這個就會讓你的makefile很不規範。

最後，有一個最需要注意的地方就是：帶初始化的全域性變數不要放在H檔案中！

例如有一個處理錯誤資訊的結構：

  char* errmsg[] = {
  /* 0 */  "No error", 
  /* 1 */  "Open file error", 
  /* 2 */  "Failed in sending/receiving a message", 
  /* 3 */  "Bad arguments", 
  /* 4 */  "Memeroy is not enough",
  /* 5 */  "Service is down; try later",
  /* 6 */  "Unknow information",
  /* 7 */  "A socket operation has failed",
  /* 8 */  "Pession denied",
  /* 9 */  "Bad configuration file format", 
  /* 10 */  "Communication time out",
  ......
  ......
  };
 
請不要把這個東西放在標頭檔案中，因為如果你的這個標頭檔案被5個函式庫（.lib或是.a）所用到，於是他就被連結在這5個.lib或.a中，而如果你的一個程式用到了這5個函式庫中的函式，並且這些函式都用到了這個出錯資訊陣列。那麼這份資訊將有5個副本存在於你的檔案中。如果你的這個errmsg很大的話，而且你用到的函式庫更多的話，你的執行檔案也會變得很大。

正確的寫法應該把它寫到C檔案中，然後在各個需要用到errmsg的C檔案頭上加上 extern char* errmsg[]; 的外部宣告，讓編譯器在連結時才去管他，這樣一來，就只會有一個errmsg存在於執行檔案中，而且，這樣做很利於封裝。

我曾遇到過的最瘋狂的事，就是在我的目標檔案中，這個errmsg一共有112個副本，執行檔案有8M左右。當我把errmsg放到C檔案中，併為一千多個C檔案加上了extern的宣告後，所有的函式庫檔案尺寸都下降了20%左右，而我的執行檔案只有5M了。一下子少了3M啊。

［ 備註 ］
—————
有朋友對我說，這個只是一個特例，因為，如果errmsg在執行檔案中存在多個副本時，可以加快程式執行速度，理由是errmsg的多個複本會讓系統的記憶體換頁降低，達到提升。像我們這裡所說的errmsg只有一份，當某函式要用errmsg時，如果記憶體隔得比較遠，會產生換頁，反而效率不高。

這個說法不無道理，但是一般而言，對於一個比較大的系統，errmsg是比較大的，所以產生副本導致執行檔案尺寸變大，不僅增加了系統裝載時間，也會讓一個程式在記憶體中佔更多的頁面。而對於errmsg這樣資料，一般來說，在系統執行時不會經常用到，所以還是產生的記憶體換頁也就不算頻繁。權衡之下，還是隻有一份errmsg的效率高。即便是像logmsg這樣頻繁使用的的資料，作業系統的記憶體排程演算法會讓這樣的頻繁使用的頁面常駐於記憶體，所以也就不會出現記憶體換頁問題了。

/Develop/read_article.?id=18270"> 

（版權所有，轉載時請註明出處和作者資訊）