【正文】 enser使用戶可以在MTS中使用BDE存取數(shù)據(jù)庫，保證了MTS對數(shù)據(jù)庫的兩階段提交(Two PhaseCommit)及資源管理的能力。(6)強大的調試功能C++ Builder強化了原有的Module View、EventLog View及Inspect Local Variable等調試窗口的功能，并在Windows NT環(huán)境中提供多線程調試的新功能，使用戶可以在某一特定過程中跟蹤程序代碼。C++ Builder針對多層分布式開發(fā)環(huán)境提供了遠程調試能力，開發(fā)人員可以通過網(wǎng)絡直接對遠端的應用程序服務器進行調試，從而簡化了多層應用系統(tǒng)的開發(fā)和維護工作。(7)其他特點C++ Builder還有很多新增的功能，如：針對Windows 98提供了PageScroller、MonthCalendar等Windows 98格式的新組件，并支持Windows98的多重屏幕顯示功能及Microsoft Office97格式的選擇選單和停駐式(docking)工具條。對界面的處理上，可以控制窗口的最大/最小尺寸以及窗口尺寸變動時其中組件的相對位置和比例，等等?？傊?，C++ Builder 的強大功能并不是通過筆者有限的介紹所能夠涵蓋的，在C++海洋里遨游的朋友不妨親自嘗試一下C++ Builder，體驗一下它的靈活與強大，相信您定會“戀戀不舍”的。 C++ BUILDER與Visual C++對比首先，從它們的應用程序框架(Application Frame，有時也稱為對象框架)進行比較。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫。(同樣，Del phi和C++Builder使用的VCL的概念也不僅僅是一個控件庫。)你如果選擇了MFC，也就選擇了一種程序結構，一種編程風格。MFC早在Windows ，那時的Visual C++還是16位的。經(jīng)過這些年的不斷補充和完善，MFC已經(jīng)十分成熟。但由于原型出現(xiàn)得比較早，MFC相比于VCL落后了一個時代。盡管微軟對MFC的更新沒有停止，我也經(jīng)常讀到持只要Windows不過時，MFC就不會過時之類觀點的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。如果MFC青春永駐，微軟的開發(fā)人員也不會私自開發(fā)出基于ATL的WTL呀。當然，WTL的地位不能和MFC比，它并不是微軟官方支持的框架，封裝的功能也相當有限。但至少也反襯出了MFC存在的不足。 我以為，最能體現(xiàn)一個應用程序框架的先進性的是它的委托模型，即對Windows消息的封裝機制。(對Windows API的封裝就不用說了吧。大同小異，也沒什么技術含量。 如果高興，你也可以自己寫一個類庫來封裝。但對Windows消息驅動機制的封裝就不是那么容易的了。)最自然的封裝方式是采用虛成員函數(shù)。如果要響應某個消息就重載相應的虛函數(shù)。但出乎我的意料，MFC采用的是古老的宏定義方法。用宏定義方法的好處是省去了虛函數(shù)VTable的系統(tǒng)開銷。(由于Windows的消息種類很多，開銷不算太小。)不過帶來的缺點就是映射不太直觀。好在較新版本VC帶的ClassWizard可以自動生成消息映射代碼，使用起來還是比較方便的。但和VCL的委托模型相比，MFC的映射方法就顯得太落后了。而C++Builder對C++語言進行了擴展，以便引入組件、事件處理、屬性等新特性。由于功夫做在編譯器級，生成的源代碼就顯得十分簡潔。但是由于擴展的非標準特性，使用VCL的C++Builder的源代碼無法被其它編譯器編譯。而MFC的功夫做在源代碼級，雖然消息映射代碼較為復雜且不直觀，但兼容性非常好。只要你有MFC庫的源代碼(隨VC企業(yè)版的光盤提供)，你的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也不是一無是處。經(jīng)歷了那么多年的發(fā)展和完善，MFC功能非常全面，而且十分穩(wěn)定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工具幫助你避開這些bug。如此規(guī)模的一個類庫，能做到這一點不容易。不要小看了這一點，很多專業(yè)程序員就是為這個選擇VC的。而C++Builder的VCL的bug就相對較多了，而且有些它自己帶的示例程序都有錯誤。看來Inprise還有很長的路要走。 再從它們的易用性比較。VC有ClassWizard、SourceBrowser等一系列工具，還附帶Visual SourceSafe、Visual Modeler等強大的工具，易用性非常好。(VC自帶建模工具Visual Modeler，也許說明了它才是工程級的開發(fā)平臺，與C++Builder的定位不同。)它所帶的MSDN這部開發(fā)者的百科全書更是讓你沒有找不到的，只有想不到的。而且它的AutoComplete之類小功能也比C++Builder要體貼。C++Builder的新版本雖然也提供了這一功能，但它的提示要等好幾秒才出來，有時你不經(jīng)意間把鼠標停在某一處，也要等硬盤響好幾秒，這可是在566Mhz的賽揚II上呀。不要笑我瑣碎，有時一個開發(fā)工具的成熟和易用，就是從這些小地方體現(xiàn)出來的。C++Builder作為RAD工具，理應強調易用性。但與VC相比還顯出不成熟。這是不應該的。 再來看看它們的可移植性。Inprise正在開發(fā)C++Builder和Delphi的Linux版本， 代號為Kylix。也許通過Kylix，用VCL構架編寫的Windows程序向Linux移植成為可能。但這只是可能。因為在目前Inprise的兼容性工作做得并不好。C++Builder可以編譯VC程序還要多謝微軟使用標準方法寫MFC，而它自己各個版本之間兼容性卻不太好。低版本的C++Builder不能使用高版本的VCL組件(這還別去說它)，而高版本的C++Builder竟然不能使用低版本的VCL組件。真是豈有此理，我很少看見軟件有不向下兼容的。如果Windows 98不能運行95的程序，Windows ，Win ，你 還會用Windows嗎？如果不是C++Builder的其它某些方面太出色，光是這個向下不兼容就足以讓我拋棄它。而且雖說通過捆綁編譯器，C++Builder可以編譯Delphi的Object Pascal代碼，但C++Builder仍不能使用為Delphi開發(fā)的VCL組件。所以一個組件有for D1/D 2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著C++Builder版本的升級可 能還會增加。希望Inprise能先解決同門兄弟的兼容性問題。而微軟的VC就沒有這類問題 。 再來看看它們的前景吧。實際上，技術的進步在很多時候是此消彼長的。當初Borland的Turbo C和Borland C++幾乎是唯一的選擇。微軟的Quick C(現(xiàn)在還有人知道這個產(chǎn)品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++壓下去了?，F(xiàn)在的C++Builder又有后來居上的態(tài)勢，如果穩(wěn)定性再提高一些，bug再少一些，有希望成為主流。但Inspires的總體實力不及微軟，這也是無可爭議的。從C++Builder 5的Release Notes中的Known Issues部分，以及它們的幫助文檔的規(guī)模和質量都可以看出。(哪個同類產(chǎn)品的幫助文檔能和MSDN比呢？)Inprise公司應從Netscape吸取教訓，不要讓C++Builder成為第二個Netscape Communicator。(Communicator也是一度技術領先，甚至曾占據(jù)了大部分的瀏覽器市場，但似乎后勁不足，而且 PR2中bug多多，現(xiàn)在被IE壓得抬不起頭。)C++Builder是Inspires的旗艦產(chǎn)品之一，前景應當還是比較樂觀的，而且Inspires已經(jīng)在向Linux進軍了，而微軟還遲遲沒有動作，難道非要到Linux成燎原之勢(或許已經(jīng)成燎原之勢了)才會奮起占領這個新興市場？似乎他們對Linux的態(tài)度與幾年前對互聯(lián)網(wǎng)的興起的反應遲緩有些相似。但后來......唉，真希望Inprise不要步Netscape的后塵。C++Builder是一個很有前途的開發(fā)工具。遺憾的是，Inprise公司Delphi的創(chuàng)始人已經(jīng)跳槽到微軟去主持Visual J++項目了。但愿對Inprise沖擊不會太大。微軟的Visual C++的前景又怎樣呢？Visual Studio 。不知能不能在保持穩(wěn)定性的同時在技術的先進性上趕上C++Builder。另外，這一版本將加強網(wǎng)絡開發(fā)的特性?？磥砦④涬m然被判解體，開發(fā)實力可是一點沒打折扣。 就技術(主要指應用框架)來說，C++Builder目前領先于Visual C++。但多多少少的不盡人意之處對Inprise想說愛你不容易。而VC盡管發(fā)展到今日已十分完善，但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。WFC是支持組件、屬性和事件的，但那是Visual J++里邊用的；ATL也很先進，但是用來進行COM/ActiveX開發(fā)的；基于ATL的WTL也不錯，可惜是非官方作品，也未必比VCL先進。微軟最近提出了C(讀作C Sharp)語言方案，但那屬于和Java同一類的東西?？磥硎墙馃o足赤啊。根據(jù) 你的需要做選擇吧。實際上Visual C++和C++Builder也不是單單競爭關系。它們在許多領域并不重疊，甚至是互補的。到底怎樣取舍，要根據(jù)你的項目特性決定。如果你開發(fā)系統(tǒng)底層的東西，需要極好的兼容性和穩(wěn)定性，選Visual C++吧。你可以只調用Windows的各種API，不用MFC。如果你寫傳統(tǒng)的Windows桌面應用程序，Visual C++的MFC框架是正統(tǒng)的選擇。如果你為企業(yè)開發(fā)數(shù)據(jù)庫、信息管理系統(tǒng)等高層應用(高層是相對于低層/底層而言的，不是說技術高級或低級。)而且有比較緊的期限限制，選C++Builder比較好。如果你用的語言是Object Pascal，Delphi是唯一的選擇(如果GNU Pascal等免費編譯器不考慮的話)。如果你原先用Delphi(Object Pascal語言)，現(xiàn)在想改學 C++，應當先C++Builder。熟悉的界面和相同的框架會讓你的轉軌事半功倍。 BCB的調試程序的bugs越少，最終用戶對這個程序的評價越高。而開發(fā)人員事先對bugs的處理越多，最終用戶能提供的關于bugs的信息就越多，也越準確，這樣，開發(fā)人員在接到最終用戶反映之后，就能夠快速找到出現(xiàn)bugs的那部分代碼，并以最快速度發(fā)布程序的升級包。 (1)寫易讀的代碼 第一點，大概也是最重要的一點，就是寫干凈易讀的代碼。易讀的代碼是很有價值的。請想象一下，如果隨便掃視一眼代碼或注釋，就能立刻知道這段代碼的的作用，以及在寫代碼的時候為什么要這樣寫，當時的思路是什么，那么就可以節(jié)約大量時間。這樣的代碼，在寫的時候可能會稍稍慢一些，不過，當你調試程序時，就不會花上幾個小時來尋找bugs，相反，你可以快速，簡單的完成除錯工作。這時，你就會覺得多花一些時間使程序易讀是很值得的。所以，在寫程序的時候，應該養(yǎng)成自己的風格，或是讀一讀Scott的關于代碼風格的文章。 (2)使用Exceptions和Exception的處理方法 除去一些少數(shù)的情況，開發(fā)人員不可能總是依靠于集成的調試工具。所以，學會用其它的方法來找到煩人的bugs是很重要的。一些重要的、處理的錯誤可能會在窗體之外發(fā)生。在C++標準制定出來之前的黑暗日子里，在程序里面發(fā)出發(fā)生錯誤的信號，通常是通過返回錯誤代碼完成的（現(xiàn)在這種方法仍然應用于OLE技術和一些Winapi函數(shù)），這樣的處理方法很容易就會被忽略。（比如說，你經(jīng)常檢查winapi函數(shù)的返回值嗎？）所以，出現(xiàn)問題的可能性并不小。由于以上的原因，需要一個這樣的機制，它不能忽略這些錯誤，而且，這個機制應該能被我們控制和自定義的。在這樣的需求下，異常處理機制出現(xiàn)了。需要一個特殊的錯誤類型嗎？簡單，定義一個新的異常類型就行了（和定義一個類的方法差不多），然后拋出（throw）它。 C++Builder定義了try {} catch (…) {}機制。這和剛剛定義的異常機制的結構很相似。這個機制完全可以按照需要自定義。要使用異常處理了，只要把要執(zhí)行的代碼放到try塊里面，為了讓程序知道出現(xiàn)異常后應該做什么，還需要定義一個catch()或是__finally塊。Catch()語句里面可以指定一個要捕捉的類型或是變量，甚至可以用它來捕捉樹結構或是繼承類的異常，如果捕捉了基類的異常，它就能捕捉到繼承這個基類的所有的類的異常。比如，在VCL中，所有的異常都是繼承于Exception類。所以，catch(Exceptionamp。 E)可以捕捉到除了EsocketError的所有VCL異常。為了讓這個機制更強大，C++Builder中還定義了catch(…)語句。（沒錯，就是三個點）使用這條語句可以捕捉到所有的異常。還有更多的功能嗎？當然，你可以添加更多的catch()語句，可以向使用if…else if…語句那樣使用它。注意，在一系列的catch()語句中，錯誤不會被重復的捕捉，也就是說，如果前面的ca