引言

　　"Visual C++與Delphi之比較"最近在CSDN的論壇上的討論非常火熱，本文將以一個(gè)程序員的角度，從技術(shù)水平、功能、性能、易用性、穩(wěn)定性、發(fā)展歷程和前景等方面，以Visual C++6和Delphi5為代表，盡可能客觀地比較介紹Visual C++和Delphi這兩大主流開發(fā)工具的優(yōu)缺點(diǎn)，其中將涉及到語言、應(yīng)用框架、控件、編譯和連接、集成界面、調(diào)試、COM、數(shù)據(jù)庫開發(fā)等。本文還將對(duì)如何選擇使用這兩個(gè)開發(fā)工具提出一些建議。 　　

　　值得一提的是，由于C++Builder與Delphi同為Inprise公司產(chǎn)品，它們除了使用的語言不同，其余特性幾乎都相同。因此本文對(duì)C++Builder程序員和學(xué)習(xí)者也有參考價(jià)值。

語言：存在即是合理

　　首先聲明常被混淆的一點(diǎn)：VC和Delphi本身不是語言，而是開發(fā)平臺(tái)。它們所用的語言分別是略作擴(kuò)展的C/C++和Object Pascal。我在網(wǎng)上常看到有人問應(yīng)該學(xué)C/C++還是VC，這個(gè)問題很好回答：如果你學(xué)VC你就必須得學(xué)C/C++，或者說你學(xué)會(huì)了VC也就學(xué)會(huì)了C/C++了。 　　

　　言歸正傳，我們來比較一下C++和Object Pascal的優(yōu)缺點(diǎn)。有人認(rèn)為Object Pascal是"玩具語言"，C++才是"專業(yè)語言"，這是不對(duì)的。單從語言本身看，Object Pascal與C++屬同一重量級(jí)。它們都是完全支持面向?qū)ο蟮恼Z言，都扎根于"歷史悠久"的面向過程的語言。C++是由C發(fā)展而來的，Object Pascal由Pascal進(jìn)化而來。它們都有很強(qiáng)的靈活性，都有自己的特長(zhǎng)和不足。比如說，Object Pascal不支持多重繼承、模板、操作符重載、內(nèi)聯(lián)函數(shù)定義、預(yù)處理、宏、全局靜態(tài)類變量、嵌套類定義，等等，而這些都是C++支持的。但同樣地C++也不支持Object Pascal的虛構(gòu)造函數(shù)、過程嵌套、內(nèi)置集合類型、內(nèi)置字符串類型、"finally"構(gòu)造等等，在RTTI方面Object Pascal也比C++做得好。但這些并不重要，因?yàn)榭梢酝ㄟ^其它方式達(dá)到同樣的目的，比如C++可以通過類擴(kuò)展支持集合、字符串，Object Pascal可以通過"interface"多重繼承，等等。關(guān)鍵是二者都可以很好地完成你手頭的任務(wù)，這就夠了。 　　

　　但是，僅僅比較語言本身是不夠的，還得看它們的被接受和流行程度，學(xué)習(xí)曲線，發(fā)展前途，可移植性等，以及，很重要但常常被忽略的一點(diǎn)：與開發(fā)環(huán)境(指VC與Delphi)及其應(yīng)用框架的"磨合"程度。 　　

