|
Visual C++與Delphi/C++Builder之比較及未來的發(fā)展前景之我見
（作者未知） 2010/5/24
（接上頁）組件也很多(也許不比C++Builder少)，但由于不
方便而對RAD程序員沒有吸引力。
C++Builder的VCL比Visual C++的MFC先進(jìn)的另一個特性是異常處理。但令人啼笑
皆非的是，它的異常處理代碼有bug，有時會無端拋出異常。不知道在最新的版本中有沒
有改正了。而VC的框架MFC也不是一無是處。經(jīng)歷了那么多年的發(fā)展和完善，MFC功能非
常全面，而且十分穩(wěn)定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工
具幫助你避開這些bug。如此規(guī)模的一個類庫，能做到這一點不容易。不要小看了這一點
，很多專業(yè)程序員就是為這個選擇VC的。而C++Builder的VCL的bug就相對較多了，而且
有些它自己帶的示例程序都有錯誤�？磥鞩nprise還有很長的路要走。
再從它們的易用性比較。VC有ClassWizard、SourceBrowser等一系列工具，還附
帶Visual SourceSafe、Visual Modeler等強(qiáng)大的工具，易用性非常好。(VC自帶建模工
具Visual Modeler，也許說明了它才是工程級的開發(fā)平臺，與C++Builder的定位不同。
)它所帶的MSDN這部"開發(fā)者的百科全書"更是讓你"沒有找不到的，只有想不到的"。
而且它的AutoComplete之類小功能也比C++Builder要體貼。C++Builder的新版本雖然也
提供了這一功能，但它的提示要等好幾秒才出來，有時你不經(jīng)意間把鼠標(biāo)停在某一處，
也要等硬盤響好幾秒，這可是在566Mhz的賽揚(yáng)II上呀。不要笑我瑣碎，有時一個開發(fā)工
具的成熟和易用，就是從這些小地方體現(xiàn)出來的。C++Builder作為RAD工具，理應(yīng)強(qiáng)調(diào)易
用性。但與VC相比還顯出不成熟。這是不應(yīng)該的。
再來看看它們的可移植性。Inprise正在開發(fā)C++Builder和Delphi的Linux版本，
代號為Kylix。也許通過Kylix，用VCL構(gòu)架編寫的Windows程序向Linux移植成為可能。但
這只是可能。因為在目前Inprise的兼容性工作做得并不好。C++Builder可以編譯VC程序
還要多謝微軟使用標(biāo)準(zhǔn)方法寫MFC，而它自己各個版本之間兼容性卻不太好。低版本的C
++Builder不能使用高版本的VCL組件(這還別去說它)，而高版本的C++Builder竟然不能
使用低版本的VCL組件。真是豈有此理，我很少看見軟件有不向下兼容的。如果Windows
98不能運行95的程序，Windows 95不能運行3.x的程序，Win 3.x不能運行DOS程序，你
還會用Windows嗎？如果不是C++Builder的其它某些方面太出色，光是這個向下不兼容就
足以讓我拋棄它。而且雖說通過捆綁編譯器，C++Builder可以編譯Delphi的Object Pas
cal代碼，但C++Builder仍不能使用為Delphi開發(fā)的VCL組件。所以一個組件有for D1/D
2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著C++Builder版本的升級可
能還會增加。希望Inprise能先解決同門兄弟的兼容性問題。而微軟的VC就沒有這類問題
。MFC1.0的程序也可以毫無障礙地在VC6.0下編譯通過。
再來看看它們的前景吧。實際上，技術(shù)的進(jìn)步在很多時候是此消彼長的。當(dāng)初Bo
rland的Turbo C和Borland C++幾乎是唯一的選擇。微軟的Quick C(現(xiàn)在還有人知道這個
產(chǎn)品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢
？不久就被新崛起的Microsoft Visual C/C++壓下去了�，F(xiàn)在的C++Builder又有后來居
上的態(tài)勢，如果穩(wěn)定性再提高一些，bug再少一些，有希望成為主流。但I(xiàn)nprise的總體
實力不及微軟，這也是無可爭議的。從C++Builder 5的Release Notes中的Known Issue
s部分，以及它們的幫助文檔的規(guī)模和質(zhì)量都可以看出。(哪個同類產(chǎn)品的幫助文檔能和
MS（未完，下一頁）
|