VisualC++與DelphiC++Builder之比較及未來的發(fā)展前景之我見

1、由于Delphi與C+Builder同為Inprise公司產(chǎn)品，共享集成開發(fā)界面(IDE)，而且 使用同一套VCL框架(這一點(diǎn)最關(guān)鍵)，它們帶的調(diào)試器、PVCS/TeamSource團(tuán)隊(duì)開發(fā)支持 、數(shù)據(jù)庫(kù)引擎及企業(yè)版中集成的其它高級(jí)功能等都是相同的，所以本文將其與C+Build er歸入同一陣線。我在網(wǎng)上見到一些Delphi程序員認(rèn)為C+Builder與VC比較接近， 這是個(gè)誤解。事實(shí)上，Delphi和C+Builder除了使用的語(yǔ)言不同，其余幾乎都相同。為 了避免話題轉(zhuǎn)移到C+語(yǔ)言與Object Pascal語(yǔ)言(即Delphi所用的語(yǔ)言)的比較，下文主 要對(duì)比分析Visual C+與C+B

2、uilder。 首先，從它們的應(yīng)用程序框架(Application Frame，有時(shí)也稱為對(duì)象框架)進(jìn)行比 較。Visual C+采用的框架是MFC。MFC不僅僅是人們通常理解的一個(gè)類庫(kù)。(同樣，Del phi和C+Builder使用的VCL的概念也不僅僅是一個(gè)控件庫(kù)。)你如果選擇了MFC，也就選 擇了一種程序結(jié)構(gòu)，一種編程風(fēng)格。MFC早在Windows 3.x的時(shí)代就出現(xiàn)了，那時(shí)的Visu al C+還是16位的。經(jīng)過這些年的不斷補(bǔ)充和完善，MFC已經(jīng)十分成熟。但由于原型出現(xiàn) 得比較早，MFC相比于VCL落后了一個(gè)時(shí)代。盡管微軟對(duì)MFC的更新沒有停止，我也經(jīng)常讀 到持只要Windows不過時(shí)

3、，MFC就不會(huì)過時(shí)之類觀點(diǎn)的文章，但就象Inprise(原Borl and)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。如果MFC青春永駐，微軟的開發(fā)人 員也不會(huì)私自開發(fā)出基于ATL的WTL呀。當(dāng)然，WTL的地位不能和MFC比，它并不是微 軟官方支持的框架，封裝的功能也相當(dāng)有限。但至少也反襯出了MFC存在的不足。 我以為，最能體現(xiàn)一個(gè)應(yīng)用程序框架的先進(jìn)性的是它的委托模型，即對(duì)Windows消 息的封裝機(jī)制。(對(duì)Windows API的封裝就不用說了吧。大同小異，也沒什么技術(shù)含量。 如果高興，你也可以自己寫一個(gè)類庫(kù)來封裝。但對(duì)Windows消息驅(qū)動(dòng)機(jī)制的封裝就不是那 么容易的了。)最自然的

4、封裝方式是采用虛成員函數(shù)。如果要響應(yīng)某個(gè)消息就重載相應(yīng)的 虛函數(shù)。但出乎我的意料，MFC采用的是古老的宏定義方法。用宏定義方法的好處是 省去了虛函數(shù)VTable的系統(tǒng)開銷。(由于Windows的消息種類很多，開銷不算太小。)不過 帶來的缺點(diǎn)就是映射不太直觀。好在較新版本VC帶的ClassWizard可以自動(dòng)生成消息映射 代碼，使用起來還是比較方便的。但和VCL的委托模型相比，MFC的映射方法就顯得太落 后了。而C+Builder對(duì)C+語(yǔ)言進(jìn)行了擴(kuò)展，以便引入組件、事件處理、屬性等新特性。 由于功夫做在編譯器級(jí)，生成的源代碼就顯得十分簡(jiǎn)潔。但是由于擴(kuò)展的非標(biāo)準(zhǔn)特性， 使用VCL的C+Builde

