編寫(xiě)可移植C/C++程序的要點(diǎn)

以前做過(guò)兩年 C++ 程序移植工作，從 Win32 平臺移植到 Linux 平臺。大約有上百萬(wàn)行 C/C++代碼，歷時(shí)一年多。

在開(kāi)發(fā) Win32 版本時(shí)，已經(jīng)強調了程序的可植性，無(wú)奈 Win32 團隊里對 Linux 精通的人比較少，很多問(wèn)題沒(méi)有想到，直到后來(lái)移植工作開(kāi)始時(shí)，才發(fā)現移植并非像想的那樣簡(jiǎn)單。

后來(lái)，我發(fā)現大家對移植工程師都比較輕視，不管是從工資待遇還是管理層的態(tài)度來(lái)看都是這樣。他們往往認為，你們不過(guò)是把別人實(shí)現好的東西移植過(guò)去罷了，你老老實(shí)實(shí)，按步就班去做就行了，根本不需要絲毫創(chuàng )意。

事實(shí)并非如此，特別是對于大項目，其中遇到的問(wèn)題和困難可謂一言難盡。比如前面提到的那個(gè)項目，雖然過(guò)去好幾年了，很多問(wèn)題我仍然記憶猶新。

這里總結一些經(jīng)驗吧，這些經(jīng)驗，無(wú)一不是經(jīng)過(guò)大量汗水換來(lái)的，有的引起的 BUG 甚至耗費數周時(shí)間才查出來(lái)。寫(xiě)出來(lái)，供類(lèi)似的項目參考，不用再走這些彎路。

1、分層設計，隔離平臺相關(guān)的代碼。

就像可測試性一樣，可移植性也要從設計抓起。一般來(lái)說(shuō)，最上層和最下層都不具有良好的可移植性。

最上層是 GUI，大多數 GUI 都不是跨平臺的，如Win32 SDK 和 MFC。最下層是操作系統API，大多部分操作系統API都是專(zhuān)用的。

如果這兩層的代碼散布在整個(gè)軟件中，那么這個(gè)軟件的可植性將非常的差，這是不言自明的。

那么如何避免這種情況呢？當然是分層設計了：最底層采用 Adapter 模式，把不同操作系統的 API 封裝成一套統一的接口。至于封裝成類(lèi)還是封裝成函數，要看你采用的 C 還是 C++ 寫(xiě)的程序了。

這看起來(lái)很簡(jiǎn)單，其實(shí)不盡然（看完整篇文章后你會(huì )明白的），它將耗去你大量的時(shí)間去編寫(xiě)代碼，去測試它們。

采用現存的程序庫，是明智的做法，有很多這樣的庫，比如，C 庫有 glib（GNOME 的基礎類(lèi)），C++ 庫有 ACE(ADAPTIVE Communication Environment)等等，在開(kāi)發(fā)第一個(gè)平臺時(shí)就采用這些庫，可以大大減少移植的工作量。

最上層采用 MVC 模型，分離界面表現與內部邏輯代碼。把大部分代碼放到內部邏輯里面，界面僅僅是顯示和接收輸入，即使要換一套 GUI，工作量也不大。這同時(shí)也是提高可測試性的手段之一，當然還有其它一些附加好處。

所以即使你采用 QT 或者 GTK+ 等跨平臺的 GUI 設計軟件界面，分離界面表現與內部邏輯也是非常有用的。若做到了以上兩點(diǎn)，程序的可移植性基本上有保障了，其它的只是技術(shù)細節問(wèn)題。

2、事先熟悉各目標平臺，合理抽象底層功能。

這一點(diǎn)是建立在分層設計之上的，大多數底層函數，像線(xiàn)程、同步機制和 IPC 機制等等，不同平臺提供的函數，幾乎是一一對應的，封裝這些函數很簡(jiǎn)單，實(shí)現 Adapter 的工作幾乎只是體力活。

然而，對于一些比較特殊的應用，如圖形組件本身，就拿 GTK+ 來(lái)說(shuō)吧，基于 X Window 的功能和基于Win32的功能，兩者差巨大，除了窗口、事件等基本概念外，幾乎沒(méi)有什么相同的，如果不事先了解各個(gè)平臺的特性，在設計時(shí)就精心考慮的話(huà)，抽象出來(lái)的抽口在另外一個(gè)平臺幾乎無(wú)法實(shí)現。

3、盡量使用標準 C/C++ 函數。

大多數平臺都會(huì )實(shí)現 POSIX(Portable Operating System Interface)規定的函數，但這些函數較原生(Native) 函數來(lái)說(shuō)，性能上的表現可能較次一些，用起來(lái)也不如原生函數方便。

但是，最好不要貪圖這種便宜而使用原生函數函數，否則搬起的石頭最終會(huì )軋到自己的腳。比如，文件操作就用 fopen 之類(lèi)的函數，而不要用 CreateFile 之類(lèi)的函數等。

4、盡量不要使用 C/C++ 新標準里出現的特性。

并不是所有的編譯器都支持這些特性，像 VC 就不支持 C99 里面要求的可變參數的宏，VC 對一些模板特性的支持也不全面。為了安全起見(jiàn)，這方面不要太激進(jìn)了。

5、盡量不要使用 C/C++ 標準里沒(méi)有明確規定的特性。

比如你有多個(gè)動(dòng)態(tài)庫，每個(gè)動(dòng)態(tài)庫都有全局對象，而且這些全局對象的構造還有依賴(lài)關(guān)系，那你遲早會(huì )遇到麻煩的，這些全局對象構造的先后順序在標準里是沒(méi)有規定的。在一個(gè)平臺上運行正確，在另外一個(gè)平臺上可能莫明其妙的死機，最終還是要對程序作大量修改。

