Visual C++與Delphi/C++Builder之比較及未來(lái)的發(fā)展前景之我見(jiàn)

首先，從它們的應(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)過(guò)這些年的不斷補(bǔ)充和完善，MFC已經(jīng)十分成熟。但由于原型出現(xiàn) 
得比較早，MFC相比于VCL落后了一個(gè)時(shí)代。盡管微軟對(duì)MFC的更新沒(méi)有停止，我也經(jīng)常讀 
到持"只要Windows不過(guò)時(shí)，MFC就不會(huì)過(guò)時(shí)"之類觀點(diǎn)的文章，但就象Inprise(原Borl 
and)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。如果MFC青春永駐，微軟的開(kāi)發(fā)人 
員也不會(huì)"私自"開(kāi)發(fā)出基于ATL的WTL呀。當(dāng)然，WTL的地位不能和MFC比，它并不是微 
軟官方支持的框架，封裝的功能也相當(dāng)有限。但至少也反襯出了MFC存在的不足。 

我以為，最能體現(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)銷(xiāo)。(由于Windows的消息種類很多，開(kāi)銷(xiāo)不算太小。)不過(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企 
業(yè)版的光盤(pán)提供)，你的MFC程序理論上用任何符合ANSI標(biāo)準(zhǔn)的編譯器均可編譯通過(guò)。C+ 
+Builder 3以上版本可以原封不動(dòng)直接編譯Visual C++程序，很多人認(rèn)為這是C++Build 
er的兼容性好，實(shí)際上很大程度應(yīng)歸功于MFC的兼容性好。微軟辛辛苦苦用標(biāo)準(zhǔn)方法寫(xiě)M 
FC，卻為對(duì)手制造了方便。不知他們作何感想？而因?yàn)镃++Builder對(duì)語(yǔ)言作了擴(kuò)展，VC 
不能編譯C++Builder的程序?？磥?lái)在這方面VC要輸給C++Builder了。而且VCL所支持的組 
件、屬性等都是MFC所缺乏的特性。雖然VC也能支持組件，但要通過(guò)AppWizard先生成一 
個(gè)"包裹"類(wrapper)，不如VCL來(lái)得簡(jiǎn)潔。有很多人使用C++Builder就是沖著控件板 
上那一大堆組件來(lái)的，VC雖然能使用的組件也很多(也許不比C++Builder少)，但由于不 
方便而對(duì)RAD程序員沒(méi)有吸引力。 

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更少。而且有第三方的專門(mén)工 
具幫助你避開(kāi)這些bug。如此規(guī)模的一個(gè)類庫(kù)，能做到這一點(diǎn)不容易。不要小看了這一點(diǎn) 
，很多專業(yè)程序員就是為這個(gè)選擇VC的。而C++Builder的VCL的bug就相對(duì)較多了，而且 
有些它自己帶的示例程序都有錯(cuò)誤?？磥?lái)Inprise還有很長(zhǎng)的路要走。 

再?gòu)乃鼈兊囊子眯员容^。VC有ClassWizard、SourceBrowser等一系列工具，還附 
帶Visual SourceSafe、Visual Modeler等強(qiáng)大的工具，易用性非常好。(VC自帶建模工 
具Visual Modeler，也許說(shuō)明了它才是工程級(jí)的開(kāi)發(fā)平臺(tái)，與C++Builder的定位不同。 
)它所帶的MSDN這部"開(kāi)發(fā)者的百科全書(shū)"更是讓你"沒(méi)有找不到的，只有想不到的"。 
而且它的AutoComplete之類小功能也比C++Builder要體貼。C++Builder的新版本雖然也 
提供了這一功能，但它的提示要等好幾秒才出來(lái)，有時(shí)你不經(jīng)意間把鼠標(biāo)停在某一處， 
也要等硬盤(pán)響好幾秒，這可是在566Mhz的賽揚(yáng)II上呀。不要笑我瑣碎，有時(shí)一個(gè)開(kāi)發(fā)工 
具的成熟和易用，就是從這些小地方體現(xiàn)出來(lái)的。C++Builder作為RAD工具，理應(yīng)強(qiáng)調(diào)易 
用性。但與VC相比還顯出不成熟。這是不應(yīng)該的。 

再來(lái)看看它們的可移植性。Inprise正在開(kāi)發(fā)C++Builder和Delphi的Linux版本， 
代號(hào)為Kylix。也許通過(guò)Kylix，用VCL構(gòu)架編寫(xiě)的Windows程序向Linux移植成為可能。但 
這只是可能。因?yàn)樵谀壳癐nprise的兼容性工作做得并不好。C++Builder可以編譯VC程序 
還要多謝微軟使用標(biāo)準(zhǔn)方法寫(xiě)MFC，而它自己各個(gè)版本之間兼容性卻不太好。低版本的C 
++Builder不能使用高版本的VCL組件(這還別去說(shuō)它)，而高版本的C++Builder竟然不能 
使用低版本的VCL組件。真是豈有此理，我很少看見(jiàn)軟件有不向下兼容的。如果Windows 
98不能運(yùn)行95的程序，Windows 95不能運(yùn)行3.x的程序，Win 3.x不能運(yùn)行DOS程序，你 
還會(huì)用Windows嗎？如果不是C++Builder的其它某些方面太出色，光是這個(gè)向下不兼容就 
足以讓我拋棄它。而且雖說(shuō)通過(guò)捆綁編譯器，C++Builder可以編譯Delphi的Object Pas 
cal代碼，但C++Builder仍不能使用為Delphi開(kāi)發(fā)的VCL組件。所以一個(gè)組件有for D1/D 
2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著C++Builder版本的升級(jí)可 
能還會(huì)增加。希望Inprise能先解決同門(mén)兄弟的兼容性問(wèn)題。而微軟的VC就沒(méi)有這類問(wèn)題 
。MFC1.0的程序也可以毫無(wú)障礙地在VC6.0下編譯通過(guò)。 

再來(lái)看看它們的前景吧。實(shí)際上，技術(shù)的進(jìn)步在很多時(shí)候是此消彼長(zhǎng)的。當(dāng)初Bo 
rland的Turbo C和Borland C++幾乎是唯一的選擇。微軟的Quick C(現(xiàn)在還有人知道這個(gè) 
產(chǎn)品嗎？)和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 Issue 
s部分，以及它們的幫助文檔的規(guī)模和質(zhì)量都可以看出。(哪個(gè)同類產(chǎn)品的幫助文檔能和 
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)還是比較樂(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++項(xiàng)目了。但愿對(duì)Inprise沖擊不會(huì)太大。微軟的Visual C++的前景又怎樣呢 
？Visual Studio 7.0不久就要推出了。不知能不能在保持穩(wěn)定性的同時(shí)在技術(shù)的先進(jìn)性 
上趕上C++Builder。另外，這一版本將加強(qiáng)網(wǎng)絡(luò)開(kāi)發(fā)的特性?？磥?lái)微軟雖然被判解體， 
開(kāi)發(fā)實(shí)力可是一點(diǎn)沒(méi)打折扣。 

就技術(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/Activ 
eX開(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)