本文就試圖從技術水平、易用性、穩定性、發展前景等對Visual   C++和C++Builder(Delphi)這兩個重量級開發工具進行比較分析。              由於Delphi與C++Builder同為Inprise公司產品，共享整合開發介面(IDE)，而且使用同一套VCL框架(這一點最關鍵)，它們帶的偵錯程式、PVCS/TeamSource團隊開發支援、資料庫引擎及企業版中整合的其它高階功能等都是相同的，所以本文將其與C++Builder歸入“同一陣線”。               首先，從它們的應用程式框架(Application   Frame，有時也稱為物件框架)進行比較。Visual   C++採用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫。(同樣，Delphi和C++Builder使用的VCL的概念也不僅僅是一個控制元件庫。)你如果選擇了MFC，也就選擇了一種程式結構，一種程式設計風格。MFC早在Windows   3.x的時代就出現了，那時的Visual   C++還是16位的。經過這些年的不斷補充和完善，MFC已經十分成熟。但由於原型出現得比較早，MFC相比於VCL落後了一個時代。儘管微軟對MFC的更新沒有停止，我也經常讀到持“只要Windows不過時，MFC就不會過時”之類觀點的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。如果MFC青春永駐，微軟的開發人員也不會“私自”開發出基於ATL的WTL呀。當然，WTL的地位不能和MFC比，它並不是微軟官方支援的框架，封裝的功能也相當有限。但至少也反襯出了MFC存在的不足。               我以為，最能體現一個應用程式框架的先進性的是它的委託模型，即對Windows訊息的封裝機制。(對Windows   API的封裝就不用說了吧。大同小異，也沒什麼技術含量。如果高興，你也可以自己寫一個類庫來封裝。但對Windows訊息驅動機制的封裝就不是那麼容易的了。)最自然的封裝方式是採用虛成員函式。如果要響應某個訊息就過載相應的虛擬函式。但出乎我的意料，MFC採用的是“古老”的巨集定義方法。用巨集定義方法的好處是省去了虛擬函式VTable的系統開銷。(由於Windows的訊息種類很多，開銷不算太小。)不過帶來的缺點就是對映不太直觀。好在較新版本VC帶的ClassWizard可以自動生成訊息對映程式碼，使用起來還是比較方便的。但和VCL的委託模型相比，MFC的對映方法就顯得太落後了。而C++Builder對C++語言進行了擴充套件，以便引入元件、事件處理、屬性等新特性。由於功夫做在編譯器級，生成的原始碼就顯得十分簡潔。但是由於擴充套件的非標準特性，使用VCL的C++Builder的原始碼無法被其它編譯器編譯。而MFC的功夫做在原始碼級，雖然訊息對映程式碼較為複雜且不直觀，但相容性非常好。只要你有MFC庫的原始碼(隨VC企業版的光碟提供)，你的MFC程式理論上用任何符合ANSI標準的編譯器均可編譯通過。C++Builder   3以上版本可以原封不動直接編譯Visual   C++程式，很多人認為這是C++Builder的相容性好，實際上很大程度應歸功於MFC的相容性好。微軟辛辛苦苦用標準方法寫MFC，卻為對手製造了方便。不知他們作何感想？而因為C++Builder對語言作了擴充套件，VC不能編譯C++Builder的程式。看來在這方面VC要輸給C++Builder了。而且VCL所支援的元件、屬性等都是MFC所缺乏的特性。雖然VC也能支援元件，但要通過AppWizard先生成一個“包裹”類(wrapper)，不如VCL來得簡潔。有很多人使用C++Builder就是衝著控制元件板上那一大堆元件來的，VC雖然能使用的元件也很多(也許不比C++Builder少)，但由於不方便而對RAD程式設計師沒有吸引力。               C++Builder的VCL比Visual   C++的MFC先進的另一個特性是異常處理。但令人啼笑皆非的是，它的異常處理程式碼有bug，有時會無端丟擲異常。不知道在最新的版本中有沒有改正了。而VC的框架MFC也不是一無是處。經歷了那麼多年的發展和完善，MFC功能非常全面，而且十分穩定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工具幫助你避開這些bug。如此規模的一個類庫，能做到這一點不容易。不要小看了這一點，很多專業程式設計師就是為這個選擇VC的。而C++Builder的VCL的bug就相對較多了，而且有些它自己帶的示例程式都有錯誤。看來Inprise還有很長的路要走。               再從它們的易用性比較。VC有ClassWizard、SourceBrowser等一系列工具，還附帶Visual   SourceSafe、Visual   Modeler等強大的工具，易用性非常好。(VC自帶建模工具Visual   Modeler，也許說明了它才是工程級的開發平臺，與C++Builder的定位不同。)它所帶的MSDN這部“開發者的百科全書”更是讓你“沒有找不到的，只有想不到的”。而且它的AutoComplete之類小功能也比C++Builder要體貼。C++Builder的新版本雖然也提供了這一功能，但它的提示要等好幾秒才出來，有時你不經意間把滑鼠停在某一處，也要等硬碟響好幾秒，這可是在566Mhz的賽揚II上呀。不要笑我瑣碎，有時一個開發工具的成熟和易用，就是從這些小地方體現出來的。C++Builder作為RAD工具，理應強調易用性。但與VC相比還顯出不成熟。這是不應該的。               再來看看它們的可移植性。Inprise正在開發C++Builder和Delphi的Linux版本，代號為Kylix。也許通過Kylix，用VCL構架編寫的Windows程式向Linux移植成為可能。但這只是可能。因為在目前Inprise的相容性工作做得並不好。C++Builder可以編譯VC程式還要多謝微軟使用標準方法寫MFC，而它自己各個版本之間相容性卻不太好。低版本的C++Builder不能使用高版本的VCL元件(這還別去說它)，而高版本的C++Builder竟然不能使用低版本的VCL元件。真是豈有此理，我很少看見軟體有不向下相容的。如果不是C++Builder的其它某些方面太出色，光是這個向下不相容就足以讓我拋棄它。而且雖說通過捆綁編譯器，C++Builder可以編譯Delphi的Object   Pascal程式碼，但C++Builder仍不能使用為Delphi開發的VCL元件。所以一個元件有多個版本是常有的事，而且隨著C++Builder版本的升級可能還會增加。希望Inprise能先解決同門兄弟的相容性問題。而微軟的VC就沒有這類問題。MFC1.0的程式也可以毫無障礙地在VC6.0下編譯通過。              再來看看它們的前景吧。實際上，技術的進步在很多時候是此消彼長的。當初Borland的Turbo   C和Borland   C++幾乎是唯一的選擇。微軟的Quick   C和Microsoft   C/C++從來也沒有成為過主流。但Borland   C++又流行了多少年呢？不久就被新崛起的Microsoft   Visual   C/C++壓下去了。現在的C++Builder又有後來居上的態勢，如果穩定性再提高一些，bug再少一些，有希望成為主流。但Inprise的總體實力不及微軟，這也是無可爭議的。從C++Builder   5的Release   Notes中的Known   Issues部分，以及它們的幫助文件的規模和質量都可以看出。(哪個同類產品的幫助文件能和MSDN比呢？)Inprise公司應從Netscape吸取教訓，不要讓C++Builder成為第二個Netscape   Communicator。(Communicator也是一度技術領先，甚至曾佔據了大部分的瀏覽器市場，但似乎後勁不足，現在被IE壓得擡不起頭。)C++Builder是Inprise的旗艦產品之一，前景應當還是比較樂觀的，而且Inprise已經在向Linux進軍了，而微軟還遲遲沒有動作，難道非要到Linux成燎原之勢(或許已經成燎原之勢了)才會奮起佔領這個新興市場？似乎他們對Linux的態度與幾年前對網際網路的興起的反應遲緩有些相似。但後來......唉，真希望Inprise不要步Netscape的後塵。C++Builder是一個很有前途的開發工具。遺憾的是，Inprise公司Delphi的創始人已經跳槽到微軟去主持Visual   J++專案了。但願對Inprise衝擊不會太大。微軟的Visual   C++的前景又怎樣呢？Visual   Studio   7.0不久就要推出了。不知能不能在保持穩定性的同時在技術的先進性上趕上C++Builder。另外，這一版本將加強網路開發的特性。看來微軟雖然被判解體，開發實力可是一點沒打折扣。                就技術(主要指應用框架)來說，C++Builder目前領先於Visual   C++。但多多少少的不盡人意之處讓我對Inprise“想說愛你不容易”。而VC儘管發展到今日已十分完善，但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。WFC是支援元件、屬性和事件的，但那是Visual   J++裡邊用的；ATL也很先進，但是用來進行COM/ActiveX開發的；基於ATL的WTL也不錯，可惜是非官方作品，也未必比VCL先進。微軟最近提出了C#(讀作C   Sharp)語言方案，但那屬於和Java同一類的東西。看來是金無足赤啊。根據你的需要做選擇吧。實際上Visual   C++和C++Builder也不是單單競爭關係。它們在許多領域並不重疊，甚至是互補的。到底怎樣取捨，要根據你的專案特性決定。如果你開發系統底層的東西，需要極好的相容性和穩定性，選Visual   C++吧。你可以只調用Windows的各種API，不用MFC。如果你寫傳統的Windows桌面應用程式，Visual   C++的MFC框架是“正統”的選擇。如果你為企業開發資料庫、資訊管理系統等高層應用(“高層”是相對於“低層/底層”而言的，不是說技術高階或低階。)而且有比較緊的期限限制，選C++Builder比較好。如果你用的語言是Object   Pascal，Delphi是唯一的選擇(如果GNU   Pascal等免費編譯器不考慮的話)。如果你原先用Delphi(Object   Pascal語言)，現在想改學C++，應當先用C++Builder。熟悉的介面和相同的框架會讓你的轉軌事半功倍。              另外，雖說MFC已顯落後，但不是說它不值得學。事實上，不學MFC就等於沒學VC。利用MFC框架開發程式仍然是目前開發桌面應用的主流模式，而且還會保持相當長的時間。即使你不使用MFC框架，花點時間學習一下MFC的封裝機制對你熟悉C++的OOP機制和Windows底層功能也是很有好處的。