5、r的源代碼無法被其它編譯器編譯。而MFC的功夫做在源代碼級(jí)，雖 然消息映射代碼較為復(fù)雜且不直觀，但兼容性非常好。只要你有MFC庫(kù)的源代碼(隨VC企 業(yè)版的光盤提供)，你的MFC程序理論上用任何符合ANSI標(biāo)準(zhǔn)的編譯器均可編譯通過。C+ +Builder 3以上版本可以原封不動(dòng)直接編譯Visual C+程序，很多人認(rèn)為這是C+Build er的兼容性好，實(shí)際上很大程度應(yīng)歸功于MFC的兼容性好。微軟辛辛苦苦用標(biāo)準(zhǔn)方法寫M FC，卻為對(duì)手制造了方便。不知他們作何感想？而因?yàn)镃+Builder對(duì)語(yǔ)言作了擴(kuò)展，VC 不能編譯C+Builder的程序?？磥碓谶@方面VC要輸給C+Builder了。而且VCL

6、所支持的組 件、屬性等都是MFC所缺乏的特性。雖然VC也能支持組件，但要通過AppWizard先生成一 個(gè)包裹類(wrapper)，不如VCL來得簡(jiǎn)潔。有很多人使用C+Builder就是沖著控件板 上那一大堆組件來的，VC雖然能使用的組件也很多(也許不比C+Builder少)，但由于不 方便而對(duì)RAD程序員沒有吸引力。 C+Builder的VCL比Visual C+的MFC先進(jìn)的另一個(gè)特性是異常處理。但令人啼笑 皆非的是，它的異常處理代碼有bug，有時(shí)會(huì)無端拋出異常。不知道在最新的版本中有沒 有改正了。而VC的框架MFC也不是一無是處。經(jīng)歷了那么多年的發(fā)展和完善，MFC功能非 常全面，而且十分

7、穩(wěn)定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工 具幫助你避開這些bug。如此規(guī)模的一個(gè)類庫(kù)，能做到這一點(diǎn)不容易。不要小看了這一點(diǎn) ，很多專業(yè)程序員就是為這個(gè)選擇VC的。而C+Builder的VCL的bug就相對(duì)較多了，而且 有些它自己帶的示例程序都有錯(cuò)誤。看來Inprise還有很長(zhǎng)的路要走。 再?gòu)乃鼈兊囊子眯员容^。VC有ClassWizard、SourceBrowser等一系列工具，還附 帶Visual SourceSafe、Visual Modeler等強(qiáng)大的工具，易用性非常好。(VC自帶建模工 具Visual Modeler，也許說明了它才是工程級(jí)的開發(fā)平臺(tái)，與C+Bu

8、ilder的定位不同。 )它所帶的MSDN這部開發(fā)者的百科全書更是讓你沒有找不到的，只有想不到的。 而且它的AutoComplete之類小功能也比C+Builder要體貼。C+Builder的新版本雖然也 提供了這一功能，但它的提示要等好幾秒才出來，有時(shí)你不經(jīng)意間把鼠標(biāo)停在某一處， 也要等硬盤響好幾秒，這可是在566Mhz的賽揚(yáng)II上呀。不要笑我瑣碎，有時(shí)一個(gè)開發(fā)工 具的成熟和易用，就是從這些小地方體現(xiàn)出來的。C+Builder作為RAD工具，理應(yīng)強(qiáng)調(diào)易 用性。但與VC相比還顯出不成熟。這是不應(yīng)該的。 再來看看它們的可移植性。Inprise正在開發(fā)C+Builder和Delphi的Linux版

9、本， 代號(hào)為Kylix。也許通過Kylix，用VCL構(gòu)架編寫的Windows程序向Linux移植成為可能。但 這只是可能。因?yàn)樵谀壳癐nprise的兼容性工作做得并不好。C+Builder可以編譯VC程序 還要多謝微軟使用標(biāo)準(zhǔn)方法寫MFC，而它自己各個(gè)版本之間兼容性卻不太好。低版本的C +Builder不能使用高版本的VCL組件(這還別去說它)，而高版本的C+Builder竟然不能 使用低版本的VCL組件。真是豈有此理，我很少看見軟件有不向下兼容的。如果Windows 98不能運(yùn)行95的程序，Windows 95不能運(yùn)行3.x的程序，Win 3.x不能運(yùn)行DOS程序，你 還會(huì)用Windows嗎

10、？如果不是C+Builder的其它某些方面太出色，光是這個(gè)向下不兼容就 足以讓我拋棄它。而且雖說通過捆綁編譯器，C+Builder可以編譯Delphi的Object Pas cal代碼，但C+Builder仍不能使用為Delphi開發(fā)的VCL組件。所以一個(gè)組件有for D1/D 2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著C+Builder版本的升級(jí)可 能還會(huì)增加。希望Inprise能先解決同門兄弟的兼容性問題。而微軟的VC就沒有這類問題 。MFC1.0的程序也可以毫無障礙地在VC6.0下編譯通過。 再來看看它們的前景吧。實(shí)際上，技術(shù)的進(jìn)步在很多時(shí)候是此消彼長(zhǎng)的

