新聞中心

EEPW首頁 > 設計應用 > 編寫可移植C/C++程序的要點

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

作者:時間:2023-09-26來源:收藏

以前做過兩年 ++ 移植工作,從 Win32 平臺移植到 Linux 平臺。大約有上百萬行 /++代碼,歷時一年多。

本文引用地址:http://www.betmarket92.com/article/202309/451013.htm

在開發 Win32 版本時,已經強調了的可植性,無奈 Win32 團隊里對 Linux 精通的人比較少,很多問題沒有想到,直到后來移植工作開始時,才發現移植并非像想的那樣簡單。

后來,我發現大家對移植工程師都比較輕視,不管是從工資待遇還是管理層的態度來看都是這樣。他們往往認為,你們不過是把別人實現好的東西移植過去罷了,你老老實實,按步就班去做就行了,根本不需要絲毫創意。

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

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

1、分層設計,隔離平臺相關的代碼。

就像可測試性一樣,可移植性也要從設計抓起。一般來說,最上層和最下層都不具有良好的可移植性。

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

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

那么如何避免這種情況呢?當然是分層設計了:最底層采用 Adapter 模式,把不同操作系統的 API 封裝成一套統一的接口。至于封裝成類還是封裝成函數,要看你采用的 C 還是 寫的了。

這看起來很簡單,其實不盡然(看完整篇文章后你會明白的),它將耗去你大量的時間去編寫代碼,去測試它們。

采用現存的程序庫,是明智的做法,有很多這樣的庫,比如,C 庫有 glib(GNOME 的基礎類), 庫有 ACE(ADAPTIVE Communication Environment)等等,在開發第一個平臺時就采用這些庫,可以大大減少移植的工作量。

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

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

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

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

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

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

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

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

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

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

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

比如你有多個動態庫,每個動態庫都有全局對象,而且這些全局對象的構造還有依賴關系,那你遲早會遇到麻煩的,這些全局對象構造的先后順序在標準里是沒有規定的。在一個平臺上運行正確,在另外一個平臺上可能莫明其妙的死機,最終還是要對程序作大量修改。

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

有些函數大多數平臺上都有,它們使用得太廣泛了,以至于大家都把它們當成標準了,比如 atoi(把字符串轉換成整數)、strdup(克隆字符串)、alloca(在棧分配自動內存)等等。不怕一萬,就怕萬一,除非明白你在做什么,否則還是別碰它們為好。

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

也許你不相信,即使是標準函數,拋開內部實現不論,就其外在表現的差異也有時令人驚訝。這里略舉幾個例子:

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

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

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

(4)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 的全局變量和函數,對外全部是可見的。這要特別小心,同名函數引起的問題,讓你查上兩天也不為過。

(1)目錄分隔符,在 Win32 下用’//’,在 Linux 下用’/’。

(2)文本文件換行符,在 Win32 下用’/r/n’,在 Linux 下用’/n’,在 MacOS 下用’/r’。

(3)字節順序(大端/小端),不同硬件平臺的字節順序可能不一樣。

(4)字節對齊,在有的平臺(如x86)上,字節不對齊,無非速度慢一點,而有的平臺(如arm)上,它完全用錯誤的方式去讀取數據,而且不會給你一點提示。若出問題,可能讓你一點頭緒都沒有。

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

想必你還記得 DOS 下同時打開的文件個數限制在幾十個的情形吧,如今操作系統的功能已經強大多了,但是并非沒有限制。比如 Linux 下的共享內存默認的最大值是 4M。

若你對目標平臺常見的資源限制了然于胸,可能有很大的幫助,一些問題很容易定位。

可移植性的問題決不限于以上幾種,一方面,即使以前遇到過的問題,部份已經忘記了。

另外一方面,還有很多未知的問題,根本沒有遇到過。這里算是拋磚引玉吧,請大家補充。



關鍵詞: C C++ 程序

評論


相關推薦

技術專區

關閉
国产精品国产三级国产a|一本一道波多野结衣一区|欧美久久精品一级c|久久国产综合精品女同