開發工具大比拚之Visual C++　vs.　Delphi(一) (轉)

開發工具大比拚之Visual C++　vs.　Delphi(一) (轉)[@more@]

紫雲英、曾登高:namespace prefix = o ns = "urn:schemas--com::office" />

引言

　　“Visual C++與之比較”最近在CSDN的論壇上的討論非常火熱，本文將以一個員的角度，從技術水平、功能、、易用性、穩定性、發展歷程和前景等方面，以Visual C++ 6和Delphi 5為代表，儘可能客觀地比較介紹Visual C++和Delphi這兩大主流開發工具的優缺點，其中將涉及到語言、應用、、編譯和連線、整合介面、、COM、開發等。本文還將對如何選擇使用這兩個開發工具提出一些建議。
　　值得一提的是，由於C++Builder與Delphi同為Inprise公司產品，它們除了使用的語言不同，其餘特性幾乎都相同。因此本文對C++Builder程式設計師和學習者也有參考價值。

 

語言：存在即是合理
　　首先宣告常被混淆的一點：VC和Delphi本身不是語言，而是開發平臺。它們所用的語言分別是略作擴充套件的C/C++和 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++編譯器一般需要增強的聯結器和預處理機制。但是預處理機制仍然存在若干問題：1）程式除錯的斷點行可能和程式碼行不同。２）沒有將最新的程式碼資訊綜合進去。３）容易產生錯誤的邏輯。４）因為讀錯頭而很容易產生類似“Unexpected End of File”的錯誤。

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

Delphi編譯後的可執行檔案至少有200K（如果不使用VCL，僅僅使用Win，檔案的大小將大大縮小）。但是Visual C++使用MFC編譯後的可執行檔案通常只有幾十K，主要是因為微軟已經將執行庫包含在系統了（Borland公司曾經和微軟協商這個介面，但是微軟利用的優勢不願意公開）。同樣道理，使用BDE開發的的資料庫程式必須附帶3-5M的額外系統檔案，也是非常不協調的。

非常有趣的是，Delphi能夠使用由C++ Builder建立的的OBJ檔案，但是使用上受很大的侷限性。

　　順便提一下VC的“Edit and Continue”功能。在除錯中，這個功能是可以大幅度節省時間的，但仍不能和Delphi的閃速編譯比。

最後，Visual C++的編譯和連線時的錯誤資訊比Delphi要詳細和具體的多。特別是使用ATL開發更加如此。