11、。當(dāng)初Bo rland的Turbo C和Borland C+幾乎是唯一的選擇。微軟的Quick C(現(xiàn)在還有人知道這個(gè) 產(chǎn)品嗎？)和Microsoft C/C+從來也沒有成為過主流。但Borland C+又流行了多少年呢 ？不久就被新崛起的Microsoft Visual C/C+壓下去了?，F(xiàn)在的C+Builder又有后來居 上的態(tài)勢(shì)，如果穩(wěn)定性再提高一些，bug再少一些，有希望成為主流。但I(xiàn)nprise的總體 實(shí)力不及微軟，這也是無可爭(zhēng)議的。從C+Builder 5的Release Notes中的Known Issue s部分，以及它們的幫助文檔的規(guī)模和質(zhì)量都可以看出。(哪個(gè)同類產(chǎn)品的幫助文

12、檔能和 MSDN比呢？)Inprise公司應(yīng)從Netscape吸取教訓(xùn)，不要讓C+Builder成為第二個(gè)Netsca pe Communicator。(Communicator也是一度技術(shù)領(lǐng)先，甚至曾占據(jù)了大部分的瀏覽器市 場(chǎng)，但似乎后勁不足，而且 6.0 PR1、2中bug多多，現(xiàn)在被IE壓得抬不起頭。)C+Buil der是Inprise的旗艦產(chǎn)品之一，前景應(yīng)當(dāng)還是比較樂觀的，而且Inprise已經(jīng)在向Linux 進(jìn)軍了，而微軟還遲遲沒有動(dòng)作，難道非要到Linux成燎原之勢(shì)(或許已經(jīng)成燎原之勢(shì)了 )才會(huì)奮起占領(lǐng)這個(gè)新興市場(chǎng)？似乎他們對(duì)Linux的態(tài)度與幾年前對(duì)互聯(lián)網(wǎng)的興起的反應(yīng) 遲緩有些

13、相似。但后來.唉，真希望Inprise不要步Netscape的后塵。C+Builder是 一個(gè)很有前途的開發(fā)工具。遺憾的是，Inprise公司Delphi的創(chuàng)始人已經(jīng)跳槽到微軟去主 持Visual J+項(xiàng)目了。但愿對(duì)Inprise沖擊不會(huì)太大。微軟的Visual C+的前景又怎樣呢 ？Visual Studio 7.0不久就要推出了。不知能不能在保持穩(wěn)定性的同時(shí)在技術(shù)的先進(jìn)性 上趕上C+Builder。另外，這一版本將加強(qiáng)網(wǎng)絡(luò)開發(fā)的特性?？磥砦④涬m然被判解體， 開發(fā)實(shí)力可是一點(diǎn)沒打折扣。 就技術(shù)(主要指應(yīng)用框架)來說，C+Builder目前領(lǐng)先于Visual C+。但多多少少 的不盡人意之處讓

14、我對(duì)Inprise想說愛你不容易。而VC盡管發(fā)展到今日已十分完善， 但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。WFC是支持組件 、屬性和事件的，但那是Visual J+里邊用的；ATL也很先進(jìn)，但是用來進(jìn)行COM/Activ eX開發(fā)的；基于ATL的WTL也不錯(cuò)，可惜是非官方作品，也未必比VCL先進(jìn)。微軟最近提出 了C#(讀作C Sharp)語(yǔ)言方案，但那屬于和Java同一類的東西?？磥硎墙馃o足赤啊。根據(jù) 你的需要做選擇吧。實(shí)際上Visual C+和C+Builder也不是單單競(jìng)爭(zhēng)關(guān)系。它們?cè)谠S多 領(lǐng)域并不重疊，甚至是互補(bǔ)的。到底怎樣取舍，要根據(jù)你的項(xiàng)目特性決定。如

