VC和Delphi作為開發(fā)平臺，很重要的一點(diǎn)就是提供了一個"無所不包"的應(yīng)用框架：VC的MFC和Delphi的VCL。MFC是用C++寫的，VCL是用Object Pascal寫的。當(dāng)然，我們都知道，C++的使用范圍比Object Pascal廣得多，移植性也好得多。這本來是優(yōu)點(diǎn)，但很有意思的是，正因?yàn)槿绱耍④泴慚FC時必須考慮最大限度減少對語言本身的改動，而把功夫下在源代碼級，以便能盡可能支持ANSI等標(biāo)準(zhǔn)，結(jié)果導(dǎo)致MFC的封裝復(fù)雜而不直觀。(尤其是它對消息的封裝，下文還會提到)。太多的宏定義和含義模糊且自動生成、不得改動的注釋使MFC乃至VC讓很多新手望而生畏，不敢"下水"深入學(xué)習(xí)。而Object Pascal幾乎是Inprise"專用"的，不必考慮"標(biāo)準(zhǔn)"問題，因此Inprise寫VCL時就把全部精力放在了結(jié)構(gòu)與性能上，結(jié)果語言與框架的磨合程度非常好。VCL框架的結(jié)構(gòu)清晰，VCL代碼的可讀性非常好。許多人說Delphi比較容易上手，也是這個緣故。天下沒有白吃的午餐。你要工業(yè)標(biāo)準(zhǔn)嗎？你要可移植性嗎(關(guān)于可移植性和兼容性，下文會詳細(xì)比較)？那么請面對MFC的"天書"級代碼吧。
編譯和連接：The Need For Speed
不同的語言帶來的另一個不同是，編譯和連接的速度的不同，以及執(zhí)行速度的不同。Delphi的編譯和連接速度，毫不夸張地說，比VC快幾十倍。即使把VC的Incremental Link選項打開，Delphi的編譯和連接速度仍比VC快好幾倍。并不是說微軟的編譯器不行，這是由C++的復(fù)雜性決定的。模板的處理、預(yù)處理和宏的展開都是很費(fèi)時的。前文不是提到Object Pascal沒有模板、預(yù)處理和宏嗎？這本來是缺點(diǎn)，但帶來的一個好處就是編譯速度極快。至于編譯完的二進(jìn)制代碼，在打開相同的優(yōu)化選項的情況下，Delphi和VC執(zhí)行速度并沒有太大的差別。
為了克服編譯的速度問題，C++編譯器一般需要增強(qiáng)的連接器和預(yù)處理機(jī)制。但是預(yù)處理機(jī)制仍然存在若干問題：1）程序調(diào)試的斷點(diǎn)行可能和代碼行不同；2）沒有將最新的代碼信息綜合進(jìn)去；3）容易產(chǎn)生錯誤的邏輯；4）因?yàn)樽x錯文件頭而很容易產(chǎn)生類似"Unexpected End of File"的錯誤。
兩個編譯器有個共同點(diǎn)是都能識別無用的"死"代碼，比如一個沒有用的函數(shù)等等。編譯后的程序?qū)⒉话@些多余的信息。Delphi在這方面作得更加出色。它可以讓你在編輯器中可視化地提示出那行代碼是"活"的、那行代碼是"死"的。這樣你就能整理出最精簡的代碼。Delphi在編譯后將在左邊顯示一個小藍(lán)點(diǎn)表示這行代碼是"活"的。Visual C++做不到這點(diǎn)。
Delphi編譯后可執(zhí)行文件至少有200K（如果不使用VCL，僅僅使用WinAPI，文件的大小將大大縮小）但是Visual C++編程使用MFC編譯后的可執(zhí)行文件通常只有幾十K，主要是因?yàn)槲④浺呀?jīng)將系統(tǒng)運(yùn)行庫包含在Windows系統(tǒng)了（Borland公司曾經(jīng)和微軟協(xié)商這個接口，但是微軟利用操作系統(tǒng)的優(yōu)勢不愿意公開）。同樣道理，使用BDE開發(fā)的的數(shù)據(jù)庫程序必須附帶3-5M的額外系統(tǒng)文件，也是非常不協(xié)調(diào)的。
非常有趣的是，Delphi能夠使用由C++ Builder創(chuàng)建的的OBJ文件，但是使用上受很大的局限性。
最后，Visual C++的編譯和連接時的錯誤信息比Delphi要詳細(xì)和具體的多。特別是使用ATL開發(fā)更加如此。
應(yīng)用框架：MFC？有KFC流行嗎？
應(yīng)用程序框架(Application Frame)，有時也稱為對象框架。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫(同樣，Delphi的VCL也不僅僅是一個控件庫，盡管它的名字叫"可視控件庫")。你如果選擇了MFC，也就選擇了一種程序結(jié)構(gòu)，一種編程風(fēng)格。MFC早在Windows 3.x的時代就出現(xiàn)了，那時的Visual C++還是16位的。經(jīng)過這些年的不斷補(bǔ)充和完善，MFC已經(jīng)十分成熟。但由于原型出現(xiàn)得比較早，MFC相比于VCL落后了一個時代。盡管微軟對MFC的更新沒有停止，我也經(jīng)常讀到"只要Windows不過時，MFC就不會過時"之類觀點(diǎn)的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。其實(shí)MFC是和OWL同一個時代的產(chǎn)物。OWL已經(jīng)不在了，MFC怎能不"居安思危"呢？如果MFC青春永駐，微軟的開發(fā)人員也不會"私自"開發(fā)出基于ATL的WTL呀。當(dāng)然，WTL的地位不能和MFC比，它并不是微軟官方支持的框架，封裝的功能也相當(dāng)有限。但至少也反襯出了MFC存在的不足。
我們以為，最能體現(xiàn)一個應(yīng)用程序框架的先進(jìn)性的是它的委托模型，即對Windows消息的封裝機(jī)制。對Windows API的封裝就不用說了吧。大同小異，也沒什么技術(shù)含量。如果高興，你也可以自己寫一個類庫來封裝。但對Windows消息驅(qū)動機(jī)制的封裝就不是那么容易的了。最自然的封裝方式是采用虛成員函數(shù)。如果要響應(yīng)某個消息就重載相應(yīng)的虛函數(shù)。但出乎我的意料，MFC采用的是"古老"的宏定義方法。用宏定義方法的好處是省去了虛函數(shù)VTable的系統(tǒng)開銷(由于Windows的消息種類很多，開銷不算太小)。不過帶來的缺點(diǎn)就是映射不太直觀。對于MFC，則是"太不直觀"了。它的消息映射代碼雖然是可見的，但"勸君莫碰"。好在VC的ClassWizard可以自動生成消息映射代碼，使用起來還算方便。但和VCL的委托模型相比，MFC的映射方法就顯得太落后了。而Delphi的Object Pascal因?yàn)闆]有"標(biāo)準(zhǔn)負(fù)擔(dān)"，語言引入了組件、事件處理、屬性等新特性。由于功夫做在編譯器級，生成的源代碼就顯得十分簡潔。似乎VC是"讓框架遷就語言"，而Delphi是"讓語言遷就框架"。
我想舉一個對字符串操作的封裝的例子來說明MFC和VCL的優(yōu)缺點(diǎn)。在MFC中，CStringList類有加入、獲取、刪除等功能，但VCL的TStringList類除了上述功能還有排序、從逗號分隔的字串讀入、流輸入輸出等功能。但同樣的字符串替換功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。總的來說，VCL的封裝比MFC更為高層，更為抽象，但不可避免地帶來的問題是某些部分執(zhí)行效率比MFC略低。這就象低級語言(如匯編)的執(zhí)行效率比高級語言(如Basic)高，但編程效率較低。魚和熊掌不可兼得嘛。
VCL比之MFC的另一優(yōu)點(diǎn)是對異常處理的支持，而一大缺點(diǎn)是對多線程支持差。VCL的大部分都不是針對多線程優(yōu)化的。雖說VCL提供了簡化多線程操作的類，但只是工作者線程(worker threads)使用起來比較簡單。如果線程要和界面打交道的話事情就變得麻煩了，因?yàn)槌藨?yīng)用程序的主線程，任何線程不能訪問任何可視的VCL部件。你不得不使用Synchronize方法等待主線程處理它的消息，然后在主線程中訪問VCL部件。而MFC就沒有這樣的限制。
穩(wěn)定性與完善程度：VC是老大哥
VC要比Delphi穩(wěn)定和完善。VC的發(fā)展歷史比Delphi長，微軟的總體實(shí)力比Inprise強(qiáng)。VC的框架MFC經(jīng)歷了那么多年的發(fā)展和完善，功能非常全面，而且十分穩(wěn)定，bug很少。其中你可能遇到的bug也更少。而且有第三方的專門工具幫助你避開這些bug。如此規(guī)模的一個類庫，能做到這一點(diǎn)不容易。不要小看了這一點(diǎn)，很多專業(yè)程序員就是為這個選擇VC的。因?yàn)楸M管VCL比MFC的抽象程度高，封裝較為高層，但由此帶來的開發(fā)效率的提高對高手來說畢竟是有限的。而如果你遇到一個怪問題，調(diào)試了半天，發(fā)現(xiàn)不是你的代碼有錯，而是VCL的bug，你作何感想？雖說遇到這類問題的可能性很小，但對VCL的形象的影響可不小。Delphi的IDE太占資源，啟動速度太慢，和某些顯卡驅(qū)動程序沖突，VCL中有bug，調(diào)試器不夠健壯，對不穩(wěn)定的第三方控件沒有防護(hù)措施 …… 問題多多，在這方面Delphi不如VC。希望Inprise能更上一層樓。順便說一下，我們在網(wǎng)上看到有些人極言Delphi的不穩(wěn)定，說幾分鐘出現(xiàn)20多次非法操作。Delphi的確不如Visual C++穩(wěn)定，但也不至于如此呀。我估計是那位朋友的Delphi裝了某些有問題的第三方控件，導(dǎo)致了Delphi的頻頻出錯。不妨卸下那些控件試試？
可移植性：立足現(xiàn)實(shí)，放眼未來
Inprise正在開發(fā)Delphi的Linux版本，代號為Kylix。也許通過Kylix，用VCL構(gòu)架編寫的Windows程序向Linux移植成為可能。但這只是可能。因?yàn)樵谀壳癐nprise的兼容性工作做得并不好。低版本的Delphi不能使用高版本的VCL組件，而高版本的Delphi竟然不能使用低版本的VCL組件。真是豈有此理，我們很少看見軟件有不向下二進(jìn)制兼容的。如果Windows 98不能運(yùn)行95的程序，Windows 95不能運(yùn)行3.x的程序，Win 3.x不能運(yùn)行DOS程序，你還會用Windows嗎？如果Windows 95的程序必須經(jīng)過重新編譯才能在98下運(yùn)行，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的不成熟。比如"自動完成"功能的智能化程度和提示詳細(xì)程度不如VC，響應(yīng)速度也沒有VC快。
Visual C++所帶的MSDN是一部"開發(fā)者的百科全書"，信息龐大，查詢方便，這方面比Delphi更專業(yè)。很多幫助項都有源程序示范。
Delphi的OpenTools是完全面向第三方的開放系統(tǒng)，開發(fā)者可以修改很多Borland公司自身的功能，從IDE的可擴(kuò)充性上說Delphi更好。
調(diào)試：細(xì)微之處見真功
Visual C++和Delphi的調(diào)試功能都非常強(qiáng)大，同時都具有單步可視化調(diào)試、斷點(diǎn)跟蹤、運(yùn)行時改變變量、鼠標(biāo)指向可以得到變量值等等功能。對DLL的輸入輸出也能方便的管理，能夠進(jìn)行源碼級別的調(diào)試。
相對而言，Visual C++能夠更加方便地看到變量的變化情況，這包括對結(jié)構(gòu)可以展開成數(shù)據(jù)樹，從而了解每一個變量的值，每一步調(diào)試，變化了的變量會加紅，從而使調(diào)試更加方便。另外，Visual C++的塊內(nèi)存察看比Delphi也要方便。
當(dāng)然，Delphi也有很多體貼的細(xì)微之處，比如在線程調(diào)試的時候，Delphi能夠很方便地察看線程的變化，Visual C++卻必須要彈出一個模式對話框。
數(shù)據(jù)庫開發(fā)：Delphi一枝獨(dú)秀
數(shù)據(jù)庫支持是Delphi的強(qiáng)項。這主要體現(xiàn)在Delphi與BDE的無縫集成，以及Delphi提供的那一大堆現(xiàn)成的數(shù)據(jù)庫操作控件。這是VC望塵莫及的。目前Delphi支持BDE、ADO、InterBase三種數(shù)據(jù)庫訪問方式。所有的方式都能拖拉到應(yīng)用程序中實(shí)現(xiàn)可視化操作。正是因?yàn)镈elphi對數(shù)據(jù)庫類的包裝，使得用戶操作數(shù)據(jù)庫不像在Visual C++中必須從開始到最后都要干預(yù)。明顯地提高了開發(fā)速度。
Delphi中使用WebBroker控件還能很方便地構(gòu)造出基于數(shù)據(jù)庫的Web頁面，通過HTML管理Web數(shù)據(jù)庫。 Visual C++訪問數(shù)據(jù)主要通過ADO和OLEDB，很多ActiveX控件也能添加數(shù)據(jù)庫功能。但是沒有像Paradox這樣的桌面數(shù)據(jù)庫，Access相對功能太弱了。也許SQL Server是不錯的選擇。
COM：新技術(shù)的力量
COM是組件對象模型的縮寫。它是OLE和ActiveX技術(shù)的基礎(chǔ)，COM定義了一組API和一個二進(jìn)制標(biāo)準(zhǔn)，讓不同的編程語言、不同平臺的彼此獨(dú)立的對象相互進(jìn)行通訊。
COM是Microsoft制訂的行業(yè)標(biāo)準(zhǔn)。但Delphi也為COM提供了強(qiáng)大的語言支持。支持接口、variant、寬字符串功能。這些對COM的封裝確實(shí)比C++更方便。比如在C++（沒有類框架）進(jìn)行COM編程時，變體定義為oaidl.h文件中的VARIANT結(jié)構(gòu)。要處理變體，必須手工調(diào)整oleaut32.dll中VariantXXXX() API函數(shù)對其進(jìn)行初始化和管理，如VariantInit()、VariantCopy()、VariantClear()等等。
Visual C++實(shí)現(xiàn)COM編程有一種特殊的方法就是使用ATL。ATL使用Visual C++特有的多重繼承來實(shí)現(xiàn)COM接口。雖然不見得實(shí)現(xiàn)COM服務(wù)和控制更容易，但是ATL和最新COM技術(shù)的接口，基于模板的構(gòu)造都比Delphi強(qiáng)。ATL更有利于建立小巧、快捷的COM組件程序。
按目前通用的觀點(diǎn)，Visual C++應(yīng)用到COM服務(wù)程序更有優(yōu)勢，Delphi應(yīng)用到COM組件程序更合適。
昨天，今天，明天
技術(shù)的進(jìn)步在很多時候是此消彼長的。當(dāng)初Borland的Turbo C和Borland C++幾乎是C/C++程序員唯一的選擇。微軟的Quick C(現(xiàn)在還有人知道這個產(chǎn)品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++壓下去了。于是Inprise(原Borland)揀起了當(dāng)年Turbo Pascal和Borland Pascal的輝煌(事實(shí)上Borland的成名作就是第一個Pascal編譯器)，全力推出了Delphi。Delphi當(dāng)初推出時被稱為VB殺手，但VB現(xiàn)在仍然活得挺好。畢竟微軟是靠Basic起家的嘛，VB不是那么容易被打敗的。Inprise想了想不和VB爭了，使用Delphi的IDE和VCL配上C++語言，推出了C++Builder，又向Visual C++的市場發(fā)起了夾攻。C++Builder似乎是個不錯的折衷選擇了？再仔細(xì)想想！C++Builder的優(yōu)點(diǎn)Delphi都有，但Delphi的優(yōu)點(diǎn)C++Builder未必有。比如C++Builder的編譯速度比VC還慢，哪能和Delphi比？而且因?yàn)閂CL是Object Pascal寫的，C++語言和VCL磨合得并不好。C++Builder的bug比Delphi還多，甚至Sample代碼中還有錯。VCL的部分功能不能使用，要靠嵌入pascal代碼訪問。C++Builder可用的第三方控件遠(yuǎn)沒有Delphi多。
唉，真是金無足赤。Microsoft和Inprise，誰會笑在最后呢？
魚和熊掌：艱難的選擇
選擇一個開發(fā)工具依賴于很多不同的因素，每個人都能因?yàn)槟撤N語言的某個缺陷而放棄學(xué)習(xí)或使用這種語言。任何程序員都希望自己喜歡的工具能達(dá)到理想的境界，通過上面不完善的比較，我想大家都有自己的看法。我們認(rèn)為影響大家選擇開發(fā)語言的因素主要包括：
1） 哪門語言更容易入門？
學(xué)習(xí)一種語言需要投入大量的時間和精力。開發(fā)程序的開發(fā)成本是值得考慮的現(xiàn)實(shí)。一個熟練的Delphi程序員和一個熟練的VC程序員工作效率是一樣的。但是，成為熟練的程序員必須很快掌握一門語言的技巧。不幸的是，目前熟練的Visual C++程序員是十里挑一。相對而言，Delphi更適合初學(xué)者。
2） 哪門語言有更多可繼承的代碼？
語言代碼的可重用性是加快開發(fā)效率明顯方面，從早期的過程、函數(shù)到現(xiàn)在的組件技術(shù)都是朝這個目標(biāo)在奮斗。這兩種語言對代碼重用的理解是不一樣的，Delphi主要通過VCL控件來實(shí)現(xiàn)代碼重用，Visual C++實(shí)現(xiàn)起來就比較復(fù)雜。
3） 語言自身的本性。
就技術(shù)(主要指應(yīng)用框架)來說，Delphi目前領(lǐng)先于Visual C++。但穩(wěn)定性和健壯性的不足又讓我對Inprise"想說愛你不容易"。而VC盡管發(fā)展到今日已十分完善，但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。根據(jù)你的需要和實(shí)際情況做選擇吧。實(shí)際上Visual C++和Delphi也不是簡單競爭關(guān)系。它們在許多領(lǐng)域并不重疊，甚至是互補(bǔ)的。到底怎樣取舍，要根據(jù)你的項目特性決定。如果你開發(fā)系統(tǒng)底層的東西，需要極好的兼容性和穩(wěn)定性，選Visual C++吧。你可以只調(diào)用Windows的各種API，不用MFC。如果你寫傳統(tǒng)的Windows桌面應(yīng)用程序，Visual C++的MFC框架是"正統(tǒng)"的選擇；如果界面部分占這個應(yīng)用程序代碼比例較大的話，或者Delphi中有相關(guān)功能的控件的話，Delphi是事半功倍的選擇。如果你為企業(yè)開發(fā)數(shù)據(jù)庫、信息管理系統(tǒng)等高層應(yīng)用("高層"是相對于"低層/底層"而言的，不是說技術(shù)高級或低級)，而且有比較緊的期限限制，選Delphi比較好。如果你熟悉的語言是Object Pascal，又不打算學(xué)復(fù)雜的C++，那么Delphi幾乎是唯一的選擇。傳統(tǒng)的觀點(diǎn)是：Delphi適合編寫Internet/Intranet、表格制圖、數(shù)據(jù)庫操作、高級用戶界面等等。Visual C++適合編寫設(shè)備驅(qū)動、COM服務(wù)程序、科學(xué)計算、控制臺（console）程序、WinCE的應(yīng)用和一些小的工具等等。應(yīng)用范圍的不同要求好的程序員同時精通這兩門語言。
4） 語言的前景和可擴(kuò)充性。
Delphi是Inprise的旗艦產(chǎn)品之一，前景應(yīng)當(dāng)還是比較樂觀的，而且Inprise已經(jīng)在向Linux進(jìn)軍了，而微軟還遲遲沒有動作。遺憾的是，Inprise公司Delphi的創(chuàng)始人已經(jīng)跳槽到微軟去主持Visual J++和C#項目了。但愿對Inprise沖擊不會太大。
微軟的Visual C++的前景又怎樣呢？Visual Studio 7.0就要推出了。這一版本將加強(qiáng)網(wǎng)絡(luò)開發(fā)的特性。看來微軟雖然被判解體，開發(fā)實(shí)力可是一點(diǎn)沒打折扣。
另外，雖說MFC已稍顯落后，但不是說它不值得學(xué)。事實(shí)上，不學(xué)MFC就等于沒學(xué)VC。利用MFC框架開發(fā)程序仍然是目前開發(fā)桌面應(yīng)用的主流模式，而且還會保持相當(dāng)長的時間。微軟公司CEO史蒂夫·巴爾默(Steve Ballmer)曾說，.NET流行還得等2－3年。那么，MFC至少還有2－3年的生命空間。在技術(shù)日新月異的IT界，2－3年實(shí)在是很長一段時間了。好好把握吧。即使你不使用MFC框架，花點(diǎn)時間看一下MFC的封裝機(jī)制對你熟悉C++的OOP機(jī)制和Windows底層功能也是很有好處的。而VCL的源代碼是Object Pascal的，對C/C++程序員就沒有這個"額外"的作用了。
Qt工具包是一個C++類庫，并且是使用“一次編寫，隨處編譯”的方式用于構(gòu)建多平臺圖形用戶界面程序的一套工具。Qt使程序員通過使用一個單一源程序來構(gòu)建應(yīng)用程序。該應(yīng)用程序可以運(yùn)行在Windows 95到XP、Mac OS X、Linux、Solaris、HP-UX和其它很多使用X11的Unix版本上。還有一個Qt的版本可以用于嵌入式Linux，它和桌面版本具有相同的應(yīng)用程序編程接口.Qt是一個多平臺的C++圖形用戶界面應(yīng)用程序框架。它提供給應(yīng)用程序開發(fā)者建立藝術(shù)級的圖形用戶界面所需的所用功能。Qt是完全面向?qū)ο蟮暮苋菀讛U(kuò)展，并且允許真正地組件編程.從1996年早些時候，Qt進(jìn)入商業(yè)領(lǐng)域，它已經(jīng)成為全世界范圍內(nèi)數(shù)千種成功的應(yīng)用程序的基礎(chǔ)。Qt也是流行的Linux桌面環(huán)境KDE 的基礎(chǔ)，KDE是所有主要的Linux發(fā)行版的一個標(biāo)準(zhǔn)組件。
