跨平臺C++程序開發(fā)系列文章

zjzfb

/*
********************************************************************************
*
* 作者：祝飛
* 郵件：zhufei@wawton.com
* MSN： zhufei@wawton.com
* 出處：http://zhufei1980.spaces.live.co ... 29BCEF27B!121.entry
*
* 本系列文章采用類BSD協(xié)議發(fā)布：
*     無論修改與否，你都可以進(jìn)行任何目的的轉(zhuǎn)發(fā)，甚至于直接銷售，只需要滿足以下條件：
*     1. 包含作者信息（作者、郵件、MSN、出處、協(xié)議）
*     2. 未獲得授權(quán)情況下，請勿使用作者信息進(jìn)行任何目的的推廣活動(dòng)
* 違反協(xié)議的情況下，作者保留所有權(quán)利。
*
********************************************************************************
*/

總概
    跨平臺C++程序開發(fā)，顧名思義，一份相同的代碼，在不同的平臺編譯，在不同的平臺運(yùn)行。
    所謂的跨平臺，一般意義上指Windows和Unix-like平臺；
    需要跨平臺的程序，一般從Unix-like平臺跨越到Windows平臺，需要更多平臺的展示及更低廉的解決方案；
    而從計(jì)算機(jī)的方展史來看，先有Unix-like系統(tǒng)，后有Windows平臺，Windows平臺的許多系統(tǒng)接口參考了Unix-like系統(tǒng)接口；
    所以，現(xiàn)有的跨平臺解決方案，一般都偏向Unix接口；
    要進(jìn)行跨平臺開發(fā)，建議先打好Unix-like系統(tǒng)的C/C++編程基礎(chǔ)。

總概
    跨平臺C++程序開發(fā)，顧名思義，一份相同的代碼，在不同的平臺編譯，在不同的平臺運(yùn)行。
    所謂的跨平臺，一般意義上指Windows和Unix-like平臺；
    需要跨平臺的程序，一般從Unix-like平臺跨越到Windows平臺，需要更多平臺的展示及更低廉的解決方案；
    而從計(jì)算機(jī)的方展史來看，先有Unix-like系統(tǒng)，后有Windows平臺，Windows平臺的許多系統(tǒng)接口參考了Unix-like系統(tǒng)接口；
    所以，現(xiàn)有的跨平臺解決方案，一般都偏向Unix接口；
    要進(jìn)行跨平臺開發(fā)，建議先打好Unix-like系統(tǒng)的C/C++編程基礎(chǔ)。

發(fā)布地址：
http://zhufei1980.spaces.live.com/

C++循序漸進(jìn)學(xué)習(xí)之書籍推薦

目錄
    1.  跨平臺C++程序開發(fā)系列之一 開發(fā)工具選擇
    2.  跨平臺C++程序開發(fā)系列之二 MPC多平臺編譯工程文件生成工具，附實(shí)例
    3.  跨平臺C++程序開發(fā)系列之三 CppUnit自動(dòng)測試工具，附實(shí)例
    4.  跨平臺C++程序開發(fā)系列之四 Doxygen接口文檔生成，附實(shí)例
    5.  跨平臺C++程序開發(fā)系列之五 ACE跨平臺工具庫引介
    6.  跨平臺C++程序開發(fā)系列之六 DLL/so動(dòng)態(tài)庫開發(fā)基礎(chǔ)，附實(shí)例
    7.  跨平臺C++程序開發(fā)系列之七 DLL/so動(dòng)態(tài)庫開發(fā)進(jìn)階，附實(shí)例
    8.  跨平臺C++程序開發(fā)系列之八 DLL/so動(dòng)態(tài)庫開發(fā)高階之COM_CORBA本質(zhì)，附實(shí)例
    9.  跨平臺C++程序開發(fā)系列之九 多廠家支持?jǐn)?shù)據(jù)庫操作接口
    10. 跨平臺C++程序開發(fā)系列之十 GUI開發(fā)工具的選擇
    11. 跨平臺C++程序開發(fā)系列之十一 C與C++的選擇與平衡
    12. 跨平臺C++程序開發(fā)系列之十二 基于管理和預(yù)分配池的多進(jìn)程多線程服務(wù)器端程序方案
    13. 跨平臺C++程序開發(fā)系列之十三 開發(fā)架構(gòu)模式的選擇，CMM與XP的混合

注：
    跨平臺C/C++程序開發(fā)的條件宏基礎(chǔ)
    #ifdef WIN32
        ...
/*
    #elif defined( SUNOS ) // 更多平臺的定義
        ...
*/
    #else //!WIN32
        ...
    #endif //end WIN32 + !WIN32

說明：
    連載模式，慢慢補(bǔ)充，8月份完成上述文章的初稿

