【分享】開發工具大比拼visual c++ vs delphi---(一)


開發工具大比拼visual c++ vs delphi---(一)
“visual c++與delphi之比較”最近在csdn的論壇上的討論非常火熱，本文將以一個程式員的角度，從技術水平、功能、性能、易用性、穩定性、發展歷程和前景等方面，以visual c++ 6和delphi 5爲代表，盡可能客觀地比較介紹visual c++和delphi這兩大主流開發工具的優缺點，其中將涉及到語言、應用框架、控制項、編譯和連接、集成介面、調試、com、資料庫開發等。本文還將對如何選擇使用這兩個開發工具提出一些建議。

　　值得一提的是，由於c++builder與delphi同爲inprise公司産品，它們除了使用的語言不同，其餘特性幾乎都相同。因此本文對c++builder程式員和學習者也有參考價值。

　　語言：存在即是合理

　　首先聲明常被混淆的一點：vc和delphi本身不是語言，而是開發平臺。它們所用的語言分別是略作擴展的c/c++和object pascal。我在網上常看到有人問應該學c/c++還是vc，這個問題很好回答：如果你學vc你就必須得學c/c++，或者說你學會了vc也就學會了c/c++了。

　　言歸正傳，我們來比較一下c++和object pascal的優缺點。有人認爲object pascal是“玩具語言”，c++才是“專業語言”，這是不對的。單從語言本身看，object pascal與c++屬同一重量級。它們都是完全支援面向物件的語言，都紮根于“歷史悠久”的面向過程的語言。c++是由c發展而來的，object pascal由pascal進化而來。它們都有很強的靈活性，都有自己的特長和不足。比如說，object pascal不支援多重繼承、模板、操作符重載、內聯函數定義、預處理、巨集、全局靜態類變數、嵌套類定義，等等，而這些都是c++支援的。但同樣地c++也不支援object pascal的虛構造函數、過程嵌套、內置集合類型、內置字串類型、finally構造等等，在rtti方面object pascal也比c++做得好。但這些並不重要，因爲可以通過其他方式達到同樣的目的，比如c++可以通過類擴展支援集合、字串，object pascal可以通過“interface”多重繼承，等等。關鍵是二者都可以很好地完成你手頭的任務，這就夠了。

　　但是，僅僅比較語言本身是不夠的，還得看它們的被接受和流行程度，學習曲線，發展前途，可攜性等，以及，很重要但常常被忽略的一點：與開發環境(指vc與delphi)及其應用框架的“磨合”程度。

　　vc和delphi作爲開發平臺，很重要的一點就是提供了一個“無所不包”的應用框架：vc的mfc和delphi的vcl。mfc是用c++寫的，vcl是用object pascal寫的。當然，我們都知道，c++的使用範圍比object pascal廣得多，移植性也好得多。這本來是優點，但很有意思的是，正因爲如此，微軟寫mfc時必須考慮最大限度減少對語言本身的改動，而把功夫下在源代碼級，以便能盡可能支援ansi等標準，結果導致mfc的封裝複雜而不直觀。(尤其是它對消息的封裝，下文還會提到。)太多的巨集定義和含義模糊且自動生成、不得改動的注釋使mfc乃至vc讓很多新手望而生畏，不敢“下水”深入學習。而object pascal幾乎是inprise“專用”的，不必考慮“標準”問題，因此inprise寫vcl時就把全部精力放在了結構與性能上，結果語言與框架的磨合程度非常好。vcl框架的結構清晰，vcl代碼的可讀性非常好。許多人說delphi比較容易上手，也是這個緣故。天下沒有白吃的午餐。你要工業標準嗎？你要可攜性嗎？(關於可攜性和相容性，下文會詳細比較。)那麽請面對mfc的“天書”級代碼吧。

　　編譯和連接：the need for speed

　　不同的語言帶來的另一個不同是，編譯和連接的速度的不同，以及執行速度的不同。delphi的編譯和連接速度，毫不誇張地說，比vc快幾十倍。即使把vc的incremental link選項打開，delphi的編譯和連接速度仍比vc快好幾倍。並不是說微軟的編譯器不行，這是由c++的複雜性決定的。模板的處理、預處理和宏的展開都是很費時的。前文不是提到object pascal沒有模板、預處理和巨集嗎？這本來是缺點，但帶來的一個好處就是編譯速度極快。至於編譯完的二進位碼，在打開相同的優化選項的情況下，delphi和vc執行速度並沒有太大的差別。

　　爲了克服編譯的速度問題，c++編譯器一般需要增強的連接器和預處理機制。但是預處理機制仍然存在若干問題：