　　VC和Delphi作為開發(fā)平臺(tái)，很重要的一點(diǎn)就是提供了一個(gè)"無所不包"的應(yīng)用框架：VC的MFC和Delphi的VCL。MFC是用C++寫的，VCL是用Object Pascal寫的。當(dāng)然，我們都知道，C++的使用范圍比Object Pascal廣得多，移植性也好得多。這本來是優(yōu)點(diǎn)，但很有意思的是，正因?yàn)槿绱耍④泴慚FC時(shí)必須考慮最大限度減少對(duì)語言本身的改動(dòng)，而把功夫下在源代碼級(jí)，以便能盡可能支持ANSI等標(biāo)準(zhǔn)，結(jié)果導(dǎo)致MFC的封裝復(fù)雜而不直觀。(尤其是它對(duì)消息的封裝，下文還會(huì)提到)。太多的宏定義和含義模糊且自動(dòng)生成、不得改動(dòng)的注釋使MFC乃至VC讓很多新手望而生畏，不敢"下水"深入學(xué)習(xí)。而Object Pascal幾乎是Inprise"專用"的，不必考慮"標(biāo)準(zhǔn)"問題，因此Inprise寫VCL時(shí)就把全部精力放在了結(jié)構(gòu)與性能上，結(jié)果語言與框架的磨合程度非常好。VCL框架的結(jié)構(gòu)清晰，VCL代碼的可讀性非常好。許多人說Delphi比較容易上手，也是這個(gè)緣故。天下沒有白吃的午餐。你要工業(yè)標(biāo)準(zhǔn)嗎？你要可移植性嗎(關(guān)于可移植性和兼容性，下文會(huì)詳細(xì)比較)？那么請(qǐng)面對(duì)MFC的"天書"級(jí)代碼吧。

編譯和連接：The Need For Speed

　　不同的語言帶來的另一個(gè)不同是，編譯和連接的速度的不同，以及執(zhí)行速度的不同。Delphi的編譯和連接速度，毫不夸張地說，比VC快幾十倍。即使把VC的Incremental Link選項(xiàng)打開，Delphi的編譯和連接速度仍比VC快好幾倍。并不是說微軟的編譯器不行，這是由C++的復(fù)雜性決定的。模板的處理、預(yù)處理和宏的展開都是很費(fèi)時(shí)的。前文不是提到Object Pascal沒有模板、預(yù)處理和宏嗎？這本來是缺點(diǎn)，但帶來的一個(gè)好處就是編譯速度極快。至于編譯完的二進(jìn)制代碼，在打開相同的優(yōu)化選項(xiàng)的情況下，Delphi和VC執(zhí)行速度并沒有太大的差別。

　　為了克服編譯的速度問題，C++編譯器一般需要增強(qiáng)的連接器和預(yù)處理機(jī)制。但是預(yù)處理機(jī)制仍然存在若干問題：1）程序調(diào)試的斷點(diǎn)行可能和代碼行不同；２）沒有將最新的代碼信息綜合進(jìn)去；３）容易產(chǎn)生錯(cuò)誤的邏輯；４）因?yàn)樽x錯(cuò)文件頭而很容易產(chǎn)生類似"Unexpected End of File"的錯(cuò)誤。

　　兩個(gè)編譯器有個(gè)共同點(diǎn)是都能識(shí)別無用的"死"代碼，比如一個(gè)沒有用的函數(shù)等等。編譯后的程序?qū)⒉话@些多余的信息。Delphi在這方面作得更加出色。它可以讓你在編輯器中可視化地提示出那行代碼是"活"的、那行代碼是"死"的。這樣你就能整理出最精簡(jiǎn)的代碼。Delphi在編譯后將在左邊顯示一個(gè)小藍(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é)商這個(gè)接口，但是微軟利用操作系統(tǒng)的優(yōu)勢(shì)不愿意公開）。同樣道理，使用BDE開發(fā)的的數(shù)據(jù)庫程序必須附帶3-5M的額外系統(tǒng)文件，也是非常不協(xié)調(diào)的。

　　非常有趣的是，Delphi能夠使用由C++ Builder創(chuàng)建的的OBJ文件，但是使用上受很大的局限性。

　　最后，Visual C++的編譯和連接時(shí)的錯(cuò)誤信息比Delphi要詳細(xì)和具體的多。特別是使用ATL開發(fā)更加如此。

應(yīng)用框架：MFC？有KFC流行嗎？

