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

2021-04-24 23:07:23 字數 3339 閱讀 2330

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 inte***ce)規定的函式,但這些函式較原生(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。若你對目標平台常見的資源限制了然於胸,可能有很大的幫助,一些問題很容易定位

編寫可移植C C 程式要點

c c 自誕生以來就受到廣大程式設計師的喜愛,編寫c c 程式容易,但寫好程式不容易,寫好可移植程式更不容易。如何做到程式在不同環境的移植呢?這裡面有技巧。1.分層設計,隔離平台相關的 就像可測試性一樣,可移植性也要從設計抓起。一般來說,最上層和最下層都不具有良好的可移植性。最上層是gui,大多數g...

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

1.分層設計,隔離平台相關的 就像可測試性一樣,可移植性也要從設計抓起。一般來說,最上層和最下層都不具有良好的可移植性。最上層是gui,大多數gui都不是跨平台的,如win32 sdk和mfc。最下層是作業系統api,大多部分作業系統api都是專用的。如果這兩層的 散布在整個軟體中,那麼這個軟體的可...

可移植C C 設計

1.分層設計,隔離平台相關的 就像可測試性一樣,可移植性也要從設計抓起。一般來說,最上層和最下層都不具有良好的可移植性。最上層是gui,大多數gui都不是跨平台的,如win32 sdk和mfc。最下層是作業系統api,大多部分作業系統api都是專用的。如果這兩層的 散布在整個軟體中,那麼這個軟體的可...