同時(shí)想與大家共同探討以下問題：
    1. Linux軟件開發(fā)，在大量動(dòng)態(tài)庫的情況下，避免root權(quán)限、避免依賴地獄，就是如同Windows軟件，將沖突限定于自己的程序目錄
        我個(gè)人所經(jīng)歷的Unix-like動(dòng)態(tài)庫地獄，一個(gè)體會(huì)是依賴，但更重要的一個(gè)體會(huì)是沖突：
            依賴：只好不停地到網(wǎng)上搜索各類軟件
            沖突：辛辛苦苦下載了制定版本的軟件，結(jié)果發(fā)現(xiàn)與現(xiàn)有軟件沖突，無法使用，最終放棄
        放棄的軟件多了，也就放棄了平臺，很無奈，卻是事實(shí)

        從來都不是系統(tǒng)的問題：系統(tǒng)接口幾十年如一日，不可能說變就變，而且如果變了，如何保證原先系統(tǒng)的健壯性
        也從來不是用戶的問題：用戶使用現(xiàn)有系統(tǒng)，目的就是方便，當(dāng)操作復(fù)雜度和系統(tǒng)沖突成本高于直接價(jià)格優(yōu)惠時(shí)，用戶有權(quán)利選擇另外的系統(tǒng)
        有問題的是開發(fā)軟件系統(tǒng)的人：怎么沒有找到在現(xiàn)有系統(tǒng)上滿足用戶需求的解決方案？

    關(guān)于這個(gè)方案，有了個(gè)初步解決方式，不過還有很多問題：到時(shí)會(huì)發(fā)布開源程序，歡迎大家屆時(shí)下載共同探討。

[ 本帖最后由 zjzfb 于 2009-8-22 17:42 編輯 ]

OwnWaterloo

嘿， 前幾天搜這方面的工具， 沒搜到這個(gè)。
MPC這名字取得不太好。。。。   相同詞條太多。。。。

試試先

zjzfb

原帖由 OwnWaterloo 于 2009-8-18 14:09 發(fā)表
嘿， 前幾天搜這方面的工具， 沒搜到這個(gè)。
MPC這名字取得不太好。。。。   相同詞條太多。。。。

試試先

也才今天更新發(fā)布的，現(xiàn)在重新排布了下
麻雀雖小，五臟俱全：不過如果是版本發(fā)布，或者用到其他版本庫，可能需要些許更改
有需要的話可以發(fā)郵件給我，盡量提供一些建議參考

GodPig

這個(gè)要關(guān)注一下~~~

群雄逐鹿

第10章：GUI開發(fā)工具的選擇

這個(gè)期待LZ表達(dá)一下看法。滿足下面這些條件的GUI, 目前還沒有發(fā)現(xiàn)：
1. 原生的GUI代碼
2. 在某個(gè)平臺像某個(gè)平臺
3. 輕量級的包裝，最好是header only或很小的library
4. 基于stl like的，比如有 iterator 可以遍歷窗口
5. 支持屬性操作

這里有列出大部分的GUI庫，并且一直在更新
http://www.thefreecountry.com/sourcecode/gui.shtml

yugliu

我才看第一篇“跨平臺C++程序開發(fā)系列之一 開發(fā)工具選擇” ，就發(fā)現(xiàn)一個(gè)地方寫錯(cuò)了。

1. Windows平臺采用gcc/gdb，基本不可能用來進(jìn)行商業(yè)軟件開發(fā)（Code::Blocks支持VC的原生態(tài)，可惜不能用來調(diào)試）

“Code::Blocks支持VC的原生態(tài)，可惜不能用來調(diào)試”  -- 這句。 CB支持 CDB，可以調(diào)試。

其他的還有許多地方待商榷，權(quán)作參考

zjzfb

原帖由 yugliu 于 2009-8-19 09:50 發(fā)表
我才看第一篇“跨平臺C++程序開發(fā)系列之一 開發(fā)工具選擇” ，就發(fā)現(xiàn)一個(gè)地方寫錯(cuò)了。

1. Windows平臺采用gcc/gdb，基本不可能用來進(jìn)行商業(yè)軟件開發(fā)（Code::Blocks支持VC的原生態(tài)，可惜不能用來調(diào)試）

“C ...

每個(gè)人使用各類工具，肯定會(huì)有偏頗之處
寫的系列文章之類的，和每個(gè)人所走的路相關(guān)，有些人合適，也有些人不合適，僅提供參考而已
同時(shí)歡迎共同探討各類問題和缺陷，會(huì)在文章一修改這個(gè)問題的

剛剛搜索了把CodeBlocks+CDB，條目很少，但至少看到
1. 我在使用code::blocks，在調(diào)試visual c++ 2005時(shí)報(bào)告調(diào)試器沒有找到，code::blocks默認(rèn)的vc2005調(diào)試器是cdb.exe，但是vc目錄下沒有這個(gè)。
2. Also supports MS CDB (not fully featured)。

同時(shí)，在Code::Blocks官方論壇里的一個(gè)討論帖：Unable to debug with Visual C++ 2008 Express
http://forums.codeblocks.org/index.php?topic=8454.0
看了一下，至少一些人放棄了