　　應(yīng)用程序框架(Application Frame)，有時(shí)也稱為對(duì)象框架。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的一個(gè)類庫(同樣，Delphi的VCL也不僅僅是一個(gè)控件庫，盡管它的名字叫"可視控件庫")。你如果選擇了MFC，也就選擇了一種程序結(jié)構(gòu)，一種編程風(fēng)格。MFC早在Windows 3.x的時(shí)代就出現(xiàn)了，那時(shí)的Visual C++還是16位的。經(jīng)過這些年的不斷補(bǔ)充和完善，MFC已經(jīng)十分成熟。但由于原型出現(xiàn)得比較早，MFC相比于VCL落后了一個(gè)時(shí)代。盡管微軟對(duì)MFC的更新沒有停止，我也經(jīng)常讀到"只要Windows不過時(shí)，MFC就不會(huì)過時(shí)"之類觀點(diǎn)的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。其實(shí)MFC是和OWL同一個(gè)時(shí)代的產(chǎn)物。OWL已經(jīng)不在了，MFC怎能不"居安思危"呢？如果MFC青春永駐，微軟的開發(fā)人員也不會(huì)"私自"開發(fā)出基于ATL的WTL呀。當(dāng)然，WTL的地位不能和MFC比，它并不是微軟官方支持的框架，封裝的功能也相當(dāng)有限。但至少也反襯出了MFC存在的不足。 　　

　　我們以為，最能體現(xiàn)一個(gè)應(yīng)用程序框架的先進(jìn)性的是它的委托模型，即對(duì)Windows消息的封裝機(jī)制。對(duì)Windows API的封裝就不用說了吧。大同小異，也沒什么技術(shù)含量。如果高興，你也可以自己寫一個(gè)類庫來封裝。但對(duì)Windows消息驅(qū)動(dòng)機(jī)制的封裝就不是那么容易的了。最自然的封裝方式是采用虛成員函數(shù)。如果要響應(yīng)某個(gè)消息就重載相應(yīng)的虛函數(shù)。但出乎我的意料，MFC采用的是"古老"的宏定義方法。用宏定義方法的好處是省去了虛函數(shù)VTable的系統(tǒng)開銷(由于Windows的消息種類很多，開銷不算太小)。不過帶來的缺點(diǎn)就是映射不太直觀。對(duì)于MFC，則是"太不直觀"了。它的消息映射代碼雖然是可見的，但"勸君莫碰"。好在VC的ClassWizard可以自動(dòng)生成消息映射代碼，使用起來還算方便。但和VCL的委托模型相比，MFC的映射方法就顯得太落后了。而Delphi的Object Pascal因?yàn)闆]有"標(biāo)準(zhǔn)負(fù)擔(dān)"，語言引入了組件、事件處理、屬性等新特性。由于功夫做在編譯器級(jí)，生成的源代碼就顯得十分簡(jiǎn)潔。似乎VC是"讓框架遷就語言"，而Delphi是"讓語言遷就框架"。 　　

　　我想舉一個(gè)對(duì)字符串操作的封裝的例子來說明MFC和VCL的優(yōu)缺點(diǎn)。在MFC中，CStringList類有加入、獲取、刪除等功能，但VCL的TStringList類除了上述功能還有排序、從逗號(hào)分隔的字串讀入、流輸入輸出等功能。但同樣的字符串替換功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。總的來說，VCL的封裝比MFC更為高層，更為抽象，但不可避免地帶來的問題是某些部分執(zhí)行效率比MFC略低。這就象低級(jí)語言(如匯編)的執(zhí)行效率比高級(jí)語言(如Basic)高，但編程效率較低。魚和熊掌不可兼得嘛。 　　

　　VCL比之MFC的另一優(yōu)點(diǎn)是對(duì)異常處理的支持，而一大缺點(diǎn)是對(duì)多線程支持差。VCL的大部分都不是針對(duì)多線程優(yōu)化的。雖說VCL提供了簡(jiǎn)化多線程操作的類，但只是工作者線程(worker threads)使用起來比較簡(jiǎn)單。如果線程要和界面打交道的話事情就變得麻煩了，因?yàn)槌藨?yīng)用程序的主線程，任何線程不能訪問任何可視的VCL部件。你不得不使用Synchronize方法等待主線程處理它的消息，然后在主線程中訪問VCL部件。而MFC就沒有這樣的限制。

穩(wěn)定性與完善程度：VC是老大哥

