編寫可移植C/C++程式的要點

編寫可移植C/C++程式的要點

 

轉載時請註明出處和作者聯絡方式：http://blog.csdn.net/absurd

作者聯絡方式：Li XianJing <xianjimli at hotmail dot com>

更新時間：2006-3-11

 

昨天看了05年的《程式設計師(精華本)》，裡面有篇關於編寫可移植的C++程式的文章，引起了我一絲興趣，大致讀了一下，有點啟發。不過感覺作者是位學院派的人士，沒有大型專案的移植經驗，把移植想得太簡單了，以為一個Adapter模式就搞定了所有的東西，太理想化了。

 

以前做過兩年C++程式移植工作，從Win32平臺移植到Linux平臺。大約有上百萬行C/C++程式碼，歷時一年多。在開發Win32版本時，已經強調了程式的可植性，無奈Win32團隊裡對Linux精通的人比較少，很多問題沒有想到，直到後來移植工作開始時，才發現移植並非像想的那樣簡單。

 

後來，我發現大家對移植工程師都比較輕視，不管是從工資待遇還是管理層的態度來看都是這樣。他們往往認為，你們不過是把別人實現好的東西移植過去罷了，你老老實實，按步就班去做就行了，根本不需要絲毫創意。事實並非如此，特別是對於大專案，其中遇到的問題和困難可謂一言難盡。比如前面提到的那個專案，雖然過去好幾年了，很多問題我仍然記憶猶新。

 

這裡總結一些經驗吧，這些經驗，無一不是經過大量汗水換來的，有的引起的BUG甚至耗費數週時間才查出來。寫出來，供類似的專案參考，不用再走這些彎路。

 

1.分層設計，隔離平臺相關的程式碼。就像可測試性一樣，可移植性也要從設計抓起。一般來說，最上層和最下層都不具有良好的可移植性。最上層是GUI，大多數GUI都不是跨平臺的，如Win32 SDK和MFC。最下層是作業系統API，大多部分作業系統API都是專用的。

 

如果這兩層的程式碼散佈在整個軟體中，那麼這個軟體的可植性將非常的差，這是不言自明的。那麼如何避免這種情況呢？當然是分層設計了：

 

最底層採用Adapter模式，把不同作業系統的API封裝成一套統一的介面。至於封裝成類還是封裝成函式，要看你採用的C還是C++寫的程式了。這看起來很簡單，其實不盡然（看完整篇文章後你會明白的），它將耗去你大量的時間去編寫程式碼，去測試它們。採用現存的程式庫，是明智的做法，有很多這樣的庫，比如，C庫有glib（GNOME的基礎類），C++庫有ACE(ADAPTIVE Communication Environment)等等，在開發第一個平臺時就採用這些庫，可以大大減少移植的工作量。

 

最上層採用MVC模型，分離介面表現與內部邏輯程式碼。把大部分程式碼放到內部邏輯裡面，介面僅僅是顯示和接收輸入，即使要換一套GUI，工作量也不大。這同時也是提高可測試性的手段之一，當然還有其它一些附加好處。所以即使你採用QT或者GTK+等跨平臺的GUI設計軟體介面，分離介面表現與內部邏輯也是非常有用的。

 

若做到了以上兩點，程式的可移植性基本上有保障了，其它的只是技術細節問題。

 

2.事先熟悉各目標平臺，合理抽象底層功能。這一點是建立在分層設計之上的，大多數底層函式，像執行緒、同步機制和IPC機制等等，不同平臺提供的函式，幾乎是一一對應的，封裝這些函式很簡單，實現Adapter的工作幾乎只是體力活。然而，對於一些比較特殊的應用，如圖形元件本身，就拿GTK+來說吧，基於X Window的功能和基於Win32的功能，兩者差巨大，除了視窗、事件等基本概念外，幾乎沒有什麼相同的，如果不事先了解各個平臺的特性，在設計時就精心考慮的話，抽象出來的抽口在另外一個平臺幾乎無法實現。

 

3.儘量使用標準C/C++函式。大多數平臺都會實現POSIX(Portable Operating System Interface)規定的函式，但這些函式較原生(Native) 函式來說，效能上的表現可能較次一些，用起來也不如原生函式方便。但是，最好不要貪圖這種便宜而使用原生函式函式，否則搬起的石頭最終會軋到自己的腳。比如，檔案操作就用fopen之類的函式，而不要用CreateFile之類的函式等。

 

4.儘量不要使用C/C++新標準裡出現的特性。並不是所有的編譯器都支援這些特性，像VC就不支援C99裡面要求的可變引數的巨集，VC對一些模板特性的支援也不全面。為了安全起見，這方面不要太激進了。

 

