?? 115.htm
字號:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CB vs Delphi</title>
</head>
<div><center>
<table border="0" width="640">
<tr><td align="center"><b>CB vs Delphi</b></td></tr>
<tr><td align="center"><font color="#CC9933"></font></td></tr>
<tr><td> 自從Borland推出了Borland C++ Builder之后,許多人時常會詢問BCB和Delphi有什么不同?除了使用的語言(C/C++ v.s. Object Pascal)之外,是不是都一樣?也有人經 常會不滿的指出,是不是BCB 一定會在功能上落后Delphi一個版本,那么使用BCB的人比 <br>起Delphi 的程序員來說,是不是代表全用BCB的人是二等公民.說實話在BCB 1.0中由于Borland主要的目的是推出使用C/C++ 語言的RAD工具所以BCB 1.0和Delphi 2.0的功能上幾乎是一樣,但 是BCB 1.0卻遠比Delphi 2.0晚了一年的時間才推出.以致造成許多 人有上面的印象和問題的出現.今年的三月Borland又推出了BCB3.0, 雖然BCB3.0距離Delphi3.0推出的時間縮短10個月,但是BCB 3.0的功能是不能仍然是復制Delphi 3.0的功能呢?雖然BCB3.0和Delphi3.0在整合發(fā)民環(huán)境,VCL元件,和許多地方仍然非常的類似, <br>但是在BCB3.0的技術底層卻已經和Delphi3.0仍然是以 VCL元件類別為主,但是在建立ActiveX元件和N-Tier的應用程序技術上 將會走向不同的方向.這是因為C/C++和Object Pascal語言上差異的原 因.在本篇文章中,我將從技術的角度討論C++ BCB 3.0和Delphi 3.0的 不同,希望能夠讓使用這二個開發(fā)工具的程序員都有所了解.<br><br># BCB 3.0 在除錯功能的大幅領先 <br><br>對于C/C++的使用者而言,除錯是平日工作中的少不了的事情.所以一個C/C++編譯器的除錯功能就直接影響了生產力.在BCB 3.0中Borland對于 BCB3.0除錯功能的強化會讓Delphi3.0的使用者羨慕的不得了.BCB3.0除了 擁有Delphi3.0對于雙數檢視的工具視窗,加快了檢視字串變數的之外,更 加入了強勁的模組檢視功能.這個模組檢視器可以讓你巨細靡遺的觀看應 用程序使用權的所有DLL以及專案中每一支程序的所有的方法.在中斷點之 處啟動模組檢視器檢查應用程序.你可以看到模組檢視器顯示了多么詳細的資訊.更令人驚訝的是,BCB 3.0在應用程序執(zhí)行時期居然能夠顯示出類似物件檢視器的視窗,讓你檢查一個VCL元件的所有資訊.包括特性值,方法和事件處 理函數.這個除錯功能實在太棒了,因為有了它之后,你就可以掌握執(zhí)行時期 VCL元件所有的變化.此外BCB 3.0也包括了一個Event Log可以讓檢視應用程序執(zhí)行時發(fā)生的事件.這些新的除錯功能都是Delphi3.0所沒有的低層除錯能力.除了除錯功能之外,BCB3.0也允許程序員對于編譯器更好的控制能力.圖形是BCB 3.0中新的 高等編譯器選項功能.你可以看到BCB和一往的BC++一樣允許你更進一步的控制 產生的程序碼品質.請注意在這些選項中有一項MFC Compatibility. 當你需要 在BCB3.0中編譯MFC的程序時,你必須選擇這個選項,因為MFC使用了許多不正確 而且奇怪的C/C++語法,為了要讓BCB的編譯器能夠順利的編譯MFC程序,這個選 項可以讓編譯器不致產生嚴重的錯誤. <br><br>#制作ActiveX/N-Tier遠程服務器的技術差異 <br><br>Delphi 3.0是PC級的工具中第一個真正可以開發(fā)N-Tier的開發(fā)工具. 另外Delphi3.0也是所有Borland的工具中支援COM/ActiveX最為完整的工 具,但是現在這個局面將被BCB 3.0打破.因為Borland現在也給予了C/C++ 使用權者相同的強大功能,讓C/C++的程序員也可以設計出分散式物件計算 應用程序.此外BCB 3.0也可以讓你一個步驟便制作出ActiveX元件.但是在 產生分散式物件和ActiveX元件時,Delphi3.0和BCB3.0差別最大的地方.下 面列出這兩個產品使用的引擎. <br><br>Delphi 3.0 ----DAX (Delphi ActiveX Engine) <br>Borland C++ Builder 3.0 ----ATL (ActiveX Template Library) <br><br>它們使用的引擎不同的原因除了Object Pascal不支持樣版(template) 外,另外的原因便是讓BCB產生的ActiveX元件和DCOM服務器能夠比較小.此 外BCB 3.0藉由使用ATL可以讓C/C++的程序員在未來跟上MicroSoft最新的 技術,例如對于COM+的支援.例如,當你使用BCB3.0建立遠端的DCOM服務器, 可以啟動ATL選項指定DCOM服務器使用的樣例方式以及使用的執(zhí)行緒模型. 當你使用BCB3.0的ATL選項制作ActiveXForm時,它可以結合資料庫的能力, 讓你開發(fā)出可以直接在IE瀏覽器中執(zhí)行的資料庫應用程序.在這里有一點很重要的是在Delphi 3.02的DAX引擎之中,并沒有指定 ActiveX元件使用的執(zhí)行緒模式.所以由Delphi 3.02制作的ActiveX和Act-iveFrom都無法正確的在IE4.0之中顯示出來.這并不是Delphi 3.02的臭蟲, 而是Microsoft改變了ActiveX元件游戲的規(guī)則.此外由于IE4.0之中有一些 臭蟲的存在,所以我建議你升級到4.01或是4.02. <br><br>#處理Windows訊息的技術差異 <br><br>BCB 3.0和Delphi 3.02在處理Window計算的方式上也有相異這處. 基本上BCB和Delphi都是使用VCL這個元件類別,所以在處理Window訊息上 也是由VCL元件來處理和分派的.下面的表格比較了VCL, OWL以及 MFC三種 FrameWork在處理Window訊息上的異 <br>同: <br><br>* Windows訊息處理的處理方式: <br>VCL元件類別---使用虛擬函數(Virtual Function) 和動態(tài)函數(Dynamic <br>Function) <br>OWLFramework(2.0之后)---使用虛擬函數 <br>MFCFramework---使用Message MAP <br><br>* Windows訊息caching: <br>VCL元件類別---否 <br>OWLFramework(2.0之后)---是 <br>MFCFramework---否 <br><br>* 處理Windows訊息的速度: <br>VCL元件類別---良好 <br>OWLFramework(2.0之后)---優(yōu) <br>MFCFramework---優(yōu) <br><br>請注意,由于VCL元件類別在處理Window訊息時除了需要分派Window訊息到特定的訊息處理函式之外,它也會負責觸發(fā)VCL上相關事件處理函數, 所以在處理Window訊息的速度上會比OWL以及MFC稍慢,但是在功能上卻比 OWL和MFC更為豐富.在BCB 3.0中由于它使用的C++編譯器是BC++5.3,而且使用的Delphi編譯器也是Version 11,更重要的是由于BCB 3.0除了使用VCL類別進行VCL元 件的事件處理函數的window訊息分派之外,它也使用了類似MFC的Message Map來分派使用者定義的訊息處理函式,所以在處理window訊息的速度上比 Delphi 3.02來得快速. <br><br>#處理windows訊息的方式: <br><br>Delphi 3.02---使用虛擬函數(Virtual Function) 和動態(tài)函數(DynamicFunction) <br>Borland C++ Builder 3.0---混合虛擬函數和動態(tài)函數,以及類似MFC 的MessageMAP的事件處理函數的window訊息分派之外,它也使用了類似MFC的Message Map來分派使用者定義的訊息處理函式,所以在處理window訊息的速度上比 Delphi 3.02來得快速. <br><br>我分別使用Delphi3.02和BCB3.0撰寫了一段處理window訊息1000次的示范程序,在我的Pentium133,64M Ram的機器上執(zhí)行的結果如下: <br><br>處理1000訊息的時間: <br>BCB 3.0-------4.08 <br>Delphi 3.02---4.89 <br><br>從上面的結果也可以證明BCB在處理window訊息方面是比Delphi3.02來得稍為快速.此外在ActiveX元件方面由于BCB3.0也是使用ATL的Message MAP 方式,所以在這方面比Delphi 3.02有較好的表現. <br><br># 系統功能的支援 <br><br>BCB3.0除了前面比較偏向底層技術的革新之外,它也提供了一些重要的工具讓先前使用BC++或是VC++的開發(fā)者可以很快地轉換到BCB的開發(fā)環(huán)境之中. 第一個工具是所謂的資源轉換精靈,它可以幫助你轉換資源文件的內容成為BCB使用的表格和VCL元件.第二個工具是Borland推出的新工具Comm20MF.這個工具可以讓你轉換VC++產生的DLL成為能夠讓BCB使用的DLL. <br><br># RC Import精靈 <br><br>對于許多使用BC++和VC++的人來說,一定使用了Resource Workshop或是AppStudio設計了許多的資源文件. 那么這些儲存對話盒或是其他視窗資源的文件如何在BCB 3.0中使用呢?是不是需要BCB使用的元件重新設計呢?當然重新設計所有的資源文件將會是一件令人痛苦的事情.Borland為了解決這個問題,特別為所有使用BCB 3.0的人提供了一個工具RC Import精靈.你可以在BCB的Tools選單中找到它.RC Import精靈可以幫助你讀取由BC++和VC++設計的所有資源,然后再把這些資源轉換為BCB使用的表格或是VCL元件.如此一來你就可以直接在BCB中使用這些資源,并且結合所有BCB提供的VCL元件.有了RC Import精靈之后,你原先不管是使用BC++或是VC++設計的資源文件都能夠立刻轉換為BCB3.0的表格或是VCL元件,可以大幅減少你從這二個C++工具移轉到BCB3.0所需要花費的時間. <br><br># COFF函數庫的支持 <br><br>在傳統上Borland和Microsoft的C++編譯器所產生的Object文件格式便是是不一樣的.Borland一直是使用OMF,而Microsoft則是使用COFF格式. 這造成許多由VC++編譯的DLL無法讓BCB使用的情形.Borland為了解決這個問題,所以在BCB 3.0中提供了這個工具讓開發(fā)者能夠轉換VC++的DLL檔案格式成為BCB使用的OMF形式.如此一來就不會再有以前的困擾了.據我所知,Borland在未來會繼續(xù)強化這個工具,讓它功能更為強大,例如可能在未來也能夠轉換靜態(tài)的函數庫(.LLB)文件.除了上述的系統功能支持之外,事實上BCB3.0的連結器現在也能夠產生正確kernel-mode的驅動程序文件格式.這代表你已經可以使用BCB 3.0編寫驅動程序了.從這點來看BCB3.0對于系統工程師是非常有幫助的.BCB的程序員終于可以吐一口氣了,因為BCB3.0在許多方面都領先了Delphi3.0.從的VCL元件類別3.5版,高等多重專案管理工具,到強勁的低層除錯功能,同時支援VCL,MFC,OWL都顯示BCB3.0是一個同時兼顧應用程序設計員和系統工程師需求的工具.此外由于BCB3.0繼承了Delphi3.0對于Multi-Tier,Internet應用程序功能方面的經驗,所以BCB是第一個讓C/C++程序設計員可以開發(fā)分散式計算環(huán)境應用程序的工具. 在未來 BCB也將會同時支援Microsoft的COM+和CORBA等分散式物件技術的標準. 這代表使用BCB,你就不必擔心未來你的應用程序會產生無法繼續(xù)執(zhí)行問題.當然,對于Delphi的使用者而言,所有由BCB3.0開發(fā)出來的技術,也都將出現在Delphi未來的版本之中.從這個角度來看,BCB和Delphi將會是相互超前,且吸收彼此功能的競爭局面.這對于BCB和Delphi使用者都是有利的,因為這二個產品在這種情形下將會進步得更為迅速,相信這是所有使用Borland產品的人高興見到的事情.</td></tr>
</table></center></div>
</html>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -