~v~
“Visual C++和Delphi的比較”最近在CSDN論壇上引起了熱烈的討論。本文將以Visual C++6和Delphi5為代表，從技術水平、功能、性能、易用性、穩定性和前景等方面客觀地比較和介紹Visual C++和Delphi的優缺點，這將涉及語言、應用程序框架、控件等方面。本文還將對如何選擇和使用這兩種開發工具給出壹些建議。
值得壹提的是，由於C++Builder和Delphi都是InEnterprise的產品，除了語言不同之外，它們幾乎具有相同的特征。因此，本文對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發展而來的，對象Pascal是由Pascal演變而來的。他們都有很強的靈活性和自己的優勢和劣勢。例如，Object Pascal不支持C++支持的多重繼承、模板、運算符重載、內聯函數定義、預處理、宏、全局靜態類變量、嵌套類定義等。但同樣，C++也不支持虛擬構造函數、過程嵌套、內置集合類型、內置字符串類型、“finally”構造等。在RTTI，Object Pascal比C++做得更好。但這些都不重要，因為同樣的目標可以通過其他方式實現，例如，C++可以通過類擴展支持集合和字符串，對象Pascal可以通過“inte***ce”多次繼承等等。關鍵是兩人都能很好地完成手頭的任務，這就足夠了。
但是，僅僅比較語言本身是不夠的，還要看語言的接受度和受歡迎程度、學習曲線、發展前景、可移植性等。，以及非常重要但經常被忽視的壹點:與開發環境（參考VC和Delphi）及其應用框架的“磨合”程度。
作為開發平臺，VC和Delphi提供了壹個包羅萬象的應用框架:VC的MFC和Delphi的VCL。MFC是用C++寫的，VCL是用Object Pascal寫的。當然，我們都知道C++的用途比Object Pascal廣泛得多，可移植性也好得多。這原本是壹個優勢，但非常有趣的是，正因為如此，微軟在編寫MFC時必須考慮盡量減少對語言本身的更改，並專註於源代碼級別，以便盡可能支持ANSI和其他標準，從而導致MFC復雜而直觀的打包。（尤其是它對消息的封裝，這將在下面提到）。太多含義模糊的宏定義和註釋是自動生成的，並且無法更改，這讓許多新手對MFC甚至VC望而生畏，他們不敢“下水”深入學習。Object Pascal幾乎是InEnterprise“專用”的，不需要考慮“標準”的問題。因此，InEnterprise在編寫《VCL》時將全部精力投入到結構和表演中，從而使語言和框架之間達到了非常好的融合程度。VCL框架結構清晰，VCL代碼可讀性很好。很多人說Delphi好用，也是這個原因。天下沒有免費的午餐。妳想要工業標準嗎？要不要便攜性（下面會詳細對比便攜性和兼容性）？那麽請面對MFC的“天書”代碼。
編譯和連接:對速度的需求
不同語言帶來的另壹個區別是編譯和連接的速度不同，執行的速度也不同。毫不誇張地說，Delphi的編譯和連接速度比VC快幾十倍。即使打開VC的增量鏈接選項，Delphi的編譯和連接速度仍然比VC快幾倍。不是微軟的編譯器不行，是C++的復雜性決定的。模板處理、預處理和宏擴展都很耗時。妳之前不是提到過Object Pascal沒有模板、預處理和宏嗎？這是壹個缺點，但壹個優點是編譯速度極快。至於編譯後的二進制代碼，在開啟相同的優化選項時，Delphi和VC的執行速度沒有太大差異。
為了克服編譯的速度問題，C++編譯器通常需要增強的連接器和預處理機制。但預處理機制仍存在壹些問題:1）程序調試的斷點行可能與代碼行不同；2）沒有集成最新的代碼信息；3）容易出錯的邏輯；4）由於讀取錯誤的文件頭，很容易出現類似“文件意外結束”的錯誤。
這兩個編譯器的相同之處在於它們可以識別無用的“死”代碼，例如無用的函數等等。編譯後的程序將不包含這些冗余信息。德爾福在這方面做得更好。它允許您在編輯器中直觀地指示哪壹行代碼是“活的”，哪壹行代碼是“死的”。這樣妳就可以整理出最精簡的代碼。編譯後，Delphi將在左側顯示壹個小藍點，以指示這行代碼是“活的”。Visual C++不能做到這壹點。
Delphi編譯的可執行文件至少有200K（如果不使用VCL，只使用WinAPI，文件大小將大大減少），但Visual C++編程中MFC編譯的可執行文件通常只有幾十K，主要是因為微軟已經將系統運行時包含在Windows系統中（Borland公司曾與微軟談判此接口，但微軟不願意利用操作系統將其公開）。同樣，BDE開發的數據庫程序必須附帶3-5M的額外系統文件，這也是非常不協調的。
非常有趣的是，Delphi可以使用C++ Builder創建的OBJ文件，但它的使用受到很大限制。
最後，編譯和連接Visual C++時的錯誤信息比Delphi詳細和具體得多。尤其是使用ATL開發。
應用框架:MFC？肯德基受歡迎嗎？
應用程序框架，有時稱為對象框架。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的類庫（同樣，Delphi的VCL也不僅僅是壹個控件庫，盡管它的名稱是“可視化控件庫”）。如果您選擇MFC，您還可以選擇程序結構和編程風格。MFC早在Windows 3.x就出現了，當時Visual C++是16。經過多年的不斷補充和改進，MFC已經非常成熟。然而，由於原型的早期出現，MFC落後於VCL壹個時代。雖然微軟對MFC的更新壹直沒有停止，但我經常看到“只要Windows過時，MFC就不會過時”之類的文章，但就像InEnterprise（原Borland）的OWL框架淡出壹樣，MFC遲早會淡出。事實上，MFC與OWL是同壹時代的產物。貓頭鷹沒了，MFC怎麽能不“居安思危”呢？如果MFC永遠存在，微軟開發人員將不會“私下”開發基於ATL的WTL。當然，WTL的立場不能與MFC相比。它不是微軟支持的框架，其打包功能相當有限。但至少它也反映了MFC的缺點。
我們認為最先進的應用程序框架是其委托模型，即Windows消息的封裝機制。Windows API的封裝就不用說了。大同小異，沒有什麽技術含量。如果妳高興，妳也可以寫壹個類庫來封裝它。但是要封裝Windows的消息驅動機制並不那麽容易。最自然的封裝方法是使用虛擬成員函數。如果您想要響應消息，請重載相應的虛函數。但令我驚訝的是，MFC采用了壹種“古老”的宏定義方法。使用宏定義方法的好處是節省虛函數VTable的系統開銷（因為Windows中的消息種類很多，開銷不會太小）。但是，缺點是映射不直觀。對於MFC來說，它“太直觀了”。雖然它的消息映射代碼可見，但“建議不要碰它”。好在VC的ClassWizard可以自動生成消息映射代碼，用起來相當方便。但是與VCL的授權模式相比，MFC的映射方法太落後了。因為在Delphi的對象Pascal中沒有“標準負擔”，所以該語言引入了組件、事件處理和屬性等新功能。因為功夫是編譯器級別的，生成的源代碼非常簡潔。看來VC是“讓框架容納語言”，Delphi是“讓語言容納框架”。
我想舉壹個封裝字符串操作的例子來說明MFC和VCL的優缺點。在MFC中，CStringList類具有添加、獲取和刪除功能，而VCL的TStringList類具有排序、讀入逗號分隔的字符串、流輸入和輸出等功能。但是同樣的字符串替換函數，VCL的StringReplace比MFC的CString::Replace慢2-3倍。壹般來說，VCL的封裝比MFC更高級、更抽象，但不可避免的問題是某些部分的效率略低於MFC。這就好比低級語言（如匯編）比高級語言（如Basic）有更高的執行效率，但編程效率更低。妳不能魚與熊掌兼得。
與MFC相比，VCL的另壹個優勢是它對異常處理的支持，而壹個大的缺點是它對多線程的支持較差。VCL的大部分都沒有針對多線程進行優化。盡管VCL提供了簡化多線程操作的類，但只有工作線程使用起來相對簡單。如果線程必須處理接口，事情就會變得麻煩，因為除了應用程序的主線程之外，沒有線程可以訪問任何可視化VCL組件。您必須使用Synchronize方法等待主線程處理其消息，然後在主線程中訪問VCL組件。另壹方面，MFC沒有這樣的限制。
穩定和完美:風險投資是老大哥。
VC比Delphi更加穩定和完善。VC的發展歷史比Delphi長，微軟的整體實力比InEnterprise強。VC的框架MFC經過這麽多年的發展和完善，功能非常全面和穩定，幾乎沒有bug。其中，您可能會遇到較少的bug。第三方有專門的工具來幫助妳避免這些錯誤。這種規模的類庫做到這壹點並不容易。不要小看這壹點，許多專業程序員都為此選擇了VC。因為盡管VCL比MFC更抽象，封裝水平更高，但它帶來的開發效率的提高對專家來說是有限的。如果妳遇到壹個奇怪的問題並調試了很長時間，妳會發現不是妳的代碼有問題，而是VCL的壹個錯誤。妳怎麽想呢?雖然不太可能遇到這種問題，但它將對VCL的形象產生很大影響。Delphi的IDE占用太多資源，啟動速度太慢，與某些顯卡驅動程序沖突，VCL中存在bug，調試器不夠健壯，對不穩定的第三方控件沒有保護措施...問題很多，Delphi在這方面不如VC。我希望我的企業可以通過上壹層樓梯來實現。對了，我們在網上看到有人對Delphi的不穩定性評價很高，說幾分鐘內有20多次非法操作。Delphi不如Visual C++穩定，但事實並非如此。我猜我朋友的Delphi安裝了壹些有問題的第三方控件，這導致Delphi經常出錯。妳為什麽不試著去掉那些控制？
便攜性:立足現實，展望未來。
InEnterprise正在開發Delphi的Linux版本，代號為Kylix。也許通過Kylix，有可能把用VCL框架編寫的Windows程序移植到Linux上。但這只是可能。因為目前InEnterprise的兼容性還沒有做好。低版本的Delphi不能使用高版本的VCL組件，高版本的Delphi不能使用低版本的VCL組件。令人憤慨的是，我們很少看到非二進制兼容的軟件。如果Windows 98不能運行95程序，Windows 95不能運行3.x程序，Win 3.x不能運行DOS程序，妳還會使用Windows嗎？如果Windows 95的程序必須重新編譯才能在98下運行，98會賣得這麽好嗎？“兄弟”C++Builder和Delphi不能使用彼此的組件，甚至同壹個VCL庫的文件名也不同。因此，壹個組件有不同的d 1/D2/D3/D4/D5/C 1/C3/C4/C5版本是很常見的，而且隨著Delphi和C++Builder的升級，這種情況可能會增加。希望InEnterprise能先解決兄弟們的兼容性問題。微軟的風投沒有這些問題。MFC1.0的程序也可以在VC6.0下毫無障礙地編譯和通過。
集成界面:宏觀和微觀
總的來說，VC的集成界面不如Delphi。Delphi只用壹個對象檢查器就可以比較VC的壹堆向導，更不用說代碼資源管理器、待辦事項列表等了。但是從壹個小的點上，我們可以看到Delphi的不成熟。例如，“自動完成”功能不如VC智能和詳細，其響應速度也不如VC快。
Visual C++帶來的MSDN是壹部信息量巨大、查詢方便的“開發人員百科全書”，比Delphi更專業。許多幫助項目都有源程序演示。
Delphi的OpenTools是壹個完全面向第三方的開放系統。開發人員可以修改Borland的許多功能，從IDE的可擴展性來看Delphi更好。
調試:詳細看真實作品。
Visual C++和Delphi的調試功能非常強大，它們都具有單步可視化調試、斷點跟蹤、運行時變量更改、鼠標指向獲取變量值等功能。還可以方便地管理DLL的輸入和輸出，並進行源代碼級調試。
相對來說，Visual C++可以更方便地看到變量的變化，包括將結構擴展為數據樹，從而知道每個變量的值。在每個調試步驟中，更改後的變量將被添加紅色，這使得調試更加方便。此外，Visual C++中的塊內存查看比Delphi更方便。
當然，德爾福也有許多體貼入微的地方。例如，在調試線程時，Delphi可以輕松檢查線程的變化，但Visual C++必須彈出壹個模式對話框。
數據庫開發:Delphi獨領風騷
數據庫支持是Delphi的強項。這主要體現在Delphi與BDE的無縫集成，以及Delphi提供的大量現成的數據庫操作控件。這是VC無法企及的。目前，Delphi支持三種數據庫訪問方法:BDE、ADO和InterBase。所有方法都可以拖入應用程序中以實現可視化操作。正是由於Delphi對數據庫類的打包，用戶在操作數據庫時不必像在Visual C++中那樣從頭幹預到尾。開發速度明顯提高。
在Delphi中使用WebBroker控件還可以方便地構建基於數據庫的網頁，並通過HTML管理Web數據庫。Visual C++主要通過ADO和OLEDB訪問數據，許多ActiveX控件也可以添加數據庫功能。但是沒有Paradox這樣的桌面數據庫，Access的相關功能就太弱了。也許SQL Server是壹個不錯的選擇。
COM:新技術的力量
COM是組件對象模型的縮寫。它是OLE和ActiveX技術的基礎。COM定義了壹組API和壹個二進制標準，這使得不同編程語言和平臺中的獨立對象能夠相互通信。
COM是微軟制定的行業標準。但是Delphi也為COM提供了強大的語言支持。支持接口、變量和寬字符串函數。COM的這些包確實比C++更方便。例如，用C++編程COM時（沒有類框架），變量被定義為oaidl.h文件中的變量結構。要處理變體，您必須在oleaut32.dll中手動調整variant xxxx（）API函數來初始化和管理它們，例如VariantInit（）、VariantCopy（）、VariantClear（）等。
Visual C++實現COM編程有壹種特殊的方法，那就是使用ATL。ATL使用Visual C++獨有的多重繼承來實現COM接口。雖然不壹定更容易實現COM服務和控件，但ATL與最新COM技術之間的接口在基於模板的構造方面優於Delphi。ATL更有利於建立小而快的COM組件程序。
根據目前的普遍觀點，Visual C++應用於COM服務程序更具優勢，而Delphi應用於COM組件程序更合適。
昨天、今天、明天。
在許多情況下，技術的進步是不斷變化的。最初，Borland的Turbo C和Borland C++幾乎是C/C++程序員的唯壹選擇。微軟的Quick C（現在有人知道這個產品嗎？）和微軟C/C++從來都不是主流。但是Borland C++流行了多少年了？它很快就被新崛起的Microsoft Visual C/C++所淹沒。因此，Enterprise（前身為Borland）重拾Turbo Pascal和Borland Pascal的榮耀（事實上，Borland的著名工作是第壹個Pascal編譯器），並全力推出了Delphi。Delphi剛推出時被稱為VB殺手，但VB仍然活得很好。畢竟微軟是從Basic起家的，VB不是那麽容易打敗的。Inprise想了想，沒有和VB爭論。它使用C++語言的Delphi IDE和VCL，推出C++Builder，並攻擊Visual C++市場。C++Builder似乎是壹個很好的妥協？再想想！Delphi具有C++Builder的所有優點，但C++Builder可能沒有Delphi的優點。比如C++Builder的編譯速度比VC慢，怎麽比得過Delphi？因為VCL是由對象Pascal編寫的，C++語言和VCL不能很好地協同工作。C++Builder中的bug比Delphi中的更多，甚至示例代碼中也有錯誤。VCL的某些功能無法使用，需要通過嵌入pascal代碼來訪問。C++Builder中可用的第三方控件比Delphi少得多。
唉，黃金無以復加。微軟和InEnterprise誰會笑到最後？
魚和熊掌:艱難的選擇
選擇開發工具取決於許多不同的因素，每個人都可能因為某種缺陷而放棄學習或使用某種語言。任何程序員都希望自己喜歡的工具能夠達到理想狀態。通過上面的不完美比較，我想每個人都有自己的看法。我們認為影響人們選擇開發語言的因素主要包括:
1）哪種語言更容易學？
學習語言需要大量的時間和精力。開發計劃的開發成本是壹個值得考慮的現實。壹個熟練的Delphi程序員和壹個熟練的VC程序員具有相同的工作效率。然而，要成為壹名熟練的程序員，您必須快速掌握壹門語言的技能。不幸的是，目前熟練的Visual C++程序員是十分之壹。相對來說，Delphi更適合初學者。
2）哪種語言的可繼承代碼更多？
語言代碼的可重用性是提高開發效率的壹個明顯方面。從早期的工藝、功能到現在的組件技術，我們都在朝著這個目標奮鬥。這兩種語言對代碼重用的理解是不同的。Delphi主要通過VCL控件實現代碼重用，而Visual C++實現起來更復雜。
3）語言本身的性質。
就技術（主要是應用程序框架）而言，Delphi目前領先於Visual C++。但是缺乏穩定性和穩健性使我“不容易說我愛妳”。雖然VC在今天已經發展到了壹個完美的水平，但MFC框架已經成為過去式。如果不使用MFC，目前沒有合適的替代品。根據自己的需求和實際情況做出選擇。事實上，Visual C++和Delphi不僅僅是競爭關系。它們在許多領域不重疊，甚至不互補。如何選擇取決於您項目的特點。如果在開發底層系統時需要出色的兼容性和穩定性，請選擇Visual C++。妳可以直接調用Windows的各種API而不是MFC。如果您編寫傳統的Windows桌面應用程序，Visual C++的MFC框架是壹個“正統”的選擇；如果界面部分占應用程序代碼的比例很大，或者在Delphi中有相關功能的控件，那麽Delphi是壹個事半功倍的選擇。如果您為企業開發數據庫和信息管理系統等高級應用程序（“高級”是相對於“低級/底層”而言的，並不是說技術先進或低級），並且期限很緊，則Delphi更好。如果妳熟悉的語言是Object Pascal，並且妳不打算學習復雜的C++，那麽Delphi幾乎是唯壹的選擇。傳統觀點認為Delphi適合於編寫Internet/Intranet、表格繪制、數據庫操作、高級用戶界面等。Visual C++適合編寫設備驅動程序、COM服務程序、科學計算、控制臺程序、WinCE應用程序和壹些小工具。不同的應用程序要求優秀的程序員同時精通兩種語言。
4）語言的前景和可擴展性。
德爾福是InEnterprise的旗艦產品之壹，其前景應該是樂觀的。此外，InEnterprise壹直在向Linux進軍，但微軟尚未采取行動。不幸的是，Delphi的創始人InEnterprise已經轉到微軟主持Visual J++和C#項目。我希望對InEnterprise的影響不會太大。
微軟的Visual C++前景如何？Visual Studio 7.0即將推出。這個版本將加強網絡開發的特點。看來微軟雖然被判解體，但其開發實力絲毫未受影響。
此外，雖然MFC有點落後，但並不意味著它不值得學習。其實不學MFC就是不學VC。使用MFC框架開發程序仍然是目前開發桌面應用程序的主流模式，並且將保持很長壹段時間。微軟首席執行官史蒂夫·鮑爾默曾經說過。NET將不得不等待2-3年。那麽，MFC至少還有2-3年的壽命。在技術日新月異的IT領域，2-3年確實是壹段很長的時間。好好利用。即使您不使用MFC框架，熟悉C++的OOP機制和Windows的底層功能也有助於您了解MFC的封裝機制。VCL的源代碼是Object Pascal，這對C/C++程序員沒有“額外”影響。