5.儘量不要使用C/C++標準裡沒有明確規定的特性。比如你有多個動態庫，每個動態庫都有全域性物件，而且這些全域性物件的構造還有依賴關係，那你遲早會遇到麻煩的，這些全域性物件構造的先後順序在標準裡是沒有規定的。在一個平臺上執行正確，在另外一個平臺上可能莫明其妙的當機，最終還是要對程式作大量修改。

 

6.儘量不要使用準標準函式。有些函式大多數平臺上都有，它們使用得太廣泛了，以至於大家都把它們當成標準了，比如atoi（把字串轉換成整數）、strdup(克隆字串)、alloca（在棧分配自動記憶體）等等。不怕一萬，就怕萬一，除非明白你在做什麼，否則還是別碰它們為好。

 

7.注意標準函式的細節。也許你不相信，即使是標準函式，拋開內部實現不論，就其外在表現的差異也有時令人驚訝。這裡略舉幾個例子：

l         int accept(int s, struct sockaddr *addr, socklen_t *addrlen);addr/ addrlen本來是輸出引數，如果是C++程式設計師，不管怎麼樣，你已經習慣於初始化所有的變數，不會有問題。如果是C程式設計師，就難說了，若沒有初始化它們，程式可能莫名其妙的crash，而你做夢也懷疑不到它頭它。這在Win32下沒問題，在Linux下才會出現。

l         int snprintf(char *str, size_t size, const char *format, ...);第二個引數size，在Win32下不包括空字元在內，在Linux下包括空字元，這一個字元的差異，也可能讓你耗上幾個小時。

l         int stat(const char *file_name, struct stat *buf);這個函式本身沒有問題，問題出在結構stat上，st_ctime在Win32下代表建立(create)時間，在Linux下代表最後修改(change)時間。

l         FILE *fopen(const char *path, const char *mode);在讀取二進位制檔案，沒有什麼問題。在讀取文字檔案可要小心，Win32下自動預處理，讀出來的內容與檔案實際都長度不一樣，在Linux則沒有問題。

 

8.小心資料標準資料型別。不少人已經吃過int型別由16位轉變成32位帶來的苦頭，這已經是陳年往事了，這裡且不談。你可知道char在有的系統上是有符號的，在有的系統是無符號的嗎？你可知道wchar_t在Win32下是16位的，在Linux 下是32位的嗎？你可知道有符號的1bit的位域，取值是0和-1而不是0和1嗎？這些貌合神離的東東，端的是神出鬼沒，一不小心著了它的道。

 

9.最好不要使用平臺獨有的特性。比如Win32下DLL可以提供一個DllMain函式，在特定的時間，作業系統的Loader會自動呼叫這個函式。這類功能很好用，但最好不要用，目標平臺可不能保證有這種功能。

 

10.最好不要使用編譯器特有的特性。現代的編譯器都做很人性化，考慮得很周到，一些功能用起非常方便。像在VC裡，你要實現執行緒區域性儲存，你都不呼叫TlsGetValue /Tls TlsSetValue之類的函式，在變數前加一個__declspec( thread )就行了，然而儘管在pthread裡有類似的功能，卻不能按這種方式實現，所以無法移植到Linux下。同樣gcc也有很多擴充套件，是在VC或者其它編譯器裡所沒有的。

 

11.注意平臺的特性。比如:

l         在Win32下的DLL裡面，除非明確指明為export的函式外，其它函式對外都是不可見的。而在Linux下，所有的非static的全域性變數和函式，對外全部是可見的。這要特別小心，同名函式引起的問題，讓你查上兩天也不為過。

l         目錄分隔符，在Win32下用’//’，在Linux下用’/’。

l         文字檔案換行符，在Win32下用’/r/n’，在Linux下用’/n’，在MacOS下用’/r’。

l         位元組順序（大端/小端），不同硬體平臺的位元組順序可能不一樣。

l         位元組對齊，在有的平臺(如x86）上，位元組不對齊，無非速度慢一點，而有的平臺（如arm）上，它完全用錯誤的方式去讀取資料，而且不會給你一點提示。若出問題，可能讓你一點頭緒都沒有。

 

12.最好清楚不同平臺的資源限制。想必你還記得DOS下同時開啟的檔案個數限制在幾十個的情形吧，如今作業系統的功能已經強大多了，但是並非沒有限制。比如Linux下的共享記憶體預設的最大值是4M。若你對目標平臺常見的資源限制瞭然於胸，可能有很大的幫助，一些問題很容易定位。

 

可移植性的問題決不限於以上幾種，一方面，即使以前遇到過的問題，部份已經忘記了。另外一方面，還有很多未知的問題，根本沒有遇到過。這裡算是拋磚引玉吧，請大家補充。

 

~~end~~