6、盡量不要使用準標準函數。

有些函數大多數平臺上都有，它們使用得太廣泛了，以至于大家都把它們當成標準了，比如 atoi（把字符串轉換成整數）、strdup(克隆字符串)、alloca（在棧分配自動(dòng)內存）等等。不怕一萬(wàn)，就怕萬(wàn)一，除非明白你在做什么，否則還是別碰它們?yōu)楹谩?/p>

7、注意標準函數的細節。

也許你不相信，即使是標準函數，拋開(kāi)內部實(shí)現不論，就其外在表現的差異也有時(shí)令人驚訝。這里略舉幾個(gè)例子：

（1） int accept(int s, struct sockaddr *addr, socklen_t *addrlen);addr/ addrlen本來(lái)是輸出參數，如果是 C++ 程序員，不管怎么樣，你已經(jīng)習慣于初始化所有的變量，不會(huì )有問(wèn)題。如果是 C 程序員，就難說(shuō)了，若沒(méi)有初始化它們，程序可能莫名其妙的 crash，而你做夢(mèng)也懷疑不到它頭它。這在 Win32 下沒(méi)問(wèn)題，在 Linux 下才會(huì )出現。

（2）int snprintf(char *str, size_t size, const char *format, ...);第二個(gè)參數size，在 Win32 下不包括空字符在內，在 Linux 下包括空字符，這一個(gè)字符的差異，也可能讓你耗上幾個(gè)小時(shí)。

（3） int stat(const char *file_name, struct stat *buf);這個(gè)函數本身沒(méi)有問(wèn)題，問(wèn)題出在結構 stat 上，st_ctime 在 Win32 下代表創(chuàng )建(create)時(shí)間，在 Linux 下代表最后修改(change)時(shí)間。

（4）FILE *fopen(const char *path, const char *mode);在讀取二進(jìn)制文件，沒(méi)有什么問(wèn)題。在讀取文本文件可要小心，Win32下 自動(dòng)預處理，讀出來(lái)的內容與文件實(shí)際都長(cháng)度不一樣，在 Linux 則沒(méi)有問(wèn)題。

8、小心數據標準數據類(lèi)型。

不少人已經(jīng)吃過(guò) int 類(lèi)型由 16 位轉變成 32 位帶來(lái)的苦頭，這已經(jīng)是陳年往事了，這里且不談。

你可知道 char 在有的系統上是有符號的，在有的系統是無(wú)符號的嗎？你可知道 wchar_t 在 Win32 下是 16 位的，在 Linux 下是 32 位的嗎？你可知道有符號的 1bit 的位域，取值是 0 和 -1 而不是 0 和 1 嗎？這些貌合神離的東東，端的是神出鬼沒(méi)，一不小心著(zhù)了它的道。

9、最好不要使用平臺獨有的特性。

比如 Win32 下 DLL 可以提供一個(gè) DllMain 函數，在特定的時(shí)間，操作系統的 Loader 會(huì )自動(dòng)調用這個(gè)函數。這類(lèi)功能很好用，但最好不要用，目標平臺可不能保證有這種功能。

10、最好不要使用編譯器特有的特性。

現代的編譯器都做很人性化，考慮得很周到，一些功能用起非常方便。像在 VC 里，你要實(shí)現線(xiàn)程局部存儲，你都不調用 TlsGetValue /Tls TlsSetValue 之類(lèi)的函數，在變量前加一個(gè) __declspec( thread ) 就行了，然而盡管在 pthread 里有類(lèi)似的功能，卻不能按這種方式實(shí)現，所以無(wú)法移植到 Linux 下。同樣 gcc 也有很多擴展，是在 VC 或者其它編譯器里所沒(méi)有的。

11、注意平臺的特性。

比如:在 Win32 下的 DLL 里面，除非明確指明為 export 的函數外，其它函數對外都是不可見(jiàn)的。而在 Linux 下，所有的非 static 的全局變量和函數，對外全部是可見(jiàn)的。這要特別小心，同名函數引起的問(wèn)題，讓你查上兩天也不為過(guò)。

（1）目錄分隔符，在 Win32 下用’//’，在 Linux 下用’/’。

（2）文本文件換行符，在 Win32 下用’/r/n’，在 Linux 下用’/n’，在 MacOS 下用’/r’。

（3）字節順序（大端/小端），不同硬件平臺的字節順序可能不一樣。

（4）字節對齊，在有的平臺(如x86）上，字節不對齊，無(wú)非速度慢一點(diǎn)，而有的平臺（如arm）上，它完全用錯誤的方式去讀取數據，而且不會(huì )給你一點(diǎn)提示。若出問(wèn)題，可能讓你一點(diǎn)頭緒都沒(méi)有。

12、最好清楚不同平臺的資源限制。

想必你還記得 DOS 下同時(shí)打開(kāi)的文件個(gè)數限制在幾十個(gè)的情形吧，如今操作系統的功能已經(jīng)強大多了，但是并非沒(méi)有限制。比如 Linux 下的共享內存默認的最大值是 4M。

若你對目標平臺常見(jiàn)的資源限制了然于胸，可能有很大的幫助，一些問(wèn)題很容易定位。

可移植性的問(wèn)題決不限于以上幾種，一方面，即使以前遇到過(guò)的問(wèn)題，部份已經(jīng)忘記了。

另外一方面，還有很多未知的問(wèn)題，根本沒(méi)有遇到過(guò)。這里算是拋磚引玉吧，請大家補充。