程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> VC >> vc教程 >> Visual C++與Delphi/C++Builder之比較(二)

Visual C++與Delphi/C++Builder之比較(二)

編輯:vc教程

  再從它們的易用性比較。VC有ClassWizard、SourceBrowser等一系列工具,還附帶Visual SourceSafe、Visual Modeler等強大的工具,易用性非常好。(VC自帶建模工具Visual Modeler,也許說明了它才是工程級的開發平台,與C++Builder的定位不同。)它所帶的MSDN這部“開發者的百科全書”更是讓你“沒有找不到的,只有想不到的”。而且它的AutoComplete之類小功能也比C++Builder要體貼。C++Builder的新版本雖然也提供了這一功能,但它的提示要等好幾秒才出來,有時你不經意間把鼠標停在某一處,也要等硬盤響好幾秒,這可是在566Mhz的賽揚II上呀。不要笑我瑣碎,有時一個開發工具的成熟和易用,就是從這些小地方體現出來的。C++Builder作為RAD工具,理應強調易用性。但與VC相比還顯出不成熟。這是不應該的。

  再來看看它們的可移植性。Inprise正在開發C++Builder和Delphi的Linux版本,代號為Kylix。也許通過Kylix,用VCL構架編寫的Windows程序向Linux移植成為可能。但這只是可能。因為在目前Inprise的兼容性工作做得並不好。C++Builder可以編譯VC程序還要多謝微軟使用標准方法寫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 Pascal代碼,但C++Builder仍不能使用為Delphi開發的VCL組件。所以一個組件有for D1/D2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事,而且隨著C++Builder版本的升級可能還會增加。希望Inprise能先解決同門兄弟的兼容性問題。而微軟的VC就沒有這類問題。MFC1.0的程序也可以毫無障礙地在VC6.0下編譯通過。

  再來看看它們的前景吧。實際上,技術的進步在很多時候是此消彼長的。當初Borland的Turbo C和Borland C++幾乎是唯一的選擇。微軟的Quick C(現在還有人知道這個產品嗎?)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢?不久就被新崛起的Microsoft Visual C/C++壓下去了。現在的C++Builder又有後來居上的態勢,如果穩定性再提高一些,bug再少一些,有希望成為主流。但Inprise的總體實力不及微軟,這也是無可爭議的。從C++Builder 5的Release Notes中的Known Issues部分,以及它們的幫助文檔的規模和質量都可以看出。(哪個同類產品的幫助文檔能和MSDN比呢?)Inprise公司應從Netscape吸取教訓,不要讓C++Builder成為第二個Netscape Communicator。(Communicator也是一度技術領先,甚至曾占據了大部分的浏覽器市場,但似乎後勁不足,而且 6.0 PR1、2中bug多多,現在被IE壓得抬不起頭。)C++Builder是Inprise的旗艦產品之一,前景應當還是比較樂觀的,而且Inprise已經在向Linux進軍了,而微軟還遲遲沒有動作,難道非要到Linux成燎原之勢(或許已經成燎原之勢了)才會奮起占領這個新興市場?似乎他們對Linux的態度與幾年前對互聯網的興起的反應遲緩有些相似。但後來......唉,真希望Inprise不要步Netscape的後塵。C++Builder是一個很有前途的開發工具。遺憾的是,Inprise公司Delphi的創始人已經跳槽到微軟去主持Visual J++項目了。但願對Inprise沖擊不會太大。微軟的Visual C++的前景又怎樣呢?Visual Studio 7.0不久就要推出了。不知能不能在保持穩定性的同時在技術的先進性上趕上C++Builder。另外,這一版本將加強網絡開發的特性。看來微軟雖然被判解體,開發實力可是一點沒打折扣。

  就技術(主要指應用框架)來說,C++Builder目前領先於Visual C++。但多多少少的不盡人意之處讓我對Inprise“想說愛你不容易”。而VC盡管發展到今日已十分完善,但MFC框架已是明日黃花了。如果不使用MFC,目前又沒有合適的替代品。WFC是支持組件、屬性和事件的,但那是Visual J++裡邊用的;ATL也很先進,但是用來進行COM/ActiveX開發的;基於ATL的WTL也不錯,可惜是非官方作品,也未必比VCL先進。微軟最近提出了C#(讀作C Sharp)語言方案,但那屬於和Java同一類的東西。看來是金無足赤啊。根據你的需要做選擇吧。實際上Visual C++和C++Builder也不是單單競爭關系。它們在許多領域並不重疊,甚至是互補的。到底怎樣取捨,要根據你的項目特性決定。如果你開發系統底層的東西,需要極好的兼容性和穩定性,選Visual C++吧。你可以只調用Windows的各種API,不用MFC。如果你寫傳統的Windows桌面應用程序,Visual C++的MFC框架是“正統”的選擇。如果你為企業開發數據庫、信息管理系統等高層應用(“高層”是相對於“低層/底層”而言的,不是說技術高級或低級。)而且有比較緊的期限限制,選C++Builder比較好。如果你用的語言是Object Pascal,Delphi是唯一的選擇(如果GNU Pascal等免費編譯器不考慮的話)。如果你原先用Delphi(Object Pascal語言),現在想改學C++,應當先用C++Builder。熟悉的界面和相同的框架會讓你的轉軌事半功倍。

  另外,雖說MFC已顯落後,但不是說它不值得學。事實上,不學MFC就等於沒學VC。利用MFC框架開發程序仍然是目前開發桌面應用的主流模式,而且還會保持相當長的時間。即使你不使用MFC框架,花點時間學習一下MFC的封裝機制對你熟悉C++的OOP機制和Windows底層功能也是很有好處的。

  以上意見僅供參考。

  1. 上一頁:
  2. 下一頁:
欄目導航
Copyright © 程式師世界 All Rights Reserved