　　１）程式調試的中斷點行可能和代碼行不同。
　　２）沒有將最新的代碼資訊綜合進去。
　　３）容易産生錯誤的邏輯。
　　４）因爲讀錯文件頭而很容易産生類似“unexpected end of file”的錯誤。

　　兩個編譯器有個共同點是都能識別無用的“死”代碼，比如一個沒有用的函數等等。編譯後的程式將不包含這些多餘的資訊。delphi在這方面作得更加出色。它可以讓你在編輯器中視覺化地提示出那行代碼是“活”的、那行代碼是“死”的。這樣你就能整理出最精簡的代碼。

　　delphi在編譯後將在左邊顯示一個小藍點表示這行代碼是“活”的。visual c++做不到這點。 delphi編譯後的可執行文件至少有200k（如果不使用vcl，僅僅使用winapi，文件的大小將大大縮小）。但是visual c++編程使用mfc編譯後的可執行文件通常只有幾十k，主要是因爲微軟已經將系統運行庫包含在windows系統了（borland公司曾經和微軟協商這個介面，但是微軟利用操作系統的優勢不願意公開）。同樣道理，使用bde開發的的資料庫程式必須附帶3-5m的額外系統文件，也是非常不協調的。

　　非常有趣的是，delphi能夠使用由c++ builder創建的的obj文件，但是使用上受很大的局限性。

　　順便提一下vc的“edit and continue”功能。在調試中，這個功\能是可以大幅度節省時間的，但仍不能和delphi的閃速編譯比。

　　最後，visual c++的編譯和連接時的錯誤資訊比delphi要詳細和具體的多。特別是使用atl開發更加如此。

開發工具大比拼visual c++ vs delphi---(二)
應用框架：mfc？有kfc流行嗎？

　　應用程式框架(application frame)，有時也稱爲物件框架。visual c++採用的框架是mfc。mfc不僅僅是人們通常理解的一個類庫。(同樣，delphi的vcl也不僅僅是一個控制項庫，儘管它的名字叫“可視控制項庫”。)你如果選擇了mfc，也就選擇了一種程式結構，一種編程風格。mfc早在windows 3.x的時代就出現了，那時的visual c++還是16位的。經過這些年的不斷補充和完善，mfc已經十分成熟。但由於原型出現得比較早，mfc相比於vcl落後了一個時代。儘管微軟對mfc的更新沒有停止，我也經常讀到“只要windows不過時，mfc就不會過時”之類觀點的文章，但就象inprise(原borland)的owl框架的淡出一樣，mfc的淡出也是早晚的事。其實mfc是和owl同一個時代的産物。owl已經不在了，mfc怎能不“居安思危”呢？如果mfc青春永駐，微軟的開發人員也不會“私自”開發出基於atl的wtl呀。當然，wtl的地位不能和mfc比，它並不是微軟官方支援的框架，封裝的功能也相當有限。但至少也反襯出了mfc存在的不足。

　　我以爲，最能體現一個應用程式框架的先進性的是它的委託模型，即對windows消息的封裝機制。對windows api的封裝就不用說了吧。大同小異，也沒什麽技術含量。如果高興，你也可以自己寫一個類庫來封裝。但對windows消息驅動機制的封裝就不是那麽容易的了。最自然的封裝方式是採用虛成員函數。如果要回應某個消息就重載相應的虛函數。但出乎我的意料，mfc採用的是“古老”的巨集定義方法。用巨集定義方法的好處是省去了虛函數vtable的系統開銷。(由於windows的消息種類很多，開銷不算太小。)不過帶來的缺點就是映射不太直觀。對於mfc，則是“太不直觀”了。它的消息映射代碼雖然是可見的，但“勸君莫碰”。好在vc的classwizard可以自動生成消息映射代碼，使用起來還算方便。但和vcl的委託模型相比，mfc的映射方法就顯得太落後了。而delphi的object pascal因爲沒有“標準負擔”，語言引入了元件、事件處理、屬性等新特性。由於功夫做在編譯器級，生成的源代碼就顯得十分簡潔。似乎vc是“讓框架遷就語言”，而delphi是“讓語言遷就框架”。

　　我想舉一個對字串操作的封裝的例子來說明mfc和vcl的優缺點。在mfc中，cstringlist類有加入、獲取、刪除等功能，但vcl的tstringlist類除了上述功能還有排序、從逗號分隔的字串讀入、流輸入輸出等功\能。但同樣的字串替換功能，vcl的stringreplace要比mfc的cstring::replace慢2~3倍。總的來說，vcl的封裝比mfc更爲高層，更爲抽象，但不可避免地帶來的問題是某些部分執行效率比mfc略低。這就象低階語言(如彙編)的執行效率比高階語言(如basic)高，但編程效率較低。魚和熊掌不可兼得嘛。