這里再補(bǔ)充一下自己對典型Unix-like平臺軟件的體會(huì)吧（Code::Blocks可以歸屬于這一類）：
1. 依賴軟件（庫）地獄
    基本上可以把一個(gè)用戶給搞崩潰，或者引入更多的沖突。
    我現(xiàn)在配置安裝Linux系統(tǒng)，很強(qiáng)調(diào)系統(tǒng)一致性，就是寧可用低版本的系統(tǒng)，不打任何系統(tǒng)補(bǔ)丁，也要保證所有軟件的版本一致。
2. 沒有良好的說明
    就如Code::Blocks，基本上沒有人能夠看到使用VC編譯器時(shí)關(guān)于CDB的提示；結(jié)果就是，大多數(shù)人像我一樣，用原生VC，結(jié)果直觀地發(fā)現(xiàn)沒有調(diào)試器可用，然后放棄。
    對比微軟的免費(fèi)版VC2005 Express，至少人家在顯眼的地方提示沒有PlatformSDK，需要如何按步驟操作。

至于世界上為什么那么多人選擇Windows平臺
相信很大一部分和我類似，只是需要一個(gè)可用的軟件，不需要大投入，不需要看形形色色的文檔
所需要的僅僅是打開軟件，高效地完成工作，讓自己關(guān)注于業(yè)務(wù)領(lǐng)域
這才是Linux圖形化發(fā)展的一個(gè)重要參介點(diǎn)

[ 本帖最后由 zjzfb 于 2009-8-19 12:32 編輯 ]

anders0913

mark，學(xué)習(xí)中~~

zjzfb

原帖由 群雄逐鹿 于 2009-8-19 08:58 發(fā)表
第10章：GUI開發(fā)工具的選擇

這個(gè)期待LZ表達(dá)一下看法。滿足下面這些條件的GUI, 目前還沒有發(fā)現(xiàn)：
1. 原生的GUI代碼
2. 在某個(gè)平臺像某個(gè)平臺
3. 輕量級的包裝，最好是header only或很小的library
4. 基于 ...

沒有那么多，只會(huì)選擇式地評點(diǎn)下QT+wxWidgets，基于C++，直接忽略X11和GTK

1. 原生的GUI代碼 - 自定義規(guī)則的代碼接口？QT做到這一點(diǎn)了，wxWidgets的話是類MFC規(guī)則
2. 在某個(gè)平臺像某個(gè)平臺 - wxWidgets基本做到了，所謂的Platform Native
3. 輕量級的包裝，最好是header only或很小的library - 這個(gè)沒考慮，基本只考慮PC應(yīng)用，不同的平臺接口差異太大，只用頭文件造成代碼復(fù)雜度劇升，同時(shí)內(nèi)聯(lián)造成最終程序過大
4. 基于stl like的，比如有 iterator 可以遍歷窗口 - QT/wxWidgets都已實(shí)現(xiàn)這類功能
5. 支持屬性操作 - QT/wxWidgets都已實(shí)現(xiàn)這類功能

OwnWaterloo

再頂一下， 支持lz的工作~~~

原帖由 zjzfb 于 2009-8-18 13:42 發(fā)表
1. Linux軟件開發(fā)，在大量動(dòng)態(tài)庫的情況下，避免root權(quán)限、避免依賴地獄，就是如同Windows軟件，將沖突限定于自己的程序目錄

關(guān)于這個(gè)問題。 "沖突限定于自己的程序目錄"的意思是將所有需要的dll都拷貝到exe同目錄下？
這樣……  和直接使用靜態(tài)鏈接有什么區(qū)別嗎？
也還是有一點(diǎn)區(qū)別的， 理論上來說， 替換（或者說升級）的可能性依然存在， exe的發(fā)布者， 可以測試該exe所依賴的dll的高版本是否會(huì)產(chǎn)生沖突， 并提出可以使用的dll版本的組合，讓用戶自由選擇dllA的x版本、dllB的y版本。
但有多少公司真這樣做了？  而且就方便來說， 還是整體打包下載較好。

而且， dll的另一個(gè)優(yōu)勢： 共享代碼、減少內(nèi)存使用，  肯定是要被抹殺了。


我覺得吧， 如果某個(gè)庫打算做成dll的形式， “對以前版本的兼容性”就是一種義務(wù)。
Windows下諸多API， 要么操作的是HANLDE, 要么是一個(gè)incomplete的指針。
一旦出現(xiàn)定義完整的結(jié)構(gòu)體， 第1個(gè)成員必定是size， 并且使用前必須 size = sizeof(S);
這不是沒有道理的。

如果大部分API都能做到對以前版本兼容， 具體的說， 是“繼續(xù)滿足以前版本與客戶代碼之間的契約”， 那很多問題就簡單多了， 往上升級即可。
有點(diǎn)天真的想法……