,,

自從Borland推出了Borland C++ Builder之后,許多人時常會詢問BCB和Delphi有什么不同?除了使用的語言(C/C++ v.s. Object Pascal)之外,是不是都一樣?也有人經常會不滿的指出,是不是BCB 一定會在功能上落后Delphi一個版本,那么使用BCB的人比
起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在整合發民環境,VCL元件,和許多地方仍然非常的類似,
但是在BCB3.0的技術底層卻已經和Delphi3.0仍然是以 VCL元件類別為主,但是在建立ActiveX元件和N-Tier的應用程序技術上將會走向不同的方向.這是因為C/C++和Object Pascal語言上差異的原因.在本篇文章中,我將從技術的角度討論C++ BCB 3.0和Delphi 3.0的不同,希望能夠讓使用這二個開發工具的程序員都有所了解.' W$ I+ \2 K2 o

# BCB 3.0 在除錯功能的大幅領先

對于C/C++的使用者而言,除錯是平日工作中的少不了的事情.所以一個C/C++編譯器的除錯功能就直接影響了生產力.在BCB 3.0中Borland對于 BCB3.0除錯功能的強化會讓Delphi3.0的使用者羨慕的不得了.BCB3.0除了擁有Delphi3.0對于雙數檢視的工具視窗,加快了檢視字串變數的之外,更加入了強勁的模組檢視功能.這個模組檢視器可以讓你巨細靡遺的觀看應用程序使用權的所有DLL以及專案中每一支程序的所有的方法.在中斷點之處啟動模組檢視器檢查應用程序.你可以看到模組檢視器顯示了多么詳細的資訊.更令人驚訝的是,BCB 3.0在應用程序執行時期居然能夠顯示出類似物件檢視器的視窗,讓你檢查一個VCL元件的所有資訊.包括特性值,方法和事件處理函數.這個除錯功能實在太棒了,因為有了它之后,你就可以掌握執行時期 VCL元件所有的變化.此外BCB 3.0也包括了一個Event Log可以讓檢視應用程序執行時發生的事件.這些新的除錯功能都是Delphi3.0所沒有的低層除錯能力.除了除錯功能之外,BCB3.0也允許程序員對于編譯器更好的控制能力.圖形是BCB 3.0中新的高等編譯器選項功能.你可以看到BCB和一往的BC++一樣允許你更進一步的控制產生的程序碼品質.請注意在這些選項中有一項MFC Compatibility. 當你需要在BCB3.0中編譯MFC的程序時,你必須選擇這個選項,因為MFC使用了許多不正確而且奇怪的C/C++語法,為了要讓BCB的編譯器能夠順利的編譯MFC程序,這個選項可以讓編譯器不致產生嚴重的錯誤.

#制作ActiveX/N-Tier遠程服務器的技術差異
$ Z. u9 M7 ~$ t% N- @- \( Q
Delphi 3.0是PC級的工具中第一個真正可以開發N-Tier的開發工具. 另外Delphi3.0也是所有Borland的工具中支援COM/ActiveX最為完整的工具,但是現在這個局面將被BCB 3.0打破.因為Borland現在也給予了C/C++ 使用權者相同的強大功能,讓C/C++的程序員也可以設計出分散式物件計算應用程序.此外BCB 3.0也可以讓你一個步驟便制作出ActiveX元件.但是在產生分散式物件和ActiveX元件時,Delphi3.0和BCB3.0差別最大的地方.下面列出這兩個產品使用的引擎., ^& f1 u: r9 ]6 |9 o" V
) Y" G' U' l: X! W/ |$ [
Delphi 3.0 ----DAX (Delphi ActiveX Engine)4 u/ |0 a; _( y# u5 a+ z: W! e
Borland C++ Builder 3.0 ----ATL (ActiveX Template Library)
' D% V' m% e0 k, ~: N% ?
它們使用的引擎不同的原因除了Object Pascal不支持樣版(template) 外,另外的原因便是讓BCB產生的ActiveX元件和DCOM服務器能夠比較小.此外BCB 3.0藉由使用ATL可以讓C/C++的程序員在未來跟上MicroSoft最新的技術,例如對于COM+的支援.例如,當你使用BCB3.0建立遠端的DCOM服務器, 可以啟動ATL選項指定DCOM服務器使用的樣例方式以及使用的執行緒模型. 當你使用BCB3.0的ATL選項制作ActiveXForm時,它可以結合資料庫的能力, 讓你開發出可以直接在IE瀏覽器中執行的資料庫應用程序.在這里有一點很重要的是在Delphi 3.02的DAX引擎之中,并沒有指定 ActiveX元件使用的執行緒模式.所以由Delphi 3.02制作的ActiveX和Act-iveFrom都無法正確的在IE4.0之中顯示出來.這并不是Delphi 3.02的臭蟲, 而是Microsoft改變了ActiveX元件游戲的規則.此外由于IE4.0之中有一些臭蟲的存在,所以我建議你升級到4.01或是4.02.+ C  w! Z% Y) v. q" ]

