|
本文就試圖從技術(shù)水平、易用性、穩(wěn)定性、發(fā)展前景等對(duì)Visual C++和C++Builder(Delphi)這兩個(gè)重量級(jí)開(kāi)發(fā)工具進(jìn)行比較 由于Delphi與c++Builder同為Inprise 首先，從它們的應(yīng)用程序框架(Application Frame，有時(shí)也稱為對(duì)象框架)進(jìn)行比較。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的一個(gè)類庫(kù)。(同樣，Delphi和C++Builder使用的VCL的概念也不僅僅是一個(gè)控件庫(kù)。)你如果選擇了MFC，也就選擇了一種程序結(jié)構(gòu)，一種 我以為，最能體現(xiàn)一個(gè)應(yīng)用程序框架的先進(jìn)性的是它的委托模型，即對(duì)Windows消息的封裝機(jī)制。(對(duì)Windows API的封裝就不用說(shuō)了吧。大同小異，也沒(méi)什么技術(shù)含量。如果高興，你也可以自己寫(xiě)一個(gè)類庫(kù)來(lái)封裝。但對(duì)Windows消息驅(qū)動(dòng)機(jī)制的封裝就不是那么容易的了。)最自然的封裝方式是采用虛成員函數(shù)。如果要響應(yīng)某個(gè)消息就重載相應(yīng)的虛函數(shù)。但出乎我的意料，MFC采用的是“古老”的宏定義方法。用宏定義方法的好處是省去了虛函數(shù)VTable的系統(tǒng)開(kāi)銷。(由于Windows的消息種類很多，開(kāi)銷不算太小。)不過(guò)帶來(lái)的缺點(diǎn)就是映射不太直觀。好在較新版本VC帶的ClassWizard可以自動(dòng)生成消息映射代碼，使用起來(lái)還是比較方便的。但和VCL的委托模型相比，MFC的映射方法就顯得太落后了。而C++Builder對(duì)C++語(yǔ)言進(jìn)行了擴(kuò)展，以便引入組件、事件處理、屬性等新特性。由于功夫做在編譯器級(jí)，生成的源代碼就顯得十分簡(jiǎn)潔。但是由于擴(kuò)展的非標(biāo)準(zhǔn)特性，使用VCL的C++Builder的源代碼無(wú)法被其它編譯器編譯。而MFC的功夫做在源代碼級(jí)，雖然消息映射代碼較為復(fù)雜且不直觀，但兼容性非常好。只要你有MFC庫(kù)的源代碼(隨VC C++Builder的VCL比Visual C++的MFC先進(jìn)的另一個(gè)特性是異常處理。但令人啼笑皆非的是，它的異常處理代碼有bug，有時(shí)會(huì)無(wú)端拋出異常。不知道在最新的版本中有沒(méi)有改正了。而VC的框架MFC也不是一無(wú)是處。經(jīng)歷了那么多年的發(fā)展和完善，MFC功能非常全面，而且十分穩(wěn)定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工具幫助你避開(kāi)這些bug。如此規(guī)模的一個(gè)類庫(kù)，能做到這一點(diǎn)不容易。不要小看了這一點(diǎn)，很多 再?gòu)乃鼈兊囊子眯员容^。VC有ClassWizard、SourceBrowser等一系列工具，還附帶Visual SourceSafe、Visual Modeler等強(qiáng)大的工具，易用性非常好。(VC自帶建模工具Visual Modeler，也許說(shuō)明了它才是工程級(jí)的開(kāi)發(fā)平臺(tái)，與C++Builder的 再來(lái)看看它們的可移植性。Inprise正在開(kāi)發(fā)C++Builder和Delphi的Linux版本，代號(hào)為Kylix。也許通過(guò)Kylix，用VCL構(gòu)架編寫(xiě)的Windows程序向linux移植成為可能。但這只是可能。因?yàn)樵谀壳癐nprise的兼容性 再來(lái)看看它們的前景吧。實(shí)際上，技術(shù)的進(jìn)步在很多時(shí)候是此消彼長(zhǎng)的。當(dāng)初Borland的Turbo C和Borland C++幾乎是唯一的選擇。微軟的Quick C和Microsoft C/C++從來(lái)也沒(méi)有成為過(guò)主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++壓下去了?，F(xiàn)在的C++Builder又有后來(lái)居上的態(tài)勢(shì)，如果穩(wěn)定性再提高一些，bug再少一些，有希望成為主流。但I(xiàn)nprise的總體實(shí)力不及微軟，這也是無(wú)可爭(zhēng)議的。從C++Builder 5的Release Notes中的Known Issues部分，以及它們的幫助文檔的規(guī)模和質(zhì)量都可以看出。(哪個(gè)同類產(chǎn)品的幫助文檔能和MSDN比呢？)Inprise公司應(yīng)從Netscape吸取教訓(xùn)，不要讓C++Builder成為第二個(gè)Netscape Communicator。(Communicator也是一度技術(shù)領(lǐng)先，甚至曾占據(jù)了大部分的瀏覽器市場(chǎng)，但似乎后勁不足，現(xiàn)在被IE壓得抬不起頭。)C++Builder是Inprise的旗艦產(chǎn)品之一，前景應(yīng)當(dāng)還是比較樂(lè)觀的，而且Inprise已經(jīng)在向Linux進(jìn)軍了，而微軟還遲遲沒(méi)有動(dòng)作，難道非要到Linux成燎原之勢(shì)(或許已經(jīng)成燎原之勢(shì)了)才會(huì)奮起占領(lǐng)這個(gè)新興市場(chǎng)？似乎他們對(duì)Linux的態(tài)度與幾年前對(duì)互聯(lián)網(wǎng)的興起的反應(yīng)遲緩有些相似。但后來(lái)......唉，真希望Inprise不要步Netscape的后塵。C++Builder是一個(gè)很有前途的開(kāi)發(fā)工具。遺憾的是，Inprise公司Delphi的創(chuàng)始人已經(jīng)跳槽到微軟去主持Visual J++ 就技術(shù)(主要指應(yīng)用框架)來(lái)說(shuō)，C++Builder目前領(lǐng)先于Visual C++。但多多少少的不盡人意之處讓我對(duì)Inprise“想說(shuō)愛(ài)你不容易”。而VC盡管發(fā)展到今日已十分完善，但MFC框架已是明日黃花了。如果不使用MFC，目前又沒(méi)有合適的替代品。WFC是支持組件、屬性和事件的，但那是Visual J++里邊用的；ATL也很先進(jìn)，但是用來(lái)進(jìn)行COM/ActiveX開(kāi)發(fā)的；基于ATL的WTL也不錯(cuò)，可惜是非官方作品，也未必比VCL先進(jìn)。微軟最近提出了C#(讀作C Sharp)語(yǔ)言方案，但那屬于和Java同一類的東西?？磥?lái)是金無(wú)足赤啊。根據(jù)你的需要做選擇吧。實(shí)際上Visual C++和C++Builder也不是單單競(jìng)爭(zhēng)關(guān)系。它們?cè)谠S多領(lǐng)域并不重疊，甚至是互補(bǔ)的。到底怎樣取舍，要根據(jù)你的項(xiàng)目特性決定。如果你開(kāi)發(fā)系統(tǒng)底層的東西，需要極好的兼容性和穩(wěn)定性，選Visual C++吧。你可以只調(diào)用Windows的各種API，不用MFC。如果你寫(xiě)傳統(tǒng)的Windows桌面應(yīng)用程序，Visual C++的MFC框架是“正統(tǒng)”的選擇。如果你為企業(yè)開(kāi)發(fā)數(shù)據(jù)庫(kù)、信息管理系統(tǒng)等高層應(yīng)用(“高層”是相對(duì)于“低層/底層”而言的，不是說(shuō)技術(shù)高級(jí)或低級(jí)。)而且有比較緊的期限限制，選C++Builder比較好。如果你用的語(yǔ)言是Object Pascal，Delphi是唯一的選擇(如果GNU Pascal等免費(fèi)編譯器不考慮的話)。如果你原先用Delphi(Object Pascal語(yǔ)言)，現(xiàn)在想改學(xué)C++，應(yīng)當(dāng)先用C++Builder。熟悉的界面和相同的框架會(huì)讓你的轉(zhuǎn)軌事半功倍。 另外，雖說(shuō)MFC已顯落后，但不是說(shuō)它不值得學(xué)。事實(shí)上，不學(xué)MFC就等于沒(méi)學(xué)VC。利用MFC框架開(kāi)發(fā)程序仍然是目前開(kāi)發(fā)桌面應(yīng)用的主流模式，而且還會(huì)保持相當(dāng)長(zhǎng)的時(shí)間。即使你不使用MFC框架，花點(diǎn)時(shí)間 |
|
|