　　VC要比Delphi穩(wěn)定和完善。VC的發(fā)展歷史比Delphi長(zhǎng)，微軟的總體實(shí)力比Inprise強(qiáng)。VC的框架MFC經(jīng)歷了那么多年的發(fā)展和完善，功能非常全面，而且十分穩(wěn)定，bug很少。其中你可能遇到的bug也更少。而且有第三方的專門工具幫助你避開這些bug。如此規(guī)模的一個(gè)類庫，能做到這一點(diǎn)不容易。不要小看了這一點(diǎn)，很多專業(yè)程序員就是為這個(gè)選擇VC的。因?yàn)楸M管VCL比MFC的抽象程度高，封裝較為高層，但由此帶來的開發(fā)效率的提高對(duì)高手來說畢竟是有限的。而如果你遇到一個(gè)怪問題，調(diào)試了半天，發(fā)現(xiàn)不是你的代碼有錯(cuò)，而是VCL的bug，你作何感想？雖說遇到這類問題的可能性很小，但對(duì)VCL的形象的影響可不小。Delphi的IDE太占資源，啟動(dòng)速度太慢，和某些顯卡驅(qū)動(dòng)程序沖突，VCL中有bug，調(diào)試器不夠健壯，對(duì)不穩(wěn)定的第三方控件沒有防護(hù)措施 …… 問題多多，在這方面Delphi不如VC。希望Inprise能更上一層樓。順便說一下，我們?cè)诰W(wǎng)上看到有些人極言Delphi的不穩(wěn)定，說幾分鐘出現(xiàn)20多次非法操作。Delphi的確不如Visual C++穩(wěn)定，但也不至于如此呀。我估計(jì)是那位朋友的Delphi裝了某些有問題的第三方控件，導(dǎo)致了Delphi的頻頻出錯(cuò)。不妨卸下那些控件試試？

可移植性：立足現(xiàn)實(shí)，放眼未來

　　Inprise正在開發(fā)Delphi的Linux版本，代號(hào)為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程序，你還會(huì)用Windows嗎？如果Windows 95的程序必須經(jīng)過重新編譯才能在98下運(yùn)行，98會(huì)賣得那么好嗎？"同門兄弟"C++Builder和Delphi也不能互相使用對(duì)方的組件，甚至同一套VCL庫的文件名也不一樣。所以一個(gè)組件有for D1/D2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著Delphi和C++Builder版本的升級(jí)可能還會(huì)增加。希望Inprise能先解決同門兄弟的兼容性問題。而微軟的VC就沒有這類問題。MFC1.0的程序也可以毫無障礙地在VC6.0下編譯通過。

集成界面：宏觀與微觀

　　就大處說，VC的集成界面是不如Delphi的。Delphi僅僅一個(gè)Object Inspector就可以將VC的一堆Wizards比下去，何況它還有Code Explorer、ToDo List等。但從小處，又可以看出Delphi的不成熟。比如"自動(dòng)完成"功能的智能化程度和提示詳細(xì)程度不如VC，響應(yīng)速度也沒有VC快。

　　Visual C++所帶的MSDN是一部"開發(fā)者的百科全書"，信息龐大，查詢方便，這方面比Delphi更專業(yè)。很多幫助項(xiàng)都有源程序示范。

　　Delphi的OpenTools是完全面向第三方的開放系統(tǒng)，開發(fā)者可以修改很多Borland公司自身的功能，從IDE的可擴(kuò)充性上說Delphi更好。

調(diào)試：細(xì)微之處見真功

　　Visual C++和Delphi的調(diào)試功能都非常強(qiáng)大，同時(shí)都具有單步可視化調(diào)試、斷點(diǎn)跟蹤、運(yùn)行時(shí)改變變量、鼠標(biāo)指向可以得到變量值等等功能。對(duì)DLL的輸入輸出也能方便的管理，能夠進(jìn)行源碼級(jí)別的調(diào)試。

