【文章內(nèi)容簡(jiǎn)介】 太出色，光是這個(gè)向下不兼容就足以讓我拋棄它。而且雖說(shuō)通過(guò)捆綁編譯器， C++Builder 可以編譯 Delphi 的 Object Pascal 代碼，但 C++Builder 仍不能使用為 Delphi 開(kāi)發(fā)的 VCL組件。所以一個(gè)組件有 for D1/D 2/D3/D4/D5/C1/C3/C4/C5 這些不同版本是常有的事，而且隨著 C++Builder 版本 的升級(jí)可 能還會(huì)增加。希望 Inprise 能先解決同門兄弟的兼容性問(wèn)題。而微軟的 VC 就沒(méi)有這類問(wèn)題 的程序也可以毫無(wú)障礙地在 下編譯通過(guò)。 再來(lái)看看它們的前景吧。實(shí)際上，技術(shù)的進(jìn)步在很多時(shí)候是此消彼長(zhǎng)的。當(dāng)初 Borland的 Turbo C 和 Borland C++幾乎是唯一的選擇。微軟的 Quick C(現(xiàn)在還有人知道這個(gè)產(chǎn)品嗎？ )和 Microsoft C/C++從來(lái)也沒(méi)有成為過(guò)主流。但 Borland C++又流行了多少年呢？不久就被新崛起的 Microsoft Visual C/C++壓下去 了?，F(xiàn)在的 C++Builder 又有后來(lái)居上的態(tài)勢(shì)，如果穩(wěn)定性再提高一些， bug 再少一些，有希望成為主流。但 Inspires 的總體實(shí)力不及微軟， 這也是無(wú)可爭(zhēng)議的。從 C++Builder 5 的 Release Notes 中的 Known Issues 部分，以及它們的幫助文檔的規(guī)模和質(zhì)量都可以看出。 (哪個(gè)同類產(chǎn)品的幫助文檔能和 MSDN 比呢？ )Inprise公司應(yīng)從 Netscape 吸取教訓(xùn)，不要讓 C++Builder 成為第二個(gè) Netscape Communicator。(Communicator 也是一度技術(shù)領(lǐng)先，甚至曾 占據(jù)了大部分的瀏覽器市場(chǎng)，但似乎后勁不足，而且 PR 2 中 bug 多多，現(xiàn)在被 IE 壓得抬不起頭。 )C++Builder 是 Inspires 的旗艦產(chǎn)品之一，前景應(yīng)當(dāng)還是比較樂(lè)觀的，而且 Inspires 已經(jīng)在向 Linux 進(jìn)軍了，而微軟還遲遲沒(méi)有動(dòng)作，難道非要到 Linux 成燎原之勢(shì) (或許已經(jīng)成燎原之勢(shì)了 )才會(huì)奮起占領(lǐng)這個(gè)新興市場(chǎng)？似乎他們對(duì) Linux 的態(tài)度與幾年前對(duì)互聯(lián)網(wǎng)的興起的反應(yīng)遲緩有些相似。但后來(lái) ......唉，真希望 Inprise 不要步 Netscape 的后塵。 C++Builder 是一個(gè)很有前途的開(kāi)發(fā) 工具。遺憾的是， Inprise 公司 Delphi 的創(chuàng)始人已經(jīng)跳槽到微軟去主持 Visual J++項(xiàng)目了。但愿對(duì)Inprise 沖擊不會(huì)太大。微軟的 Visual C++的前景又怎樣呢？ Visual Studio 不久就要推出了。不知能不能在保持穩(wěn)定性的同時(shí)在技術(shù)的先進(jìn)性上趕上 C++Builder。另外，這一版本將加強(qiáng)網(wǎng)絡(luò)開(kāi)發(fā)的特性?？磥?lái)微軟雖然被判解體， 開(kāi)發(fā)實(shí)力可是一點(diǎn)沒(méi)打折扣。 就技術(shù) (主要指應(yīng)用框架 )來(lái)說(shuō)， C++Builder 目前領(lǐng)先于 Visual C++。但多多少少的不盡人意之處 對(duì) Inprise想 說(shuō)愛(ài)你不容易 。而 VC 盡管發(fā)展到今日已十分完善，但 MFC 框架已是明日黃花了。如果不使用 MFC，目前又沒(méi)有合適的替代品。 WFC 是支持組件、屬性和事件的，但那是 Visual J++里邊用的； ATL 也很先進(jìn)，但是用來(lái)進(jìn)行 COM/ActiveX 開(kāi)發(fā)的；基于 ATL 的 WTL 也不錯(cuò)，可惜是非官方作品，也未必比 VCL 先進(jìn)。微軟最近提出了 C(讀作 C Sharp)語(yǔ)言方案，但那屬于和 Java 同一類的東西?？磥?lái)是金無(wú)足赤啊。根據(jù) 你的需要做選擇吧。實(shí)際上 Visual C++和 C++Builder 也不是單單競(jìng)爭(zhēng)關(guān)系。它們?cè)谠S多領(lǐng) 域并不重疊，甚至是互補(bǔ)的。到底怎樣取舍，要根據(jù)你的項(xiàng)目特性決定。如果你開(kāi)發(fā)系統(tǒng)底層的東西，需要極好的兼容性和穩(wěn)定性，選 Visual C++吧。你可以只調(diào)用 Windows 的各種API，不用 MFC。如果你寫(xiě)傳統(tǒng)的 Windows 桌面應(yīng)用程序， Visual C++的 MFC 框架是 正統(tǒng) 的選擇。如果你為企業(yè)開(kāi)發(fā)數(shù)據(jù)庫(kù)、信息管理系統(tǒng)等高層應(yīng)用 (高層 是相對(duì)于 低層 /底層 而言的，不是說(shuō)技術(shù)高級(jí)或低級(jí)。 )而且有比較緊的期限限制，選 C++Builder 比較好。如果你用的語(yǔ)言是 Object Pascal， Delphi 是唯一 的選擇 (如果 GNU Pascal 等免費(fèi)編譯器不考慮的話 )。如果你原先用 Delphi(Object Pascal 語(yǔ)言 )，現(xiàn)在想改學(xué) C++，應(yīng)當(dāng)先 C++Builder。熟悉的界面和相同的框架會(huì)讓你的轉(zhuǎn)軌事半功倍。 BCB 的調(diào)試 程序的 bugs 越少，最終用戶對(duì)這個(gè)程序的評(píng)價(jià)越高。而開(kāi)發(fā)人員事先對(duì) bugs 的處理越多，最終用戶能提供的關(guān)于 bugs 的信息就越多，也越準(zhǔn)確，這樣，開(kāi)發(fā)人員在接到最終用戶反映之后，就能夠快速找到出現(xiàn) bugs 的那部分代碼，并以最快速度發(fā)布程序的升級(jí)包。 (1)寫(xiě)易讀的代碼 第一點(diǎn)，大概 也是最重要的一點(diǎn)，就是寫(xiě)干凈易讀的代碼。易讀的代碼是很有價(jià)值的。請(qǐng)想象一下，如果隨便掃視一眼代碼或注釋，就能立刻知道這段代碼的的作用，以及在寫(xiě) 代碼的時(shí)候?yàn)槭裁匆@樣寫(xiě)，當(dāng)時(shí)的思路是什么，那么就可以節(jié)約大量時(shí)間。這樣的代碼，在寫(xiě)的時(shí)候可能會(huì)稍稍慢一些，不過(guò)，當(dāng)你調(diào)試程序時(shí)，就不會(huì)花上幾個(gè)小時(shí)來(lái)尋找 bugs，相反，你可以快速，簡(jiǎn)單的完成除錯(cuò)工作。這時(shí)，你就會(huì)覺(jué)得多花一些時(shí)間使程序易讀是很值得的。 所以，在寫(xiě)程序的時(shí)候，應(yīng)該養(yǎng)成自己的風(fēng)格，或是讀一讀 Scott 的關(guān)于代碼風(fēng)格的文章。 (2)使用 Exceptions 和 Exception 的處理方法 除去一些少數(shù)的情況，開(kāi)發(fā)人員不可能總是依靠于集成的調(diào)試工具。所以，學(xué)會(huì)用其它的方法來(lái)找到煩人的 bugs 是很重要的。一些重要的、處理的錯(cuò)誤可能會(huì)在窗體之外發(fā)生。在 C++標(biāo)準(zhǔn)制定出來(lái)之前的黑暗日子里，在程序里面發(fā)出發(fā)生錯(cuò)誤的信號(hào)，通常是通過(guò)返回錯(cuò)誤代碼完成的（現(xiàn)在這種方法仍然應(yīng)用于 OLE 技術(shù)和一些 Winapi 函數(shù)），這樣的處理方法很容易就會(huì)被忽略。（比如說(shuō)，你經(jīng)常檢查 winapi 函數(shù)的返回值嗎？）所以，出現(xiàn)問(wèn)題的可能性并不小。由于以上的原因，需要一個(gè)這樣的機(jī)制，它不能忽略這些 錯(cuò)誤，而且，這個(gè)機(jī)制應(yīng)該能被我們控制和自定義的。在這樣的需求下，異常處理機(jī)制出現(xiàn)了。需要一個(gè)特殊的錯(cuò)誤類型嗎？簡(jiǎn)單，定義一個(gè)新的異常類型就行了（和定義一個(gè)類的方法差不多），然后拋出（ throw）它。 C++Builder 定義了 try {} catch (? ) {}機(jī)制。這和剛剛定義的異常機(jī)制的結(jié)構(gòu)很相似。這個(gè)機(jī)制完全可以按照需要自定義。要使用異常處理了，只要把要執(zhí)行的代碼放到 try 塊里面，為了讓程序知道出現(xiàn)異常后應(yīng)該做什么，還需要定義一個(gè) catch()或是 __finally 塊。Catch()語(yǔ)句里面可以指 定一個(gè)要捕捉的類型或是變量，甚至可以用它來(lái)捕捉樹(shù)結(jié)構(gòu)或是繼承類的異常，如果捕捉了基類的異常，它就能捕捉到繼承這個(gè)基類的所有的類的異常。比如，在 VCL 中，所有的異常都是繼承于 Exception 類。所以， catch(Exceptionamp。 E)可以捕捉到除了 EsocketError 的所有 VCL 異常。為了讓這個(gè)機(jī)制更強(qiáng)大， C++Builder 中還定義了catch(? )語(yǔ)句。（沒(méi)錯(cuò)，就是三個(gè)點(diǎn)）使用這條語(yǔ)句可以捕捉到所有的異常。還有更多的功能嗎？當(dāng)然，你可以添加更多的 catch()語(yǔ)句，可以向使用 if? else if?語(yǔ)句那樣使用它。注意，在一系列的 catch()語(yǔ)句中，錯(cuò)誤不會(huì)被重復(fù)的捕捉，也就是說(shuō)，如果前面的 catch()語(yǔ)句捕捉到了錯(cuò)誤，后面的 catch()語(yǔ)句將不會(huì)捕捉這條錯(cuò)誤。 這個(gè)機(jī)制還有更多的功能。如果你想處理異常，但是不想在處理的位置停止，那么可以重新拋出異常。這時(shí)，程序?qū)⒗^續(xù)尋找下一個(gè) catch()語(yǔ)句來(lái)處理這個(gè)異常。這個(gè)方法和“ throw”差不多。這樣，你處理過(guò)的異常會(huì)再次被拋出，繼續(xù)尋找下一個(gè) catch 語(yǔ)句來(lái)處理它。 最后一個(gè)要說(shuō)的是 __finally（這不是標(biāo)準(zhǔn)的用法，是 Borland 添加 的一個(gè)好方法），在__finally{}程序塊中代碼，無(wú)論是否發(fā)生異常都會(huì)被執(zhí)行。這是一個(gè)清理程序中使用 new分配的本地變量，設(shè)置用作旗標(biāo)的變量值為正常的好位置。（比如，把一個(gè)等待狀態(tài)的光標(biāo)圖標(biāo)設(shè)置為正常光標(biāo)。） 就是這些了。有時(shí)間的話，請(qǐng)看看 C++Builder 幫助文件中的 Exception 類以及繼承 Exception 的類。這些將對(duì)于理解本節(jié)所說(shuō)的內(nèi)容有很大幫助。 (3)使用記錄機(jī)制 不可能總是用調(diào)試器來(lái) 調(diào)試代碼，在某些情況下，可能無(wú)法使用內(nèi)部集成的調(diào)試器，這時(shí)候， 就不得不依靠其他手段調(diào)試程序了。（ 比如： Windows NT 服務(wù)程序 ,ISAPI/CGI 程序，實(shí)時(shí)應(yīng)用程序等等）。這時(shí)候，有經(jīng)驗(yàn)的程序員可能會(huì)借助古老的調(diào)試方法，例如，使用一些分類的記錄機(jī)制來(lái)確定程序?qū)嶋H運(yùn)行的過(guò)程。現(xiàn)在有一系列的方法可以簡(jiǎn)單的完成這樣的工作。下面將介紹 3 種方法。 第一 個(gè)方法： OutputDebugString。（ WinAPI: VOID OutputDebugString(LPCTSTR lpOutputString)。）很幸運(yùn)，微軟徹底的實(shí)現(xiàn)了調(diào)試子系統(tǒng)。它包括的一些特點(diǎn)可能讓你想把自己的記錄系統(tǒng)扔掉。應(yīng)用程序在調(diào)試器 進(jìn)程中運(yùn)行時(shí) OutputDebugString 將用 C 字符串把調(diào)試器輸出的信息打印出來(lái)。如果程序沒(méi)有在調(diào)試器進(jìn)程中運(yùn)行，它將忽略這些調(diào)用。它會(huì)很好的在客戶的機(jī)器上運(yùn)行，不會(huì)彈出信息窗口。如果在發(fā)布給客戶的時(shí)候，忘記去掉這些代碼程序僅僅會(huì)變慢一點(diǎn)，不會(huì)有別的不良后果。 第二個(gè)方法：使用了 Gexperts，通過(guò) 接口進(jìn)行調(diào)試。它是個(gè)可以稱之為偉大的程序，你可以把它分發(fā)給客戶。和 OutputDebugString 一樣，如果客戶沒(méi)有這個(gè)程序，它就根本什么也不作。（它會(huì)自動(dòng)檢測(cè)機(jī)器上是否安裝了客 戶端）。要使用 dbugintf，它很容易被加入到你的工程中，加入 include （要把它加入工程，然后會(huì)編譯它的 pascal 文件）。然后，你就可以直接使用 SendDebug(要送到記錄文件的字符串 )。 或者，你需要它更機(jī)警一些，可以使用 SendDebugEx（它給 TMsgDlgType 增加了一個(gè)新的消息類型 )SendMethodEnter, SendMethodExit, SendSeparator 等等（用法都差不多）。如果你打算給最終用戶分發(fā)客戶端 ()， 不要忘記 include 所需要的程序包。 Gexperts 可以在 得到，它是免費(fèi)的。 第三個(gè) 方法：大概是最艱苦的方法，就是使用自己的記錄控制。這個(gè)方法可能不是想象的這么簡(jiǎn)單。 可能首先會(huì)想到“在窗體上扔一個(gè) RichEdit,把它設(shè)置為只讀的，然后往里面寫(xiě)記錄”是這樣吧？理論上不錯(cuò)，但是，實(shí)施起來(lái)?首先，使用 RichEdit 控件來(lái)做記錄，會(huì)大大降低應(yīng)用程序的速度，還會(huì)在內(nèi)存中造成碎片，甚至丟失內(nèi)存。通常，在運(yùn)行 10分鐘左右之后，會(huì)使整個(gè)計(jì)算機(jī)的速度變慢！所以，如果 希望 在自己的記錄中能夠使用彩色和圖標(biāo)，那么最好自己創(chuàng)建一個(gè)組件。如果沒(méi)有這么高的要求，那么有一個(gè)簡(jiǎn)單有效的方法，就是使用 ListBox 控件作記錄，把 ListBox 的 Style 屬性設(shè)置為 lbOwnerDrawFixed，這樣句柄將會(huì)自繪。（ Gexperts 的控制臺(tái)就是用這樣的方法制作的）。 (4)將記錄和異常處理結(jié)合使用 不用總是擔(dān)心可能會(huì)發(fā)生什么偶然的異常。一般來(lái)說(shuō)，通過(guò)很多的 bugs 測(cè)試后（盡量折磨程序，看看它會(huì)不會(huì)崩潰），應(yīng)用程序在運(yùn)行是應(yīng)該不會(huì)出現(xiàn)什么錯(cuò)誤。下面的這個(gè)技術(shù)，建議組件開(kāi)發(fā)者，在第一次把組 件放在 IDE 環(huán)境測(cè)試的時(shí)候，很應(yīng)該遵守。一個(gè)在IDE 中產(chǎn)生的異常會(huì)導(dǎo)致很多問(wèn)題，甚至可能無(wú)法重新啟動(dòng) IDE 也不能恢復(fù)。這個(gè)技術(shù)很簡(jiǎn)單。在代碼中每一個(gè)函數(shù)或是主要的函數(shù)中加入： try { //函數(shù)的代碼 } catch(Exception amp。E) { SendDebugMessage( “ Exception caught in classname::functionname of type: ” +() +” with the message:” +)。 }。 把字符串中 classname 和 functionname 替換成相應(yīng)的類名和函數(shù)名。在出現(xiàn)錯(cuò)誤時(shí)，你會(huì)立刻知道錯(cuò)誤發(fā)生的位置。這樣也就不至于強(qiáng)制重起 IDE 的了。 ClassName()給了 什么樣的幫助呢？它只是用于返回字符串“ Exception”嗎？每一次，E 都被聲明為異常類型？這是 VCL 另一個(gè)優(yōu)秀的地方，所有的類都從 Tobject 繼承，所以，這些類都能自動(dòng)獲得正確的類型和基類的類型，所有的更多的信息都可以在這里找到。（請(qǐng)參見(jiàn) Tobject 的幫助）所以，盡管 使用了 Exception amp。E，其中的 ()將返回捕獲到的產(chǎn)生異常的實(shí)際類名。得到這些好處需要付出的代價(jià)是編譯出來(lái)的可執(zhí)行文件變大了一些。所有的 Delphi/Cbuilder 用戶都注意到了這一點(diǎn)，但是說(shuō) 沒(méi)有付出就沒(méi)有收獲。在 howto 欄目可以看到 Xiphias 的一系列文章。其中，他提到了使