15、果你開發(fā) 系統(tǒng)底層的東西，需要極好的兼容性和穩(wěn)定性，選Visual C+吧。你可以只調(diào)用Window s的各種API，不用MFC。如果你寫傳統(tǒng)的Windows桌面應(yīng)用程序，Visual C+的MFC框架是 正統(tǒng)的選擇。如果你為企業(yè)開發(fā)數(shù)據(jù)庫(kù)、信息管理系統(tǒng)等高層應(yīng)用(高層是相對(duì) 于低層/底層而言的，不是說技術(shù)高級(jí)或低級(jí)。)而且有比較緊的期限限制，選C+B uilder比較好。如果你用的語(yǔ)言是Object Pascal，Delphi是唯一的選擇(如果GNU Pasc al等免費(fèi)編譯器不考慮的話)。如果你原先用Delphi(Object Pascal語(yǔ)言)，現(xiàn)在想改學(xué) C+，應(yīng)當(dāng)先用C+Builde

16、r。熟悉的界面和相同的框架會(huì)讓你的轉(zhuǎn)軌事半功倍。另外，雖說MFC已顯落后，但不是說它不值得學(xué)。事實(shí)上，不學(xué)MFC就等于沒學(xué)VC 。利用MFC框架開發(fā)程序仍然是目前開發(fā)桌面應(yīng)用的主流模式，而且還會(huì)保持相當(dāng)長(zhǎng)的時(shí) 間。即使你不使用MFC框架，花點(diǎn)時(shí)間學(xué)習(xí)一下MFC的封裝機(jī)制對(duì)你熟悉C+的OOP機(jī)制和 Windows底層功能也是很有好處的 作為程序員等級(jí)評(píng)判的標(biāo)準(zhǔn)之一c/c+(不管是mfc還是bcb)將 會(huì)讓位給三種編程語(yǔ)言,1.sun的java2.windows平臺(tái)上的c#3.xml 為什么這么說呢,我認(rèn)為最大理由是目前的應(yīng)用程序正在從基于獨(dú)立的操作系統(tǒng),傳向 基于internet平臺(tái). 我們以前

17、開發(fā)應(yīng)用程序都是依賴于平臺(tái)的功能調(diào)用,mfc,bcb都是這樣.而現(xiàn)在日益火熱 的internet編程卻最不想關(guān)心的就是某一個(gè)平臺(tái)的調(diào)用,譬如說要實(shí)現(xiàn)b2b的電子商務(wù)那 么就需要做不同平臺(tái)的集成,如果我是程序員我最care的就是如何實(shí)現(xiàn)商務(wù)邏輯 而不是各種平臺(tái)之間的通信和管理.那么我們最迫切需要的就是一種與各種平臺(tái)調(diào)用無 關(guān)的語(yǔ)言,這中語(yǔ)言只注重程序邏輯的設(shè)計(jì)而不涉及平臺(tái)的調(diào)用.而我們熟悉的c/c+卻恰 恰不是為這個(gè)而設(shè)計(jì)的(赫赫這也不能怪c/c+在70年代誰(shuí)能知道現(xiàn)在internet的情況呢 ).c/c+的最初設(shè)計(jì)目的是為了設(shè)計(jì)unix產(chǎn)生一種介于匯編和高級(jí)語(yǔ)言之間的一種開發(fā)高 效而性能不低的

18、語(yǔ)言.他要比其他任何高級(jí)語(yǔ)言都要關(guān)心系統(tǒng)的物理結(jié)構(gòu),譬如一直是毀 譽(yù)攙半的指針.指針之所以強(qiáng)大就是應(yīng)為涉及了系統(tǒng)物理內(nèi)存的管理.他可以使得程序員 和系統(tǒng)之間成為一種半透明狀態(tài).但是就是這種半透明的狀態(tài)讓指針帶來了更多的不穩(wěn)定 性. c/c+在面向Internet的編程中卻無任何優(yōu)勢(shì)可言.跨平臺(tái)的電子商務(wù)軟件最害怕顧及 各種平臺(tái)之間的天差地別的系統(tǒng)調(diào)用,最害怕時(shí)不時(shí)的由于內(nèi)存泄漏而crash.c/c+的優(yōu) 勢(shì)在這里卻成為了劣勢(shì).即使在windows平臺(tái)上開發(fā)基于windows dna的solution 用的最多的還是vb做的dcom而不是vc的atl做的dcom,因?yàn)閏/c+雖然高效但是太容易

