宮成剛
[摘要]本文將以一個程序員的角度,從技術水平、功能、性能、易用性、穩定性、發展歷程和前景等方面,以isual c++ 6和delphi 5為代表,盡可能客觀地比較介紹isual c++和delphi這兩大主流開發工具的優缺點,其中將涉及到語言、應用框架、控件、編譯和連接、集成界面、調試、com、數據庫開發等。本文還將對如何選擇使用這兩個開發工具提出一些建議。
[關鍵詞]開發工具 語言 應用框架 控件 編譯和連接 集成界面 調試 數據庫
一、語言:存在即是合理
首先聲明常被混淆的一點:c和delphi本身不是語言,而是開發平臺。它們所用的語言分別是略作擴展的c/c++和object pascal。有人認為object pascal是“玩具語言”,c++才是“專業語言”,這是不對的。單從語言本身看,object pascal與c++屬同一重量級。它們都是完全支持面向對象的語言,都扎根于“歷史悠久”的面向過程的語言。c++是由c發展而來的,object pascal由pascal進化而來。它們都有很強的靈活性,都有自己的特長和不足。比如說,object pascal不支持多重繼承、模板、操作符重載、內聯函數定義等等,而這些都是c++支持的。但同樣地c++也不支持object pascal的虛構造函數、過程嵌套、內置集合類型、內置字符串類型等等,在rtti方面object pascal也比c++做得好。但這些并不重要,因為可以通過其它方式達到同樣的目的,比如c++可以通過類擴展支持集合、字符串,object pascal可以通過“interface”多重繼承,等等。關鍵是二者都可以很好地完成你手頭的任務,這就夠了。
二、編譯和連接:速度的較量
不同的語言帶來的另一個不同是,編譯和連接的速度的不同,以及執行速度的不同。delphi的編譯和連接速度,毫不夸張地說,比c快幾十倍。即使把c的incremental link選項打開,delphi的編譯和連接速度仍比c快好幾倍。并不是說微軟的編譯器不行,這是由c++的復雜性決定的。模板的處理、預處理和宏的展開都是很費時的。前文不是提到object pascal沒有模板、預處理和宏嗎?這本來是缺點,但帶來的一個好處就是編譯速度極快。至于編譯完的二進制代碼,在打開相同的優化選項的情況下,delphi和c執行速度并沒有太大的差別。
三、應用框架:mfc有kfc流行嗎
應用程序框架(application frame),有時也稱為對象框架。isual c++采用的框架是mfc。mfc不僅僅是人們通常理解的一個類庫。經過這些年的不斷補充和完善,mfc已經十分成熟。但由于原型出現得比較早,mfc相比于cl落后了一個時代。盡管微軟對mfc的更新沒有停止,但就象inprise的owl框架的淡出一樣,mfc的淡出也是早晚的事。其實mfc是和owl同一個時代的產物。owl已經不在了,mfc怎能不“居安思危”呢?如果mfc青春永駐,微軟的開發人員也不會“私自”開發出基于atl的wtl呀。當然,wtl的地位不能和mfc比,它并不是微軟官方支持的框架,封裝的功能也相當有限。但至少也反襯出了mfc存在的不足。
四、穩定性與完善程度:c是老大哥
c要比delphi穩定和完善。c的發展歷史比delphi長,微軟的總體實力比inprise強。c的框架mfc經歷了那么多年的發展和完善,功能非常全面,而且十分穩定,bug很少。不要小看了這一點,很多專業程序員就是為這個選擇c的。因為盡管cl比mfc的抽象程度高,封裝較為高層,但由此帶來的開發效率的提高對高手來說畢竟是有限的。而如果你遇到一個怪問題,調試了半天,發現不是你的代碼有錯,而是cl的bug,你作何感想? delphi的ide太占資源,啟動速度太慢,和某些顯卡驅動程序沖突,cl中有bug,調試器不夠健壯,對不穩定的第三方控件沒有防護措施……問題多多,在這方面delphi不如c。
五、可移植性:立足現實,放眼未來
目前inprise的兼容性工作做得并不好。低版本的delphi不能使用高版本的cl組件,而高版本的delphi竟然不能使用低版本的cl組件。如果windows 98不能運行95的程序,windows 95不能運行3.x的程序,你還會用windows嗎?如果windows 95的程序必須經過重新編譯才能在98下運行,98會賣得那么好嗎?“同門兄弟”c++builder和delphi也不能互相使用對方的組件,甚至同一套cl庫的文件名也不一樣。希望inprise能先解決同門兄弟的兼容性問題。而微軟的c就沒有這類問題。mfc1.0的程序也可以毫無障礙地在c6.0下編譯通過。
六、集成界面:宏觀與微觀
就大處說,c的集成界面是不如delphi的。delphi僅僅一個object inspector就可以將c的一堆wizards比下去,何況它還有code explorer、todo list等。但從小處,又可以看出delphi的不成熟。比如“自動完成”功能的智能化程度和提示詳細程度不如c,響應速度也沒有c快。
isual c++所帶的msdn是一部“開發者的百科全書”,信息龐大,查詢方便,這方面比delphi更加專業。delphi的opentools是完全面向第三方的開放系統,開發者可以修改很多borland公司自身的功能,從ide的可擴充性上說delphi更好。
七、魚和熊掌:艱難的選擇
選擇一個開發工具依賴于很多不同的因素,每個人都能因為某種語言的某個缺陷而放棄學習或使用這種語言。任何程序員都希望自己喜歡的工具能達到理想的境界,通過上面不完善的比較,我想大家都有自己的看法。我認為影響大家選擇開發語言的因素主要包括:
1.哪門語言更容易入門
學習一種語言需要投入大量的時間和精力。開發程序的開發成本是值得考慮的現實。一個熟練的delphi程序員和一個熟練的c程序員工作效率是一樣的。但是,成為熟練的程序員必須很快掌握一門語言的技巧。不幸的是,目前熟練的isual c++程序員是十里挑一。相對而言,delphi更適合初學者。
2.哪門語言有更多可繼承的代碼
語言代碼的可重用性是加快開發效率明顯方面,從早期的過程、函數到現在的組件技術都是朝這個目標在奮斗。這兩種語言對代碼重用的理解是不一樣的,delphi主要通過cl控件來實現代碼重用,isual c++實現起來就比較復雜。
3.語言自身的本性
就技術(主要指應用框架)來說,delphi目前領先于isual c++。但穩定性和健壯性的不足又讓我們對inprise“想說愛你不容易”。而c盡管發展到今日已十分完善,但mfc框架已是明日黃花了。如果不使用mfc,目前又沒有合適的替代品。
4.語言的前景和可擴充性
delphi是inprise的旗艦產品之一,前景應當還是比較樂觀的,而且inprise已經在向linux進軍了,而微軟還遲遲沒有動作。
微軟的isual c++的前景又怎樣呢?isual studio 7.0就要推出了。這一版本將加強網絡開發的特性。看來微軟雖然被判解體,開發實力可是一點沒打折扣。
根據你的需要和實際情況做選擇吧。實際上c和delphi也不是單單競爭關系。它們在許多領域并不重疊,甚至是互補的。到底怎樣取舍,要根據你的項目特性決定。如果你開發系統底層的東西,需要極好的兼容性和穩定性,選c吧。如果你寫傳統的windows桌面應用程序,c的mfc框架是“正統”的選擇;如果界面部分占這個應用程序代碼比例較大的話,或者delphi中有相關功能的控件的話,delphi是事半功倍的選擇。如果你為企業開發數據庫、信息管理系統等高層應用,而且有比較緊的期限限制,選delphi比較好。傳統的觀點是:delphi適合編寫internet/intranet、表格制圖、數據庫操作、高級用戶界面等等。isual c++適合編寫設備驅動、com服務程序、科學計算、控制臺程序、wince的應用和一些小的工具等等。