看完讓我對VC BCB Delphi了解更多 原本是Vicen兄在本區發表的 但為簡體,我轉一下,老文章大家在看看吧  --------------------------------------- 開發工具大比拚之Visual C++ VS Delphi  轉載自 CSDN    引言      "Visual C++與Delphi之比較"最近在CSDN的論壇上的討論非常火熱，本文將以一個程序員的角度，從技術水平、功能、性能、易用性、穩定性、發展歷程和前景等方面，以Visual C++6和Delphi5為代表，盡可能客觀地比較介紹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++編譯器一般需要增強的連接器和預處理機制。但是預處理機制仍然存在若干問題：1）程序調試的斷點行可能和代碼行不同；２）沒有將最新的代碼信息綜合進去；３）容易產生錯誤的邏輯；４）因為讀錯文件頭而很容易產生類似"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文件，但是使用上受很大的局限性。      最後，Visual C++的編譯和連接時的錯誤信息比Delphi要詳細和具體的多。特別是使用ATL開發更加如此。    應用框架：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++卻必須要彈出一個模式對話框。    數據庫開發：Delphi一枝獨秀     數據庫支持是Delphi的強項。這主要體現在Delphi與BDE的無縫集成，以及Delphi提供的那一大堆現成的數據庫操作控件。這是VC望塵莫及的。目前Delphi支持BDE、ADO、InterBase三種數據庫訪問方式。所有的方式都能拖拉到應用程序中實現可視化操作。正是因為Delphi對數據庫類的包裝，使得用戶操作數據庫不像在Visual C++中必須從開始到最後都要干預。明顯地提高了開發速度。      Delphi中使用WebBroker控件還能很方便地構造出基於數據庫的Web頁面，通過HTML管理Web數據庫。 Visual C++訪問數據主要通過ADO和OLEDB，很多ActiveX控件也能添加數據庫功能。但是沒有像Paradox這樣的桌面數據庫，Access相對功能太弱了。也許SQL Server是不錯的選擇。    COM：新技術的力量     COM是組件對像模型的縮寫。它是OLE和ActiveX技術的基礎，COM定義了一組API和一個二進制標準，讓不同的編程語言、不同平台的彼此獨立的對象相互進行通訊。      COM是Microsoft制訂的行業標準。但Delphi也為COM提供了強大的語言支持。支持接口、variant、寬字符串功能。這些對COM的封裝確實比C++更方便。比如在C++（沒有類框架）進行COM編程時，變體定義為oaidl.h文件中的VARIANT結構。要處理變體，必須手工調整oleaut32.dll中VariantXXXX() 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(現在還有人知道這個產品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++壓下去了。於是Inprise(原Borland)揀起了當年Turbo Pascal和Borland Pascal的輝煌(事實上Borland的成名作就是第一個Pascal編譯器)，全力推出了Delphi。Delphi當初推出時被稱為VB殺手，但VB現在仍然活得挺好。畢竟微軟是靠Basic起家的嘛，VB不是那麼容易被打敗的。Inprise想了想不和VB爭了，使用Delphi的IDE和VCL配上C++語言，推出了C++Builder，又向Visual C++的市場發起了夾攻。C++Builder似乎是個不錯的折衷選擇了？再仔細想想！C++Builder的優點Delphi都有，但Delphi的優點C++Builder未必有。比如C++Builder的編譯速度比VC還慢，哪能和Delphi比？而且因為VCL是Object Pascal寫的，C++語言和VCL磨合得並不好。C++Builder的bug比Delphi還多，甚至Sample代碼中還有錯。VCL的部分功能不能使用，要靠嵌入pascal代碼訪問。C++Builder可用的第三方控件遠沒有Delphi多。       唉，真是金無足赤。Microsoft和Inprise，誰會笑在最後呢？    魚和熊掌：艱難的選擇     選擇一個開發工具依賴於很多不同的因素，每個人都能因為某種語言的某個缺陷而放棄學習或使用這種語言。任何程序員都希望自己喜歡的工具能達到理想的境界，通過上面不完善的比較，我想大家都有自己的看法。我們認為影響大家選擇開發語言的因素主要包括：     １） 哪門語言更容易入門？  學習一種語言需要投入大量的時間和精力。開發程序的開發成本是值得考慮的現實。一個熟練的Delphi程序員和一個熟練的VC程序員工作效率是一樣的。但是，成為熟練的程序員必須很快掌握一門語言的技巧。不幸的是，目前熟練的Visual C++程序員是十里挑一。相對而言，Delphi更適合初學者。     ２） 哪門語言有更多可繼承的代碼？  語言代碼的可重用性是加快開發效率明顯方面，從早期的過程、函數到現在的組件技術都是朝這個目標在奮鬥。這兩種語言對代碼重用的理解是不一樣的，Delphi主要通過VCL控件來實現代碼重用，Visual C++實現起來就比較複雜。     ３） 語言自身的本性。  就技術(主要指應用框架)來說，Delphi目前領先於Visual C++。但穩定性和健壯性的不足又讓我對Inprise"想說愛你不容易"。而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服務程序、科學計算、控制台（console）程序、WinCE的應用和一些小的工具等等。應用範圍的不同要求好的程序員同時精通這兩門語言。     ４） 語言的前景和可擴充性。  Delphi是Inprise的旗艦產品之一，前景應當還是比較樂觀的，而且Inprise已經在向Linux進軍了，而微軟還遲遲沒有動作。遺憾的是，Inprise公司Delphi的創始人已經跳槽到微軟去主持Visual J++和C#項目了。但願對Inprise衝擊不會太大。      微軟的Visual C++的前景又怎樣呢？Visual Studio 7.0就要推出了。這一版本將加強網絡開發的特性。看來微軟雖然被判解體，開發實力可是一點沒打折扣。       另外，雖說MFC已稍顯落後，但不是說它不值得學。事實上，不學MFC就等於沒學VC。利用MFC框架開發程序仍然是目前開發桌面應用的主流模式，而且還會保持相當長的時間。微軟公司CEO史蒂夫·巴爾默(Steve Ballmer)曾說，.NET流行還得等2－3年。那麼，MFC至少還有2－3年的生命空間。在技術日新月異的IT界，2－3年實在是很長一段時間了。好好把握吧。即使你不使用MFC框架，花點時間看一下MFC的封裝機制對你熟悉C++的OOP機制和Windows底層功能也是很有好處的。而VCL的源代碼是Object Pascal的，對C/C++程序員就沒有這個"額外"的作用了。     參考文獻：     Programming Microsoft Visual C++, 5th Edition, by Scot Wingo & George Shepherd  MSDN, by Microsoft Corp.  Visual C++ versus Delphi, by John M. Jacobson BorlandC++Builder3Unleashed,byCharlieCalvert,etal.  Borland Delphi 5-Developer's Guide,by Inprise Corp.      在研讀侯捷先生的【深入淺出 MFC】 可下載電子檔 http://www.jjhou.com/free-u002p.htm