19、出錯(cuò),如果不是很小心的釋放內(nèi)存nt很快就會(huì)資源不足. java就是最先看到這種情況,他用jvm實(shí)現(xiàn)了平臺(tái)無關(guān)用內(nèi)存回收實(shí)現(xiàn)了穩(wěn)定健壯.但是 相當(dāng)多的c/c+程序員抱怨java太慢了.的確即使到j(luò)ava2速度仍然是一個(gè)大問題.我曾經(jīng) 是一個(gè)c/c+堅(jiān)決擁護(hù)者在許多論壇里和java程序員打筆仗.但是我逐漸意識(shí)到面對(duì)與in ternet平臺(tái)而不是特定的操作系統(tǒng)的時(shí)候java的速度問題往往是一個(gè)小小的瑕疵.我們可 以想象那一個(gè)電子商務(wù)網(wǎng)站會(huì)用我們手頭的pc做服務(wù)器,他們不是sun的e1000就是ibm的 risc6000.在這種平臺(tái)上java這點(diǎn)速度問題只是a peice of cake.程序員只需要

20、專注與商 務(wù)邏輯的編程,而不必要關(guān)心數(shù)組是否越界,對(duì)象內(nèi)存是否釋放更不需要關(guān)心是不是unix 和windows的系統(tǒng)調(diào)用不一樣. 微軟的c#可以說是一種java與c/c+的雜合體,他可以回收內(nèi)存,可以平臺(tái)無關(guān).但是 他又可以實(shí)現(xiàn)一些java沒有的功能譬如在標(biāo)記的程序段內(nèi)用指針自己管理內(nèi)存,可以實(shí) 現(xiàn)操作符的重載等等.為什么要這樣做我想也許c#還肩負(fù)了一定的面向操作系統(tǒng)開發(fā)的任 務(wù)例如winform.他基本上的思想和java類似,但是實(shí)現(xiàn)的方法又不一樣他不通過jvm解釋 中間代碼,而是吧源代碼編譯成p代碼然后通過CLS庫(kù)和JIT在平臺(tái)上及時(shí)編譯為100%的本 地代碼來執(zhí)行.他的pe代碼是獨(dú)立于平

21、臺(tái)的,但是cls和jit卻根據(jù)不同的平臺(tái)而設(shè)計(jì).因此 c#的平臺(tái)獨(dú)立有點(diǎn)類似于c/c+在不同平臺(tái)上的移植使得c#比java來的更快.而且微軟還 許諾cls和jit不僅針對(duì)c#還可以針對(duì)任何語(yǔ)言譬如pascal,smaltalk,basic因此將來有可 能所有的編程語(yǔ)言都是可以平臺(tái)無關(guān)的(ms真是毒,所有的語(yǔ)言都平臺(tái)無關(guān)java還有什么 優(yōu)勢(shì)呢,據(jù)說ms正在開發(fā)基于pascal smaltalk的asp+). xml很多人可能認(rèn)為與html相類似的語(yǔ)言和c/c+,java,c#完全不在一個(gè)檔次上的語(yǔ)言 .其實(shí)不然.我們知道不管是c#還是java都是通過統(tǒng)一地層計(jì)算來實(shí)現(xiàn)平臺(tái)無關(guān).那就必須 在性能

22、上付出一點(diǎn)代價(jià).而xml卻能夠?qū)崿F(xiàn)不同的語(yǔ)言之間的調(diào)用.譬如說一個(gè)網(wǎng)占用jav a用bean實(shí)現(xiàn)一個(gè)出貨功能,另一個(gè)網(wǎng)站用dcom實(shí)現(xiàn)一個(gè)入庫(kù)功能 .如果這個(gè)網(wǎng)站需要實(shí) 現(xiàn)b2b,用一般的方式就是在他們之間寫轉(zhuǎn)換程序.而xml通過標(biāo)記語(yǔ)言來描述各自的借口 特性.兩端通過解析xml文本來實(shí)現(xiàn)互相的調(diào)用,無需任何中間轉(zhuǎn)換程序 只要一張xml文本就能實(shí)現(xiàn)bean和dcom之間的通訊(要說清楚其中的機(jī)理,需要很多xml 概念如果有興趣可以到/xml或者去看看).目前ms的.ne t中最核心的技術(shù)soap就是完全基于xml的遠(yuǎn)過程調(diào)用. 介紹了那么多可能有點(diǎn)跑題,其實(shí)我最想說的就是21世紀(jì)的程序員應(yīng)該從面向操作系統(tǒng) 的傳統(tǒng)方法中走出來,學(xué)習(xí)一點(diǎn)如何面向Intern