【文章內容簡介】 些方面太出色，光是這個向下不兼容就足以讓我拋棄它。而且雖說通過捆綁編譯器， 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)在還有人知道這個產品嗎？ )和 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ī)模和質量都可以看出。 (哪個同類產品的幫助文檔能和 MSDN 比呢？ )Inprise公司應從 Netscape 吸取教訓，不要讓 C++Builder 成為第二個 Netscape Communicator。(Communicator 也是一度技術領先，甚至曾 占據(jù)了大部分的瀏覽器市場，但似乎后勁不足，而且 PR 2 中 bug 多多，現(xiàn)在被 IE 壓得抬不起頭。 )C++Builder 是 Inspires 的旗艦產品之一，前景應當還是比較樂觀的，而且 Inspires 已經在向 Linux 進軍了，而微軟還遲遲沒有動作，難道非要到 Linux 成燎原之勢 (或許已經成燎原之勢了 )才會奮起占領這個新興市場？似乎他們對 Linux 的態(tài)度與幾年前對互聯(lián)網(wǎng)的興起的反應遲緩有些相似。但后來 ......唉，真希望 Inprise 不要步 Netscape 的后塵。 C++Builder 是一個很有前途的開發(fā) 工具。遺憾的是， Inprise 公司 Delphi 的創(chuà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ù)），這樣的處理方法很容易就會被忽略。（比如說，你經常檢查 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()語句中，錯誤不會被重復的捕捉，也就是說，如果前面的 catch()語句捕捉到了錯誤，后面的 catch()語句將不會捕捉這條錯誤。 這個機制還有更多的功能。如果你想處理異常，但是不想在處理的位置停止，那么可以重新拋出異常。這時，程序將繼續(xù)尋找下一個 catch()語句來處理這個異常。這個方法和“ throw”差不多。這樣，你處理過的異常會再次被拋出，繼續(xù)尋找下一個 catch 語句來處理它。 最后一個要說的是 __finally（這不是標準的用法，是 Borland 添加 的一個好方法），在__finally{}程序塊中代碼，無論是否發(fā)生異常都會被執(zhí)行。這是一個清理程序中使用 new分配的本地變量，設置用作旗標的變量值為正常的好位置。（比如，把一個等待狀態(tài)的光標圖標設置為正常光標。） 就是這些了。有時間的話，請看看 C++Builder 幫助文件中的 Exception 類以及繼承 Exception 的類。這些將對于理解本節(jié)所說的內容有很大幫助。 (3)使用記錄機制 不可能總是用調試器來 調試代碼，在某些情況下，可能無法使用內部集成的調試器，這時候， 就不得不依靠其他手段調試程序了。（ 比如： Windows NT 服務程序 ,ISAPI/CGI 程序，實時應用程序等等）。這時候，有經驗的程序員可能會借助古老的調試方法，例如，使用一些分類的記錄機制來確定程序實際運行的過程?，F(xiàn)在有一系列的方法可以簡單的完成這樣的工作。下面將介紹 3 種方法。 第一 個方法： OutputDebugString。（ WinAPI: VOID OutputDebugString(LPCTSTR lpOutputString)。）很幸運，微軟徹底的實現(xiàn)了調試子系統(tǒng)。它包括的一些特點可能讓你想把自己的記錄系統(tǒng)扔掉。應用程序在調試器 進程中運行時 OutputDebugString 將用 C 字符串把調試器輸出的信息打印出來。如果程序沒有在調試器進程中運行，它將忽略這些調用。它會很好的在客戶的機器上運行，不會彈出信息窗口。如果在發(fā)布給客戶的時候，忘記去掉這些代碼程序僅僅會變慢一點，不會有別的不良后果。 第二個方法：使用了 Gexperts，通過 接口進行調試。它是個可以稱之為偉大的程序，你可以把它分發(fā)給客戶。和 OutputDebugString 一樣，如果客戶沒有這個程序，它就根本什么也不作。（它會自動檢測機器上是否安裝了客 戶端）。要使用 dbugintf，它很容易被加入到你的工程中，加入 include （要把它加入工程，然后會編譯它的 pascal 文件）。然后，你就可以直接使用 SendDebug(要送到記錄文件的字符串 )。 或者，你需要它更機警一些，可以使用 SendDebugEx（它給 TMsgDlgType 增加了一個新的消息類型 )SendMethodEnter, SendMethodExit, SendSeparator 等等（用法都差不多）。如果你打算給最終用戶分發(fā)客戶端 ()， 不要忘記 include 所需要的程序包。 Gexperts 可以在 得到，它是免費的。 第三個 方法：大概是最艱苦的方法，就是使用自己的記錄控制。這個方法可能不是想象的這么簡單。 可能首先會想到“在窗體上扔一個 RichEdit,把它設置為只讀的，然后往里面寫記錄”是這樣吧？理論上不錯，但是，實施起來?首先，使用 RichEdit 控件來做記錄，會大大降低應用程序的速度，還會在內存中造成碎片，甚至丟失內存。通常，在運行 10分鐘左右之后，會使整個計算機的速度變慢！所以，如果 希望 在自己的記錄中能夠使用彩色和圖標，那么最好自己創(chuàng)建一個組件。如果沒有這么高的要求，那么有一個簡單有效的方法，就是使用 ListBox 控件作記錄，把 ListBox 的 Style 屬性設置為 lbOwnerDrawFixed，這樣句柄將會自繪。（ Gexperts 的控制臺就是用這樣的方法制作的）。 (4)將記錄和異常處理結合使用 不用總是擔心可能會發(fā)生什么偶然的異常。一般來說，通過很多的 bugs 測試后（盡量折磨程序，看看它會不會崩潰），應用程序在運行是應該不會出現(xiàn)什么錯誤。下面的這個技術，建議組件開發(fā)者，在第一次把組 件放在 IDE 環(huán)境測試的時候，很應該遵守。一個在IDE 中產生的異常會導致很多問題，甚至可能無法重新啟動 IDE 也不能恢復。這個技術很簡單。在代碼中每一個函數(shù)或是主要的函數(shù)中加入： try { //函數(shù)的代碼 } catch(Exception amp。E) { SendDebugMessage( “ Exception caught in classname::functionname of type: ” +() +” with the message:” +)。 }。 把字符串中 classname 和 functionname 替換成相應的類名和函數(shù)名。在出現(xiàn)錯誤時，你會立刻知道錯誤發(fā)生的位置。這樣也就不至于強制重起 IDE 的了。 ClassName()給了 什么樣的幫助呢？它只是用于返回字符串“ Exception”嗎？每一次，E 都被聲明為異常類型？這是 VCL 另一個優(yōu)秀的地方，所有的類都從 Tobject 繼承，所以，這些類都能自動獲得正確的類型和基類的類型，所有的更多的信息都可以在這里找到。（請參見 Tobject 的幫助）所以，盡管 使用了 Exception amp。E，其中的 ()將返回捕獲到的產生異常的實際類名。得到這些好處需要付出的代價是編譯出來的可執(zhí)行文件變大了一些。所有的 Delphi/Cbuilder 用戶都注意到了這一點，但是說 沒有付出就沒有收獲。在 howto 欄目可以看到 Xiphias 的一系列文章。其中，他提到了