編寫可移植C/C++程序要點

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.注意標準函數的細節。也許你不相信，即便是標準函數，拋開內部實現不論，就其外在表現的差別也有時使人驚訝。這裏略舉幾個例子： 　　int accept(int s, struct sockaddr *addr, socklen_t *addrlen);addr/ addrlen原本是輸出參數，若是是C++程序員，無論怎麼樣，你已經習慣於初始化全部的變量，不會有問題。若是是C程序員，就難說了，若沒有初始化它們，程序可能莫名其妙的crash，而你作夢也懷疑不到它頭它。這在Win32下沒問題，在Linux下才會出現。 　　int snprintf(char *str, size_t size, const char *format, ……);第二個參數size，在Win32下不包括空字符在內，在Linux下包括空字符，這一個字符的差別，也可能讓你耗上幾個小時。 　　int stat(const char *file_name, struct stat *buf);這個函數自己沒有問題，問題出在結構stat上，st_ctime在Win32下表明建立(create)時間，在Linux下表明最後修改 (change)時間。 　　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.注意平臺的特性。好比: 　　在Win32下的DLL裏面，除非明確指明爲export的函數外，其它函數對外都是不可見的。而在Linux下，全部的非static的全局變量和函數，對外所有是可見的。這要特別當心，同名函數引發的問題，讓你查上兩天也不爲過。 　　目錄分隔符，在Win32下用‘\\’，在Linux下用‘/’。 　　文本文件換行符，在Win32下用‘\r\n’，在Linux下用‘\n’，在MacOS下用‘\r’。 　　字節順序（大端/小端），不一樣硬件平臺的字節順序可能不同。 　　字節對齊，在有的平臺(如x86）上，字節不對齊，無非速度慢一點，而有的平臺（如arm）上，它徹底用錯誤的方式去讀取數據，並且不會給你一點提示。若出問題，可能讓你一點頭緒都沒有。 　　12.最好清楚不一樣平臺的資源限制。想必你還記得DOS下同時打開的文件個數限制在幾十個的情形吧，現在操做系統的功能已經強大多了，可是並不是沒有限制。好比Linux下的共享內存默認的最大值是4M。若你對目標平臺常見的資源限制瞭然於胸，可能有很大的幫助，一些問題很容易定位。