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

xuequansongmo

1.分層設(shè)計，隔離平臺相關(guān)的代碼。就像可測試性一樣，可移植性也要從設(shè)計抓起。一般來說，最上層和最下層都不具有良好的可移植性。最上層是GUI，大多數(shù)GUI都不是跨平臺的，如Win32 SDK和MFC。最下層是操作系統(tǒng)API，大多部分操作系統(tǒng)API都是專用的。
　　如果這兩層的代碼散布在整個軟件中，那么這個軟件的可植性將非常的差，這是不言自明的。那么如何避免這種情況呢？當然是分層設(shè)計了：
　　最底層采用Adapter模式，把不同操作系統(tǒng)的API封裝成一套統(tǒng)一的接口。至于封裝成類還是封裝成函數(shù)，要看你采用的C還是C++寫的程
序了。這看起來很簡單，其實不盡然（看完整篇文章后你會明白的），它將耗去你大量的時間去編寫代碼，去測試它們。采用現(xiàn)存的程序庫，是明智的做法，有很多
這樣的庫，比如，C庫有g(shù)lib（GNOME的基礎(chǔ)類），C++庫有ACE(ADAPTIVE Communication Environment)等
等，在開發(fā)第一個平臺時就采用這些庫，可以大大減少移植的工作量。
　　最上層采用MVC模型，分離界面表現(xiàn)與內(nèi)部邏輯代碼。把大部分代碼放到內(nèi)部邏輯里面，界面僅僅是顯示和接收輸入，即使要換一套GUI，工作量
也不大。這同時也是提高可測試性的手段之一，當然還有其它一些附加好處。所以即使你采用QT或者GTK+等跨平臺的GUI設(shè)計軟件界面，分離界面表現(xiàn)與內(nèi)
部邏輯也是非常有用的。
　　若做到了以上兩點，程序的可移植性基本上有保障了，其它的只是技術(shù)細節(jié)問題。
　　2.事先熟悉各目標平臺，合理抽象底層功能。這一點是建立在分層設(shè)計之上的，大多數(shù)底層函數(shù)，像線程、同步機制和IPC機制等等，不同平臺提
供的函數(shù)，幾乎是一一對應(yīng)的，封裝這些函數(shù)很簡單，實現(xiàn)Adapter的工作幾乎只是體力活。然而，對于一些比較特殊的應(yīng)用，如圖形組件本身，就拿
GTK+來說吧，基于X Window的功能和基于Win32的功能，兩者差巨大，除了窗口、事件等基本概念外，幾乎沒有什么相同的，如果不事先了解各個
平臺的特性，在設(shè)計時就精心考慮的話，抽象出來的抽口在另外一個平臺幾乎無法實現(xiàn)。
　　3.盡量使用標準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++新標準里出現(xiàn)的特性。并不是所有的編譯器都支持這些特性，像VC就不支持C99里面要求的可變參數(shù)的宏，VC對一些模板特性的支持也不全面。為了安全起見，這方面不要太激進了。
　　5.盡量不要使用C/C++標 準里沒有明確規(guī)定的特性。比如你有多個動態(tài)庫，每個動態(tài)庫都有全局對象，而且這些全局對象的構(gòu)造還有依賴關(guān)
系，那你遲早會遇到麻煩的，這些全局對象構(gòu)造的 先后順序在標準里是沒有規(guī)定的。在一個平臺上運行正確，在另外一個平臺上可能莫明其妙的死機，最終還是要
對程序作大量修改。
               
               
               

本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u/15067/showart_1904495.html