- 相關(guān)推薦
VisualC 與Delphi/C Builder之比較及未來(lái)的發(fā)展前景之我見(jiàn)
由于Delphi與C Builder同為Inprise公司產(chǎn)品，共享集成開(kāi)發(fā)界面(IDE)，而且
使用同一套VCL框架(這一點(diǎn)最關(guān)鍵)，它們帶的調試器、PVCS/TeamSource團隊開(kāi)發(fā)支持
、數據庫引擎及企業(yè)版中集成的其它高級功能等都是相同的，所以本文將其與C Build
er歸入"同一陣線(xiàn)"。我在網(wǎng)上見(jiàn)到一些Delphi程序員認為C Builder與VC比較接近，
這是個(gè)誤解。事實(shí)上，Delphi和C Builder除了使用的語(yǔ)言不同，其余幾乎都相同。為
了避免話(huà)題轉移到C 語(yǔ)言與Object Pascal語(yǔ)言(即Delphi所用的語(yǔ)言)的比較，下文主
要對比分析Visual C 與C Builder。
首先，從它們的應用程序框架(Application Frame，有時(shí)也稱(chēng)為對象框架)進(jìn)行比
較。Visual C 采用的框架是MFC。MFC不僅僅是人們通常理解的一個(gè)類(lèi)庫。(同樣，Del
phi和C Builder使用的VCL的概念也不僅僅是一個(gè)控件庫。)你如果選擇了MFC，也就選
擇了一種程序結構，一種編程風(fēng)格。MFC早在Windows 3.x的時(shí)代就出現了，那時(shí)的Visu
al C 還是16位的。經(jīng)過(guò)這些年的不斷補充和完善，MFC已經(jīng)十分成熟。但由于原型出現
得比較早，MFC相比于VCL落后了一個(gè)時(shí)代。盡管微軟對MFC的更新沒(méi)有停止，我也經(jīng)常讀
到持"只要Windows不過(guò)時(shí)，MFC就不會(huì )過(guò)時(shí)"之類(lèi)觀(guān)點(diǎn)的文章，但就象Inprise(原Borl
and)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。如果MFC青春永駐，微軟的開(kāi)發(fā)人
員也不會(huì )"私自"開(kāi)發(fā)出基于A(yíng)TL的WTL呀。當然，WTL的地位不能和MFC比，它并不是微
軟官方支持的框架，封裝的功能也相當有限。但至少也反襯出了MFC存在的不足。
我以為，最能體現一個(gè)應用程序框架的先進(jìn)性的是它的委托模型，即對Windows消
息的封裝機制。(對Windows API的封裝就不用說(shuō)了吧。大同小異，也沒(méi)什么技術(shù)含量。
如果高興，你也可以自己寫(xiě)一個(gè)類(lèi)庫來(lái)封裝。但對Windows消息驅動(dòng)機制的封裝就不是那
么容易的了。)最自然的封裝方式是采用虛成員函數。如果要響應某個(gè)消息就重載相應的
虛函數。但出乎我的意料，MFC采用的是"古老"的宏定義方法。用宏定義方法的好處是
省去了虛函數VTable的系統開(kāi)銷(xiāo)。(由于Windows的消息種類(lèi)很多，開(kāi)銷(xiāo)不算太小。)不過(guò)
帶來(lái)的缺點(diǎn)就是映射不太直觀(guān)。好在較新版本VC帶的ClassWizard可以自動(dòng)生成消息映射
代碼，使用起來(lái)還是比較方便的。但和VCL的委托模型相比，MFC的映射方法就顯得太落
后了。而C Builder對C 語(yǔ)言進(jìn)行了擴展，以便引入組件、事件處理、屬性等新特性。
由于功夫做在編譯器級，生成的源代碼就顯得十分簡(jiǎn)潔。但是由于擴展的非標準特性，
使用VCL的C Builder的源代碼無(wú)法被其它編譯器編譯。而MFC的功夫做在源代碼級，雖
然消息映射代碼較為復雜且不直觀(guān)，但兼容性非常好。只要你有MFC庫的源代碼(隨VC企
業(yè)版的光盤(pán)提供)，你的MFC程序理論上用任何符合ANSI標準的編譯器均可編譯通過(guò)。C
Builder 3以上版本可以原封不動(dòng)直接編譯Visual C 程序，很多人認為這是C Build
er的兼容性好，實(shí)際上很大程度應歸功于MFC的兼容性好。微軟辛辛苦苦用標準方法寫(xiě)M
FC，卻為對手制造了方便。不知他們作何感想？而因為C Builder對語(yǔ)言作了擴展，VC
不能編譯C Builder的程序�？磥�(lái)在這方面VC要輸給C Builder了。而且VCL所支持的組
件、屬性等都是MFC所缺乏的特性。雖然VC也能支持組件，但要通過(guò)AppWizard先生成一
個(gè)"包裹"類(lèi)(wrapper)，不如VCL來(lái)得簡(jiǎn)潔。有很多人使用C Builder就是沖著(zhù)控件板
上那一大堆組件來(lái)的，VC雖然能使用的組件也很多(也許不比C Builder少)，但由于不
方便而對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功能非
常全面，而且十分穩定，bug很少。其中你可能遇到的bug更少。而且有第三方的專(zhuān)門(mén)工
具幫助你避開(kāi)這些bug。如此規模的一個(gè)類(lèi)庫，能做到這一點(diǎn)不容易。不要小看了這一點(diǎn)
，很多專(zhuān)業(yè)程序員就是為這個(gè)選擇VC的。而C Builder的VCL的bug就相對較多了，而且
有些它自己帶的示例程序都有錯誤�？磥�(lái)Inprise還有很長(cháng)的路要走。
再從它們的易用性比較。VC有ClassWizard、SourceBrowser等一系列工具，還附
帶Visual SourceSafe、Visual Modeler等強大的工具，易用性非常好。(VC自帶建模工
具Visual Modeler，也許說(shuō)明了它才是工程級的開(kāi)發(fā)平臺，與C Builder的定位不同。
)它所帶的MSDN這部"開(kāi)發(fā)者的百科全書(shū)"更是讓你"沒(méi)有找不到的，只有想不到的"。
而且它的AutoComplete之類(lèi)小功能也比C Builder要體貼。C Builder的新版本雖然也
提供了這一功能，但它的提示要等好幾秒才出來(lái)，有時(shí)你不經(jīng)意間把鼠標停在某一處，
也要等硬盤(pán)響好幾秒，這可是在566Mhz的賽揚II上呀。不要笑我瑣碎，有時(shí)一個(gè)開(kāi)發(fā)工
具的成熟和易用，就是從這些小地方體現出來(lái)的。C Builder作為RAD工具，理應強調易
用性。但與VC相比還顯出不成熟。這是不應該的。
再來(lái)看看它們的可移植性。Inprise正在開(kāi)發(fā)C Builder和Delphi的Linux版本，
代號為Kylix。也許通過(guò)Kylix，用VCL構架編寫(xiě)的Windows程序向Linux移植
【VisualC 與Delphi/C Builder之比較及未來(lái)的發(fā)展】相關(guān)文章：
C語(yǔ)言上機考試系統Delphi7+Access11-23
基于Delphi的試卷智能生成系統設計Delphi+SQL11-23
試論中西哲學(xué)之根本比較03-06
delphi題庫系統(一)03-07
文件自動(dòng)分類(lèi)系統Delphi03-08
讓員工相信未來(lái)發(fā)展03-24
比較優(yōu)勢、競爭優(yōu)勢與發(fā)展的趕超03-20
C2C模式下網(wǎng)絡(luò )營(yíng)銷(xiāo)價(jià)格策略的發(fā)展趨勢及建議03-28