[導(dǎo)讀]??以前做過兩年C程序移植工作，從Win32平臺移植到Linux平臺。大約有上百萬行C/C代碼，歷時一年多。在開發(fā)Win32版本時，已經(jīng)強(qiáng)調(diào)了程序的可植性，無奈Win32團(tuán)隊里對Linux精通的人比較少，很多問題沒有想到，直到后來移植工作開始時，才發(fā)現(xiàn)移植并非像想的那樣簡單。后來...
??
以前做過兩年 C 程序移植工作，從 Win32 平臺移植到 Linux 平臺。大約有上百萬行 C/C 代碼，歷時一年多。
在開發(fā) Win32 版本時，已經(jīng)強(qiáng)調(diào)了程序的可植性，無奈 Win32 團(tuán)隊里對 Linux 精通的人比較少，很多問題沒有想到，直到后來移植工作開始時，才發(fā)現(xiàn)移植并非像想的那樣簡單。后來，我發(fā)現(xiàn)大家對移植工程師都比較輕視，不管是從工資待遇還是管理層的態(tài)度來看都是這樣。他們往往認(rèn)為，你們不過是把別人實現(xiàn)好的東西移植過去罷了，你老老實實，按步就班去做就行了，根本不需要絲毫創(chuàng)意。事實并非如此，特別是對于大項目，其中遇到的問題和困難可謂一言難盡。比如前面提到的那個項目，雖然過去好幾年了，很多問題我仍然記憶猶新。這里總結(jié)一些經(jīng)驗吧，這些經(jīng)驗，無一不是經(jīng)過大量汗水換來的，有的引起的 BUG 甚至耗費(fèi)數(shù)周時間才查出來。寫出來，供類似的項目參考，不用再走這些彎路。1、分層設(shè)計，隔離平臺相關(guān)的代碼就像可測試性一樣，可移植性也要從設(shè)計抓起。一般來說，最上層和最下層都不具有良好的可移植性。最上層是 GUI，大多數(shù) GUI 都不是跨平臺的，如Win32 SDK 和 MFC。最下層是操作系統(tǒng)API，大多部分操作系統(tǒng)API都是專用的。如果這兩層的代碼散布在整個軟件中，那么這個軟件的可植性將非常的差，這是不言自明的。那么如何避免這種情況呢？當(dāng)然是分層設(shè)計了：最底層采用?Adapter 模式，把不同操作系統(tǒng)的 API 封裝成一套統(tǒng)一的接口。至于封裝成類還是封裝成函數(shù)，要看你采用的 C 還是 C 寫的程序了。這看起來很簡單，其實不盡然（看完整篇文章后你會明白的），它將耗去你大量的時間去編寫代碼，去測試它們。采用現(xiàn)存的程序庫，是明智的做法，有很多這樣的庫，比如，C 庫有?glib（GNOME 的基礎(chǔ)類），C 庫有 ACE(ADAPTIVE Communication Environment)等等，在開發(fā)第一個平臺時就采用這些庫，可以大大減少移植的工作量。最上層采用 MVC 模型，分離界面表現(xiàn)與內(nèi)部邏輯代碼。把大部分代碼放到內(nèi)部邏輯里面，界面僅僅是顯示和接收輸入，即使要換一套 GUI，工作量也不大。這同時也是提高可測試性的手段之一，當(dāng)然還有其它一些附加好處。所以即使你采用 QT 或者 GTK 等跨平臺的 GUI 設(shè)計軟件界面，分離界面表現(xiàn)與內(nèi)部邏輯也是非常有用的。若做到了以上兩點，程序的可移植性基本上有保障了，其它的只是技術(shù)細(xì)節(jié)問題。2、事先熟悉各目標(biāo)平臺，合理抽象底層功能這一點是建立在分層設(shè)計之上的，大多數(shù)底層函數(shù)，像線程、同步機(jī)制和 IPC 機(jī)制等等，不同平臺提供的函數(shù)，幾乎是一一對應(yīng)的，封裝這些函數(shù)很簡單，實現(xiàn) Adapter 的工作幾乎只是體力活。然而，對于一些比較特殊的應(yīng)用，如圖形組件本身，就拿 GTK 來說吧，基于 X Window 的功能和基于Win32的功能，兩者差巨大，除了窗口、事件等基本概念外，幾乎沒有什么相同的，如果不事先了解各個平臺的特性，在設(shè)計時就精心考慮的話，抽象出來的抽口在另外一個平臺幾乎無法實現(xiàn)。3、盡量使用標(biāo)準(zhǔn)C/C 函數(shù)大多數(shù)平臺都會實現(xiàn)?POSIX(Portable Operating System Interface)規(guī)定的函數(shù)，但這些函數(shù)較原生(Native) 函數(shù)來說，性能上的表現(xiàn)可能較次一些，用起來也不如原生函數(shù)方便。但是，最好不要貪圖這種便宜而使用原生函數(shù)函數(shù)，否則搬起的石頭最終會軋到自己的腳。比如，文件操作就用 fopen 之類的函數(shù)，而不要用 CreateFile 之類的函數(shù)等。4、盡量不要使用C/C 新標(biāo)準(zhǔn)里出現(xiàn)的特性并不是所有的編譯器都支持這些特性，像 VC 就不支持 C99 里面要求的可變參數(shù)的宏，VC 對一些模板特性的支持也不全面。為了安全起見，這方面不要太激進(jìn)了。5、盡量不要使用C/C 標(biāo)準(zhǔn)里沒有明確規(guī)定的特性比如你有多個動態(tài)庫，每個動態(tài)庫都有全局對象，而且這些全局對象的構(gòu)造還有依賴關(guān)系，那你遲早會遇到麻煩的，這些全局對象構(gòu)造的先后順序在標(biāo)準(zhǔn)里是沒有規(guī)定的。在一個平臺上運(yùn)行正確，在另外一個平臺上可能莫明其妙的死機(jī)，最終還是要對程序作大量修改。6、盡量不要使用準(zhǔn)標(biāo)準(zhǔn)函數(shù)有些函數(shù)大多數(shù)平臺上都有，它們使用得太廣泛了，以至于大家都把它們當(dāng)成標(biāo)準(zhǔn)了，比如 atoi（把字符串轉(zhuǎn)換成整數(shù)）、strdup(克隆字符串)、alloca（在棧分配自動內(nèi)存）等等。不怕一萬，就怕萬一，除非明白你在做什么，否則還是別碰它們?yōu)楹谩?/span>7、注意標(biāo)準(zhǔn)函數(shù)的細(xì)節(jié)也許你不相信，即使是標(biāo)準(zhǔn)函數(shù)，拋開內(nèi)部實現(xiàn)不論，就其外在表現(xiàn)的差異也有時令人驚訝。這里略舉幾個例子：（1） int accept(int s, struct sockaddr *addr, socklen_t *addrlen);addr/ addrlen本來是輸出參數(shù)，如果是 C 程序員，不管怎么樣，你已經(jīng)習(xí)慣于初始化所有的變量，不會有問題。如果是 C 程序員，就難說了，若沒有初始化它們，程序可能莫名其妙的 crash，而你做夢也懷疑不到它頭它。這在 Win32 下沒問題，在 Linux 下才會出現(xiàn)。（2）int snprintf(char *str, size_t size, const char *format, ...);第二個參數(shù)size，在 Win32 下不包括空字符在內(nèi)，在 Linux 下包括空字符，這一個字符的差異，也可能讓你耗上幾個小時。（3） int stat(const char *file_name, struct stat *buf);這個函數(shù)本身沒有問題，問題出在結(jié)構(gòu) stat 上，st_ctime 在 Win32 下代表創(chuàng)建(create)時間，在 Linux 下代表最后修改(change)時間。（4）FILE *fopen(const char *path, const char *mode);在讀取二進(jìn)制文件，沒有什么問題。在讀取文本文件可要小心，Win32下 自動預(yù)處理，讀出來的內(nèi)容與文件實際都長度不一樣，在 Linux 則沒有問題。8、小心數(shù)據(jù)標(biāo)準(zhǔn)數(shù)據(jù)類型不少人已經(jīng)吃過 int 類型由 16 位轉(zhuǎn)變成 32 位帶來的苦頭，這已經(jīng)是陳年往事了，這里且不談。你可知道 char 在有的系統(tǒng)上是有符號的，在有的系統(tǒng)是無符號的嗎？你可知道 wchar_t 在 Win32 下是 16 位的，在 Linux 下是 32 位的嗎？你可知道有符號的 1bit 的位域，取值是 0 和 -1 而不是 0 和 1 嗎？這些貌合神離的東東，端的是神出鬼沒，一不小心著了它的道。9、最好不要使用平臺獨(dú)有的特性比如 Win32 下 DLL 可以提供一個 DllMain 函數(shù)，在特定的時間，操作系統(tǒng)的 Loader 會自動調(diào)用這個函數(shù)。這類功能很好用，但最好不要用，目標(biāo)平臺可不能保證有這種功能。10、最好不要使用編譯器特有的特性現(xiàn)代的編譯器都做很人性化，考慮得很周到，一些功能用起非常方便。像在 VC 里，你要實現(xiàn)線程局部存儲，你都不調(diào)用 TlsGetValue /Tls TlsSetValue 之類的函數(shù)，在變量前加一個 __declspec( thread ) 就行了，然而盡管在 pthread 里有類似的功能，卻不能按這種方式實現(xiàn)，所以無法移植到 Linux 下。同樣 gcc 也有很多擴(kuò)展，是在 VC 或者其它編譯器里所沒有的。11、注意平臺的特性比如:在 Win32 下的 DLL 里面，除非明確指明為 export 的函數(shù)外，其它函數(shù)對外都是不可見的。而在 Linux 下，所有的非 static 的全局變量和函數(shù)，對外全部是可見的。這要特別小心，同名函數(shù)引起的問題，讓你查上兩天也不為過。（1）目錄分隔符，在 Win32 下用’//’，在 Linux 下用’/’。（2）文本文件換行符，在 Win32 下用’/r/n’，在 Linux 下用’/n’，在 MacOS 下用’/r’。（3）字節(jié)順序（大端/小端），不同硬件平臺的字節(jié)順序可能不一樣。（4）字節(jié)對齊，在有的平臺(如x86）上，字節(jié)不對齊，無非速度慢一點，而有的平臺（如arm）上，它完全用錯誤的方式去讀取數(shù)據(jù)，而且不會給你一點提示。若出問題，可能讓你一點頭緒都沒有。12、最好清楚不同平臺的資源限制想必你還記得 DOS 下同時打開的文件個數(shù)限制在幾十個的情形吧，如今操作系統(tǒng)的功能已經(jīng)強(qiáng)大多了，但是并非沒有限制。比如 Linux 下的共享內(nèi)存默認(rèn)的最大值是 4M。若你對目標(biāo)平臺常見的資源限制了然于胸，可能有很大的幫助，一些問題很容易定位。可移植性的問題決不限于以上幾種，一方面，即使以前遇到過的問題，部份已經(jīng)忘記了。另外一方面，還有很多未知的問題，根本沒有遇到過。這里算是拋磚引玉吧，請大家補(bǔ)充。
作者：jim.li來源：https://blog.csdn.net/absurd版權(quán)歸原作者所有，如有侵權(quán)，請聯(lián)系刪除。
以前做過兩年 C 程序移植工作，從 Win32 平臺移植到 Linux 平臺。大約有上百萬行 C/C 代碼，歷時一年多。
在開發(fā) Win32 版本時，已經(jīng)強(qiáng)調(diào)了程序的可植性，無奈 Win32 團(tuán)隊里對 Linux 精通的人比較少，很多問題沒有想到，直到后來移植工作開始時，才發(fā)現(xiàn)移植并非像想的那樣簡單。后來，我發(fā)現(xiàn)大家對移植工程師都比較輕視，不管是從工資待遇還是管理層的態(tài)度來看都是這樣。他們往往認(rèn)為，你們不過是把別人實現(xiàn)好的東西移植過去罷了，你老老實實，按步就班去做就行了，根本不需要絲毫創(chuàng)意。事實并非如此，特別是對于大項目，其中遇到的問題和困難可謂一言難盡。比如前面提到的那個項目，雖然過去好幾年了，很多問題我仍然記憶猶新。這里總結(jié)一些經(jīng)驗吧，這些經(jīng)驗，無一不是經(jīng)過大量汗水換來的，有的引起的 BUG 甚至耗費(fèi)數(shù)周時間才查出來。寫出來，供類似的項目參考，不用再走這些彎路。1、分層設(shè)計，隔離平臺相關(guān)的代碼就像可測試性一樣，可移植性也要從設(shè)計抓起。一般來說，最上層和最下層都不具有良好的可移植性。最上層是 GUI，大多數(shù) GUI 都不是跨平臺的，如Win32 SDK 和 MFC。最下層是操作系統(tǒng)API，大多部分操作系統(tǒng)API都是專用的。如果這兩層的代碼散布在整個軟件中，那么這個軟件的可植性將非常的差，這是不言自明的。那么如何避免這種情況呢？當(dāng)然是分層設(shè)計了：最底層采用?Adapter 模式，把不同操作系統(tǒng)的 API 封裝成一套統(tǒng)一的接口。至于封裝成類還是封裝成函數(shù)，要看你采用的 C 還是 C 寫的程序了。這看起來很簡單，其實不盡然（看完整篇文章后你會明白的），它將耗去你大量的時間去編寫代碼，去測試它們。采用現(xiàn)存的程序庫，是明智的做法，有很多這樣的庫，比如，C 庫有?glib（GNOME 的基礎(chǔ)類），C 庫有 ACE(ADAPTIVE Communication Environment)等等，在開發(fā)第一個平臺時就采用這些庫，可以大大減少移植的工作量。最上層采用 MVC 模型，分離界面表現(xiàn)與內(nèi)部邏輯代碼。把大部分代碼放到內(nèi)部邏輯里面，界面僅僅是顯示和接收輸入，即使要換一套 GUI，工作量也不大。這同時也是提高可測試性的手段之一，當(dāng)然還有其它一些附加好處。所以即使你采用 QT 或者 GTK 等跨平臺的 GUI 設(shè)計軟件界面，分離界面表現(xiàn)與內(nèi)部邏輯也是非常有用的。若做到了以上兩點，程序的可移植性基本上有保障了，其它的只是技術(shù)細(xì)節(jié)問題。2、事先熟悉各目標(biāo)平臺，合理抽象底層功能這一點是建立在分層設(shè)計之上的，大多數(shù)底層函數(shù)，像線程、同步機(jī)制和 IPC 機(jī)制等等，不同平臺提供的函數(shù)，幾乎是一一對應(yīng)的，封裝這些函數(shù)很簡單，實現(xiàn) Adapter 的工作幾乎只是體力活。然而，對于一些比較特殊的應(yīng)用，如圖形組件本身，就拿 GTK 來說吧，基于 X Window 的功能和基于Win32的功能，兩者差巨大，除了窗口、事件等基本概念外，幾乎沒有什么相同的，如果不事先了解各個平臺的特性，在設(shè)計時就精心考慮的話，抽象出來的抽口在另外一個平臺幾乎無法實現(xiàn)。3、盡量使用標(biāo)準(zhǔn)C/C 函數(shù)大多數(shù)平臺都會實現(xiàn)?POSIX(Portable Operating System Interface)規(guī)定的函數(shù)，但這些函數(shù)較原生(Native) 函數(shù)來說，性能上的表現(xiàn)可能較次一些，用起來也不如原生函數(shù)方便。但是，最好不要貪圖這種便宜而使用原生函數(shù)函數(shù)，否則搬起的石頭最終會軋到自己的腳。比如，文件操作就用 fopen 之類的函數(shù)，而不要用 CreateFile 之類的函數(shù)等。4、盡量不要使用C/C 新標(biāo)準(zhǔn)里出現(xiàn)的特性并不是所有的編譯器都支持這些特性，像 VC 就不支持 C99 里面要求的可變參數(shù)的宏，VC 對一些模板特性的支持也不全面。為了安全起見，這方面不要太激進(jìn)了。5、盡量不要使用C/C 標(biāo)準(zhǔn)里沒有明確規(guī)定的特性比如你有多個動態(tài)庫，每個動態(tài)庫都有全局對象，而且這些全局對象的構(gòu)造還有依賴關(guān)系，那你遲早會遇到麻煩的，這些全局對象構(gòu)造的先后順序在標(biāo)準(zhǔn)里是沒有規(guī)定的。在一個平臺上運(yùn)行正確，在另外一個平臺上可能莫明其妙的死機(jī)，最終還是要對程序作大量修改。6、盡量不要使用準(zhǔn)標(biāo)準(zhǔn)函數(shù)有些函數(shù)大多數(shù)平臺上都有，它們使用得太廣泛了，以至于大家都把它們當(dāng)成標(biāo)準(zhǔn)了，比如 atoi（把字符串轉(zhuǎn)換成整數(shù)）、strdup(克隆字符串)、alloca（在棧分配自動內(nèi)存）等等。不怕一萬，就怕萬一，除非明白你在做什么，否則還是別碰它們?yōu)楹谩?/span>7、注意標(biāo)準(zhǔn)函數(shù)的細(xì)節(jié)也許你不相信，即使是標(biāo)準(zhǔn)函數(shù)，拋開內(nèi)部實現(xiàn)不論，就其外在表現(xiàn)的差異也有時令人驚訝。這里略舉幾個例子：（1） int accept(int s, struct sockaddr *addr, socklen_t *addrlen);addr/ addrlen本來是輸出參數(shù)，如果是 C 程序員，不管怎么樣，你已經(jīng)習(xí)慣于初始化所有的變量，不會有問題。如果是 C 程序員，就難說了，若沒有初始化它們，程序可能莫名其妙的 crash，而你做夢也懷疑不到它頭它。這在 Win32 下沒問題，在 Linux 下才會出現(xiàn)。（2）int snprintf(char *str, size_t size, const char *format, ...);第二個參數(shù)size，在 Win32 下不包括空字符在內(nèi)，在 Linux 下包括空字符，這一個字符的差異，也可能讓你耗上幾個小時。（3） int stat(const char *file_name, struct stat *buf);這個函數(shù)本身沒有問題，問題出在結(jié)構(gòu) stat 上，st_ctime 在 Win32 下代表創(chuàng)建(create)時間，在 Linux 下代表最后修改(change)時間。（4）FILE *fopen(const char *path, const char *mode);在讀取二進(jìn)制文件，沒有什么問題。在讀取文本文件可要小心，Win32下 自動預(yù)處理，讀出來的內(nèi)容與文件實際都長度不一樣，在 Linux 則沒有問題。8、小心數(shù)據(jù)標(biāo)準(zhǔn)數(shù)據(jù)類型不少人已經(jīng)吃過 int 類型由 16 位轉(zhuǎn)變成 32 位帶來的苦頭，這已經(jīng)是陳年往事了，這里且不談。你可知道 char 在有的系統(tǒng)上是有符號的，在有的系統(tǒng)是無符號的嗎？你可知道 wchar_t 在 Win32 下是 16 位的，在 Linux 下是 32 位的嗎？你可知道有符號的 1bit 的位域，取值是 0 和 -1 而不是 0 和 1 嗎？這些貌合神離的東東，端的是神出鬼沒，一不小心著了它的道。9、最好不要使用平臺獨(dú)有的特性比如 Win32 下 DLL 可以提供一個 DllMain 函數(shù)，在特定的時間，操作系統(tǒng)的 Loader 會自動調(diào)用這個函數(shù)。這類功能很好用，但最好不要用，目標(biāo)平臺可不能保證有這種功能。10、最好不要使用編譯器特有的特性現(xiàn)代的編譯器都做很人性化，考慮得很周到，一些功能用起非常方便。像在 VC 里，你要實現(xiàn)線程局部存儲，你都不調(diào)用 TlsGetValue /Tls TlsSetValue 之類的函數(shù)，在變量前加一個 __declspec( thread ) 就行了，然而盡管在 pthread 里有類似的功能，卻不能按這種方式實現(xiàn)，所以無法移植到 Linux 下。同樣 gcc 也有很多擴(kuò)展，是在 VC 或者其它編譯器里所沒有的。11、注意平臺的特性比如:在 Win32 下的 DLL 里面，除非明確指明為 export 的函數(shù)外，其它函數(shù)對外都是不可見的。而在 Linux 下，所有的非 static 的全局變量和函數(shù)，對外全部是可見的。這要特別小心，同名函數(shù)引起的問題，讓你查上兩天也不為過。（1）目錄分隔符，在 Win32 下用’//’，在 Linux 下用’/’。（2）文本文件換行符，在 Win32 下用’/r/n’，在 Linux 下用’/n’，在 MacOS 下用’/r’。（3）字節(jié)順序（大端/小端），不同硬件平臺的字節(jié)順序可能不一樣。（4）字節(jié)對齊，在有的平臺(如x86）上，字節(jié)不對齊，無非速度慢一點，而有的平臺（如arm）上，它完全用錯誤的方式去讀取數(shù)據(jù)，而且不會給你一點提示。若出問題，可能讓你一點頭緒都沒有。12、最好清楚不同平臺的資源限制想必你還記得 DOS 下同時打開的文件個數(shù)限制在幾十個的情形吧，如今操作系統(tǒng)的功能已經(jīng)強(qiáng)大多了，但是并非沒有限制。比如 Linux 下的共享內(nèi)存默認(rèn)的最大值是 4M。若你對目標(biāo)平臺常見的資源限制了然于胸，可能有很大的幫助，一些問題很容易定位。可移植性的問題決不限于以上幾種，一方面，即使以前遇到過的問題，部份已經(jīng)忘記了。另外一方面，還有很多未知的問題，根本沒有遇到過。這里算是拋磚引玉吧，請大家補(bǔ)充。
作者：jim.li來源：https://blog.csdn.net/absurd版權(quán)歸原作者所有，如有侵權(quán)，請聯(lián)系刪除。
下載文檔