#處理Windows訊息的技術差異
% f" C; ^& ^1 h9 ^
BCB 3.0和Delphi 3.02在處理Window計算的方式上也有相異這處. 基本上BCB和Delphi都是使用VCL這個元件類別,所以在處理Window訊息上也是由VCL元件來處理和分派的.下面的表格比較了VCL, OWL以及 MFC三種 FrameWork在處理Window訊息上的異+ B& h# ]7 i; Q
同:# m+ r) B9 |( A$ X) a" e! H7 E
' T# m3 q# C- f- o- }/ t" _( v: M( s
* Windows訊息處理的處理方式:- Y( K8 R* D9 |! T) f. z% {
VCL元件類別---使用虛擬函數(Virtual Function) 和動態函數(Dynamic. [2 @# I) F9 d" `+ E7 M0 |2 x
Function)
OWLFramework(2.0之后)---使用虛擬函數
MFCFramework---使用Message MAP. d% c; g  M9 u9 N" h% J5 _8 }
( N4 R1 W% K9 S' O# e. s- R. L
* Windows訊息caching:
VCL元件類別---否
OWLFramework(2.0之后)---是/ A9 j" V+ O5 ?9 G4 B. D7 h
MFCFramework---否
5 O2 y) g# a- j, o6 M/ z. I
* 處理Windows訊息的速度:
VCL元件類別---良好
OWLFramework(2.0之后)---優
MFCFramework---優) E% O1 X2 X0 {6 T
& @9 a* [9 w( }4 s% L
請注意,由于VCL元件類別在處理Window訊息時除了需要分派Window訊息到特定的訊息處理函式之外,它也會負責觸發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來得快速.

#處理windows訊息的方式:
4 D% r5 ]% h" c4 k
Delphi 3.02---使用虛擬函數(Virtual Function) 和動態函數(DynamicFunction)
Borland C++ Builder 3.0---混合虛擬函數和動態函數,以及類似MFC 的MessageMAP的事件處理函數的window訊息分派之外,它也使用了類似MFC的Message Map來分派使用者定義的訊息處理函式,所以在處理window訊息的速度上比 Delphi 3.02來得快速.
) j* m$ Z6 J' W0 l) h
我分別使用Delphi3.02和BCB3.0撰寫了一段處理window訊息1000次的示范程序,在我的Pentium133,64M Ram的機器上執行的結果如下:+ F4 E5 u5 k8 y; K! f1 P
+ K1 D- y% d* x+ A& \
處理1000訊息的時間:
BCB 3.0-------4.08
Delphi 3.02---4.890 `! d% u2 `) R
% Y- u1 @8 k1 W9 e8 K) v+ _6 ^% D
從上面的結果也可以證明BCB在處理window訊息方面是比Delphi3.02來得稍為快速.此外在ActiveX元件方面由于BCB3.0也是使用ATL的Message MAP 方式,所以在這方面比Delphi 3.02有較好的表現.

# 系統功能的支援; ~* V. u( m$ d/ ~6 i7 j$ O
( V) Z/ P8 p7 \/ I/ A. ~
BCB3.0 除了前面比較偏向底層技術的革新之外,它也提供了一些重要的工具讓先前使用BC++或是VC++的開發者可以很快地轉換到BCB的開發環境之中. 第一個工具是所謂的資源轉換精靈,它可以幫助你轉換資源文件的內容成為BCB使用的表格和VCL元件.第二個工具是Borland推出的新工具 Comm20MF.這個工具可以讓你轉換VC++產生的DLL成為能夠讓BCB使用的DLL., L* K) S7 n' v% c" L5 [6 r2 H' ]

# RC Import精靈

對于許多使用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所需要花費的時間.
0 q8 k6 i( o1 h& ?( `" E2 U
# COFF函數庫的支持
7 q. Z7 ]8 ~  C" T. O
在傳統上Borland和 Microsoft的C++編譯器所產生的Object文件格式便是是不一樣的.Borland一直是使用OMF,而Microsoft則是使用COFF 格式. 這造成許多由VC++編譯的DLL無法讓BCB使用的情形.Borland為了解決這個問題,所以在BCB 3.0中提供了這個工具讓開發者能夠轉換VC++的DLL檔案格式成為BCB使用的OMF形式.如此一來就不會再有以前的困擾了.據我所知, Borland在未來會繼續強化這個工具,讓它功能更為強大,例如可能在未來也能夠轉換靜態的函數庫(.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++程序設計員可以開發分散式計算環境應用程序的工具. 在未來 BCB也將會同時支援Microsoft的COM+和CORBA等分散式物件技術的標準. 這代表使用BCB,你就不必擔心未來你的應用程序會產生無法繼續執行問題.當然,對于Delphi的使用者而言,所有由BCB3.0開發出來的技術,也都將出現在Delphi未來的版本之中.從這個角度來看,BCB和Delphi將會是相互超前,且吸收彼此功能的競爭局面.這對于BCB和Delphi使用者都是有利的,因為這二個產品在這種情形下將會進步得更為迅速,相信這是所有使用Borland產品的人高興見到的事情

主題：CB vs Delphi

CB vs Delphi

回復標題：
上傳附件：

	簽名：不顯示顯示