　　相對(duì)而言，Visual C++能夠更加方便地看到變量的變化情況，這包括對(duì)結(jié)構(gòu)可以展開成數(shù)據(jù)樹，從而了解每一個(gè)變量的值，每一步調(diào)試，變化了的變量會(huì)加紅，從而使調(diào)試更加方便。另外，Visual C++的塊內(nèi)存察看比Delphi也要方便。

　　當(dāng)然，Delphi也有很多體貼的細(xì)微之處，比如在線程調(diào)試的時(shí)候，Delphi能夠很方便地察看線程的變化，Visual C++卻必須要彈出一個(gè)模式對(duì)話框。

數(shù)據(jù)庫開發(fā)：Delphi一枝獨(dú)秀

　　數(shù)據(jù)庫支持是Delphi的強(qiáng)項(xià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對(duì)數(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相對(duì)功能太弱了。也許SQL Server是不錯(cuò)的選擇。

COM：新技術(shù)的力量

　　COM是組件對(duì)象模型的縮寫。它是OLE和ActiveX技術(shù)的基礎(chǔ)，COM定義了一組API和一個(gè)二進(jìn)制標(biāo)準(zhǔn)，讓不同的編程語言、不同平臺(tái)的彼此獨(dú)立的對(duì)象相互進(jìn)行通訊。

　　COM是Microsoft制訂的行業(yè)標(biāo)準(zhǔn)。但Delphi也為COM提供了強(qiáng)大的語言支持。支持接口、variant、寬字符串功能。這些對(duì)COM的封裝確實(shí)比C++更方便。比如在C++（沒有類框架）進(jìn)行COM編程時(shí)，變體定義為oaidl.h文件中的VARIANT結(jié)構(gòu)。要處理變體，必須手工調(diào)整oleaut32.dll中VariantXXXX()　API函數(shù)對(duì)其進(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)勢(shì)，Delphi應(yīng)用到COM組件程序更合適。

昨天，今天，明天

　　技術(shù)的進(jìn)步在很多時(shí)候是此消彼長(zhǎng)的。當(dāng)初Borland的Turbo C和Borland C++幾乎是C/C++程序員唯一的選擇。微軟的Quick C(現(xiàn)在還有人知道這個(gè)產(chǎn)品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++壓下去了。于是Inprise(原Borland)揀起了當(dāng)年Turbo Pascal和Borland Pascal的輝煌(事實(shí)上Borland的成名作就是第一個(gè)Pascal編譯器)，全力推出了Delphi。Delphi當(dāng)初推出時(shí)被稱為VB殺手，但VB現(xiàn)在仍然活得挺好。畢竟微軟是靠Basic起家的嘛，VB不是那么容易被打敗的。Inprise想了想不和VB爭(zhēng)了，使用Delphi的IDE和VCL配上C++語言，推出了C++Builder，又向Visual C++的市場(chǎng)發(fā)起了夾攻。C++Builder似乎是個(gè)不錯(cuò)的折衷選擇了？再仔細(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代碼中還有錯(cuò)。VCL的部分功能不能使用，要靠嵌入pascal代碼訪問。C++Builder可用的第三方控件遠(yuǎn)沒有Delphi多。 　　

　　唉，真是金無足赤。Microsoft和Inprise，誰會(huì)笑在最后呢？

魚和熊掌：艱難的選擇

　　選擇一個(gè)開發(fā)工具依賴于很多不同的因素，每個(gè)人都能因?yàn)槟撤N語言的某個(gè)缺陷而放棄學(xué)習(xí)或使用這種語言。任何程序員都希望自己喜歡的工具能達(dá)到理想的境界，通過上面不完善的比較，我想大家都有自己的看法。我們認(rèn)為影響大家選擇開發(fā)語言的因素主要包括：

１） 哪門語言更容易入門？
　　學(xué)習(xí)一種語言需要投入大量的時(shí)間和精力。開發(fā)程序的開發(fā)成本是值得考慮的現(xiàn)實(shí)。一個(gè)熟練的Delphi程序員和一個(gè)熟練的VC程序員工作效率是一樣的。但是，成為熟練的程序員必須很快掌握一門語言的技巧。不幸的是，目前熟練的Visual C++程序員是十里挑一。相對(duì)而言，Delphi更適合初學(xué)者。

２） 哪門語言有更多可繼承的代碼？
　　語言代碼的可重用性是加快開發(fā)效率明顯方面，從早期的過程、函數(shù)到現(xiàn)在的組件技術(shù)都是朝這個(gè)目標(biāo)在奮斗。這兩種語言對(duì)代碼重用的理解是不一樣的，Delphi主要通過VCL控件來實(shí)現(xiàn)代碼重用，Visual C++實(shí)現(xiàn)起來就比較復(fù)雜。

３） 語言自身的本性。 　　
　　就技術(shù)(主要指應(yīng)用框架)來說，Delphi目前領(lǐng)先于Visual C++。但穩(wěn)定性和健壯性的不足又讓我對(duì)Inprise"想說愛你不容易"。而VC盡管發(fā)展到今日已十分完善，但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。根據(jù)你的需要和實(shí)際情況做選擇吧。實(shí)際上Visual C++和Delphi也不是簡(jiǎn)單競(jìng)爭(zhēng)關(guān)系。它們?cè)谠S多領(lǐng)域并不重疊，甚至是互補(bǔ)的。到底怎樣取舍，要根據(jù)你的項(xiàng)目特性決定。如果你開發(fā)系統(tǒng)底層的東西，需要極好的兼容性和穩(wěn)定性，選Visual C++吧。你可以只調(diào)用Windows的各種API，不用MFC。如果你寫傳統(tǒng)的Windows桌面應(yīng)用程序，Visual C++的MFC框架是"正統(tǒng)"的選擇；如果界面部分占這個(gè)應(yīng)用程序代碼比例較大的話，或者Delphi中有相關(guān)功能的控件的話，Delphi是事半功倍的選擇。如果你為企業(yè)開發(fā)數(shù)據(jù)庫、信息管理系統(tǒng)等高層應(yīng)用("高層"是相對(duì)于"低層/底層"而言的，不是說技術(shù)高級(jí)或低級(jí))，而且有比較緊的期限限制，選Delphi比較好。如果你熟悉的語言是Object Pascal，又不打算學(xué)復(fù)雜的C++，那么Delphi幾乎是唯一的選擇。傳統(tǒng)的觀點(diǎn)是：Delphi適合編寫Internet/Intranet、表格制圖、數(shù)據(jù)庫操作、高級(jí)用戶界面等等。Visual C++適合編寫設(shè)備驅(qū)動(dòng)、COM服務(wù)程序、科學(xué)計(jì)算、控制臺(tái)（console）程序、WinCE的應(yīng)用和一些小的工具等等。應(yīng)用范圍的不同要求好的程序員同時(shí)精通這兩門語言。

４） 語言的前景和可擴(kuò)充性。
　　Delphi是Inprise的旗艦產(chǎn)品之一，前景應(yīng)當(dāng)還是比較樂觀的，而且Inprise已經(jīng)在向Linux進(jìn)軍了，而微軟還遲遲沒有動(dòng)作。遺憾的是，Inprise公司Delphi的創(chuàng)始人已經(jīng)跳槽到微軟去主持Visual J++和C#項(xiàng)目了。但愿對(duì)Inprise沖擊不會(huì)太大。

　　微軟的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)用的主流模式，而且還會(huì)保持相當(dāng)長(zhǎng)的時(shí)間。微軟公司CEO史蒂夫·巴爾默(Steve Ballmer)曾說，.NET流行還得等2－3年。那么，MFC至少還有2－3年的生命空間。在技術(shù)日新月異的IT界，2－3年實(shí)在是很長(zhǎng)一段時(shí)間了。好好把握吧。即使你不使用MFC框架，花點(diǎn)時(shí)間看一下MFC的封裝機(jī)制對(duì)你熟悉C++的OOP機(jī)制和Windows底層功能也是很有好處的。而VCL的源代碼是Object Pascal的，對(duì)C/C++程序員就沒有這個(gè)"額外"的作用了。