　　vcl比之mfc的另一優點是對異常處理的支援，而一大缺點是對多線程支援差。vcl的大部分都不是針對多線程優化的。雖說vcl提供了簡化多線程操作的類，但只是工作者線程(worker threads)使用起來比較簡單。如果線程要和介面打交道的話事情就變得麻煩了，因爲除了應用程式的主線程，任何線程不能訪問任何可視的vcl部件。你不得不使用synchronize方法等待主線程處理它的消息，然後在主線程中訪問vcl部件。而mfc就沒有這樣的限制。

　　穩定性與完善程度：vc是老大哥

　　vc要比delphi穩定和完善。vc的發展歷史比delphi長，微軟的總體實力比inprise強。vc的框架mfc經歷了那麽多年的發展和完善，功能非常全面，而且十分穩定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工具幫助你避開這些bug。如此規模的一個類庫，能做到這一點不容易。不要小看了這一點，很多專業程式員就是爲這個選擇vc的。因爲儘管vcl比mfc的抽象程度高，封裝較爲高層，但由此帶來的開發效率的提高對高手來說畢竟是有限的。而如果你遇到一個怪問題，調試了半天，發現不是你的代碼有錯，而是vcl的bug，你作何感想？雖說遇到這類問題的可能性很小，但對vcl的形象的影響可不小。delphi的ide太占資源，啓動速度太慢，和某些顯卡驅動程式衝突，vcl中有bug，調試器不夠健壯，對不穩定的第三方控制項沒有防護措施……問題多多，在這方面delphi不如vc。希望inprise能更上一層樓。順便說一下，我在網上看到有些人極言delphi的不穩定，說幾分鐘出現20多次非法操作。delphi的確不如visual c++穩定，但也不至於如此呀。我估計是那位朋友的delphi裝了某些有問題的第三方控制項，導致了delphi的頻頻出錯。不妨卸下那些控制項試試？

　　可攜性：立足現實，放眼未來

　　inprise正在開發delphi的linux版本，代號爲kylix。也許通過kylix，用vcl構架編寫的windows程式向linux移植成爲可能。但這只是可能。因爲在目前inprise的相容性工作做得並不好。低版本的delphi不能使用高版本的vcl元件(這還別去說它)，而高版本的delphi竟然不能使用低版本的vcl元件。真是豈有此理，我很少看見軟體有不向下二進位相容的。如果windows 98不能運行95的程式，windows 95不能運行3.x的程式，win 3.x不能運行dos程式，你還會用windows嗎？如果windows 95的程式必須經過重新編譯才能在98下運行，98會賣得那麽好嗎？“同門兄弟”c++builder和delphi也不能互相使用對方的元件，甚至同一套vcl庫的檔案名也不一樣。所以一個元件有for d1/d2/d3/d4/d5/c1/c3/c4/c5這些不同版本是常有的事，而且隨著delphi和c++builder版本的升級可能還會增加。希望inprise能先解決同門兄弟的相容性問題。而微軟的vc就沒有這類問題。mfc1.0的程式也可以毫無障礙地在vc6.0下編譯通過。

　　集成介面：宏觀與微觀

　　就大處說，vc的集成介面是不如delphi的。delphi僅僅一個object inspector就可以將vc的一堆wizards比下去，何況它還有code explorer、todo list等。但從小處，又可以看出delphi的不成熟。比如“自動完成”功能的智慧化程度和提示詳細程度不如vc，回應速度也沒有vc快。

　　visual c++所帶的msdn是一部“開發者的百科全書”，資訊龐大，查詢方便，這方面比delphi更加專業。很多幫助項都有源程式示範。

　　delphi的opentools是完全面向第三方的開放系統，開發者可以修改很多borland公司自身的功能，從ide的可擴充性上說delphi更好。

　　調試：細微之處見真功

　　visual c++和delphi的調試功能都非常強大，同時都具有單步視覺化調試、中斷點跟蹤、運行時改變變數、滑鼠指向可以得到變數值等等功\能。對dll的輸入輸出也能方便的管理，能夠進行源碼級別的調試。

　　相對而言，visual c++能夠更加方便地看到變數的變化情況，這包括對結構可以展開成資料樹，從而瞭解每一個變數的值，每一步調試，變化了的變數會加紅，從而使調試更加方便。另外，visual c++的塊記憶體察看比delphi也要方便。

　　當然，delphi也有很多體貼的細微之處，比如在線程調試的時候，delphi能夠很方便地察看線程的變化，visual c++確必須要彈出一個模式對話方塊。