請問 Visual C++ and Buield C++的差異及其優劣?
@-min
尚未認證通過
--------------
Visual C++ vs C++ Builder
其實很久以前我就想寫這篇文章，其原因一方面是因為筆者深深感覺
到C++ Builder的確是一個先進與強大的程式開發工具，但更最重要的
一點是，我深信C++ Builder能給公司帶來巨大了商業利益與生產力的
大幅提升，我可以假裝沒看到這幾點，但是基於良心與責任我不能不
花點時間來跟大家分享一下我的看法與心得。
C++ Builder的前身是Borland C++，Borland C++ 所使用的Application
Framework是OWL，而OWL以物件導向的角度來看，也的確比MFC先進很多
（這在學界早有定論），但是在市場上卻叫好不叫座，直到Imprise
（以前的Borland）推出以VCL為Application Framework的Delphi之後，
這才一炮而紅。
雖然Delphi的VCL非常強大與好用，但是Delphi所使用的是OOPascal語法
，和C++不同，直到後來，Imprise才推出以C++為程式語言的C++ Builder
，而其所使用的Application Framework正是赫赫有名的VCL。
VCL的全名是“Visual Component Library“，它是一種新一代的
Application Framework，以元件化、視覺化為設計的方向。VCL的興起，
起源於OWL和MFC都日見龐大與癡肥，不利於日益複雜的程式開發趨勢，於
是Imprise的設計小組決定開發一套更物件導向化的Application Framework，
使程式設計師能以視覺化的觀念、元件重用的觀念來快速設計出各式各樣的
應用程式，將物件導向的威力與精髓發揮的淋漓盡致，相形之下，OWL和MFC
都只算過時與半屌子的Application Framework。
果然～C++ Builder一推出後，在微軟的大軍壓境下以及人們西瓜靠大邊的
心態下，仍然引起了一陣旋風，在News上許多程式師表示它們對C++ Builder
的肯定與激賞，更有人指出，根據經驗，在微軟的市場優勢之下，Delphi
和C++ Builder仍能欣欣向榮，這表示Delphi和C ++ Builder的產品水準不是
只贏微軟產品幾個百分點，而是數十至數百個百分點，否則Imprise的產品早
就消失不見了。
到底C++ Builder的特性與優點在哪裡呢？這對於我們公司又有什麼利弊呢？
我的觀點與分析如下。
大家想一想，當我們使用Visual C++來開發程式的時候，最痛苦的事情是什
麼？答對了～那就是GUI的設計。根據經驗，通常我們利用Visual C++開發一
套軟體時，設計GUI所花的時間幾乎佔掉程式開發週期的三分之一～甚至到二
分之一以上，而設計和界面無關的核心程式通常只佔了不到二分之一左右至三
分之二的時間，但是使用C++ Builder則可以大幅簡化這個問題。C++ Builder
的VCL提供大量的各式各樣GUI軟體元件，讓我們可以將大部分的心力放在核心
程式碼的設計上，而不必跟Windows系統的訊息、界面去搏鬥。
C++ Builder的Compiler在功能上跟Visual C++都一樣，Win32 API等都可以
呼叫與使用（VCL就是架構在Win32 API之上，沒有不相容的問題，只是包裝的
更高明，也非常有彈性），你不用擔心目前有什麼事情是Visual C++可以做而
C++ Builder做不到的，進而拒絕使用C++ Builder，抱持這樣的觀點就好像為
了健康而不坐汽車，卻堅持騎腳踏車從淡水來上班一樣因噎廢食，在網路許多
非常有經驗的程式設計師會告訴你這是多慮了。曾有人比喻的很傳神，如果
Visual C++是手排車，那C++ Builder就是手自排兩用車（看過三菱的Sports
mode手自排兩用車嗎？）。
C++ Builder的程式設計細節是清楚而透明的，除了Application Framework
的運作保有神秘感之外（MFC也是），所有的程式碼與檔案相關的檔案都是可
以掌握與觀看的，不像某些開發工具，程式設計師許多事情是無法掌握的，
而C++ Builder 所產生的碼大小與產生的時間都和Visual C++ 都是同級的
（我指的是勝負差距都不大）。
我的觀點是，我們公司非常適合大量採用C++Builder作為程式開發工具，當然
啦，為了相容性的考量和母公司有特殊要求的專案除外。由Visual C++轉換
到C++ Builder不是很嚴重與痛苦的事情，反而會覺得很快樂，這就好像開手排
車人改學自排車一樣，甚至可以更掌握C++ Builder的威力。
利用C++ Builder來開發程式，我們可以快速的產生程式的GUI layout和prototype
，在後續調整程式界面的調整週期中也非常的方便，我個人認為至少可以比
Visual C++節省三至五倍以上的時間。
除了某些特殊需求的專案之外（例如版本升級，而原來的版本是VC開發的，或
者參考改寫的程式碼是用VC寫的，事實上C++ Builder也可以支援MFC），我
看不出來公司有什麼專案的規模或內容非要靠Visual C++不可，自己找罪受不說
，也違反了“Build a high performance company“的目標，而將大量的資源投
注在落後的工具上，程式生產力也無法巨幅提升。因此我建議公司應該大量而
全面性的鼓勵員工使用並熟悉C++ Builder成為第一線的程式開發工具，根據我
的淺見，這樣的投資不但回收快速，而且效果宏大。
簡而言之，C++ Builder同時兼具C++程式語言的威力和Visual Basic這種 Rapid
Development Tool的視覺化程式開發環境的便利，土法煉鋼或必先利其器，決
定就在你了。
To be or not to be, it is the question.
習慣的確是一個主要的癥結點
事實上如果C++ Builder和VC的程式生產力差不了多少的話
那我認為用什麼都差不多；）我也不會寫前面幾篇的文章了....
但若是事實不是這樣呢？？我們要付上多少不必要的代價？我們做過多少的評估？
事實上若我不提，公司也沒什麼人會對這個問題進行深入的了解與評估
並加以衡量公司能從中得到什麼樣的利益與經驗？
人性都是如此～習慣原有的東西～潛意識抗拒與排斥新的事物
更何況舊有的東西還是微軟的主力產品
這也是許多公司繼續沿用VC的產品....直到受不了為止
其實就算目前的專案用什麼都可以（幾乎用不到GUI）
使用C++ Builder還是有其巨大的利益
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
服我，BCB 能增加我多少的生產力，這證據是由實驗證明，而不是
news group 上一些人順口的人云亦云。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
別人再多的實驗證明，還是比不上我們親自來實驗；）我想這也是
ＸＸＸ叫我用C++ Builder來做ＸＸＸ的緣故我只能說我的親身經歷
支持Internet上的說法；）
還有一點是我的看法
不論國內或國外的newsgroup，我都看到許多高手發表文章來指出
C++ Builder的優越性而台灣方面這些高手甚至精通數種開發工具
，並出過許多書。我比較擔心的是基於習慣性和對微軟的“信任“
會使得就算有再多的證據指出C++ Builder會比VC帶來更多的好處，
也不會被採信～這不是針對我們公司的高級主管，而是基於人性；Ｐ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
更重要的，是方法論。很多數據顯示， programming 占不到整個
project 發展的百分之 30 ，project 本身的意義大於所用的工具。
另外，你以手排，自排來形容兩者的不同，這就對了，為什麼還有這
麼多人要開手排車？因為它馬力好，適合特殊用途。我並不是說，VC
的馬力特別好，我只是認為，每個人都有他特殊的考量。另外，你也
提到了“和界面無關的核心程式”，為什麼稱為核心呢？這才是
Project的精髓所在，我們要 care 也就是這部份，不是嗎？我想，
這就是為什麼那麼多人知道，BCB是一個不錯的工具，而沒有馬上
switch 到這工具上最大的原因吧！ 總而言之，工具的比重不是這
麼重要，太依賴工具，當你的工作環境改變了，你怎麼辦？這就是為
什麼學校的 training 不著重在工具，語言，因為比這個重要的東西
太多了。但經你文章這麼一提，好像公司的許多人都固步自封，
捨棄大車子，而願意騎腳踏車？我很不以為然你的批評方式。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
我是一個非常注重方法論的人；）
和ＸＸＸ出差ＸＸ時，和他聊天我就聊到這一點
事實上我就是因為C++ Builder的革命性觀念會造成程式設計師
“方法論的巨大改變“所以我才強力指出公司會因此得到巨大的利益
換句話說～C++ Builder所帶來的不只是工具環境的改變，更深層的來說
他所帶來的是程式寫作方式與物件導向觀念的巨大改變～會使整個程式
設計的“過程“與思惟都會被影響，程式生產力的巨大提升只是其
“結果“罷了。
還是一句老話～如果C++ Builder只是一個和VC++“差不多同級“的開發工具
那我也不會講這麼多了；Ｐ
如果使用C++ Builder會算是依賴工具
那使用VC也應該逃脫不了這樣的指控才是；）
還有一點要提的是
我也不認為programmin在整個專案當中是最重要的部份
我的文章也很清楚的定位在C++ Builder只是一個很好的程式開發工具
我也知道VC有他的優點，但我的重點是在程式programming的時期，
“公司從VC得到的壞處會大於從他得到的好處“～和C++ Builder比起來
～當然這只是我的看法。
公司一般的程式設計師，不會有興趣來試試看在Coding的時候使用
C++ Builder和VC有什麼不一樣的地方（這是人性～沒有所謂的對錯）
，所以就算C++ Builder比VC優越很多倍，程式設計師還是無法得到這
樣的資訊，並形成強大的動力與決定來打破原有的習慣來使用C++ Builder
，不是嗎？這時似乎只有高級主管能有機會改變這種可能出現的局面，
這也是我寫前面幾封信的目的與動機。
的確～目前許多專案用什麼都可以，換句話說使用VC或C++ Builder
都沒有差～反正都是在寫kernel code，和界面無關，我並沒有說這時
一定要用C++ Builder才叫進步（但是根據我的經驗，此時將除錯的過程
和C++ Builder的GUI功能結合起來，對於除錯仍有極大的幫助）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
我也看了很多 BCB 的介紹，如果有機會，我也很願意試一試，我相信
它是一個非常強大的界面開發工具，勝過VC ，但是，我也相信，
VC 有它許多先天的優勢，若有機會，我很願意繼續和你交換心得。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C++ Builder不只是一個“界面開發工具“而已
而VC和C++ Builder的高手筆戰我也看過太多了
結局已定（當然市場的佔有率正好相反～微軟畢竟太強大了（不是指技術））
我只能說～在這方面我只憂慮一件事情
那就是已目前的技術來看“若我們繼續使用VC來作為我們的主力程式開發
工具，我們要附上的代價會遠大於C++ Builder，而所得到的利益會遠小於
C++ Builder“~
當然這只是我的個人看法，我也很希望高級主管能加以評估與衡量
哎～其實說實在的
我可以什麼都不管，反正錢照領～班照上～要我用ＶＣ就用ＶＣ
慢慢學～慢慢寫～程式生產力低沒關係～反正是公司的事情
但是我沒有辦法做這樣的事情
我必須要指出來我的看法與經驗
畢竟這中間的差異不是只是用Word和Amipro的不同而已
而是“革命性的改變“
差一個人月可以差到二三十萬台幣
這樣的差別是我不能忽略的；Ｐ
Dear JoJoHSU：
我又想到一個很 critical 的問題。
我們公司以前有一些程式用 Borlan 的 C++ 發展，那時還是 31 的時代，
但是，換成 95 後，死傷慘重，但我們用 VC 就沒有這樣的情況了。
受限於系統，想到以後的 upgrade ，這些都是必須考慮的因素。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dear ＸＸＸ
此一時也彼一時也...
我就我所知道的來講.....（年代久遠，細節可能記錯了）
Borland曾經有一陣子很糟糕（Borland C++ 3.0 ～4.5那一段期間）
公司決策的錯誤
使得他們把很多的資源放在開發Database for Window這套軟體上
（不知道軟體的名字有沒有記錯，好像是DB for Window更前一套版本）
結果很失敗～嚴重到動搖到Borland的國本
不但這套軟體在Database的市場裡連FoxPro都打不贏
連Borland C++的開發都因此而延遲很久～
而微軟也從Microsoft C++成功轉型至Visual C++
但之後Borland就開始勵精圖治～大量運用物件導向的方式來開發他們的產品
使得產品週期開發週期減半與產品品質巨幅提升
Dephi的成功正是他們開花結果的產品....
之後直到今天，Borland的產品技術與對Window的支援（開發環境）
在大部分方面都還是遙遙領先微軟的開發工具
舉例來說，我從當兵到今天，微軟的Visual C++從4.2到6.0
整個開發環境架構都沒有什麼巨大的改進
（Visual C++ 6.0加強的是團隊程式開發的除錯環境，
但公司目前都沒有大型的團隊開發專案）
而Borland的產品線是
Delphi 1.0 -> Delphi 2.0 -> Delphi 3.0 -> Dephi 4.0
Borland c++ 5.01 -> C++ Builder 1.0 ->
C++ Builder 3.0 -> C++ Builder 4.0
由於升級的速度快
所以反而能快速反應Window各種新的規格與花樣
（不同版本間也有一些相容性的問題，但和Visual C++的情形差不多）
並會出現這種明明Window是微軟的產品，
但Borland的程式開發環境反而支援的比微軟更快的現象
所以若是以支援的程度來衡量
目前反而是Borland佔了優勢～而這也是Borland一直強調的特色.....
（網路上沒有人會認同微軟的程式開發工具會比Borland更快支援
Windows的這種說法）
另外我要分享一點我個人的看法
以某種角度來看
Visual C++正步上Borland C++同樣的後塵
MFC日益龐大癡肥，已無法應付（指程式開發效率）日益複雜的各種標準與難題
（所以妳會發現這版的Visual C++ 6.0所用的MFC 4.21根本沒什麼大改進）
（微軟也知道這個問題，於是將Borland的Delphi首席程式設計師挖到微軟，
叫他主持Visual J++的開發計畫，並開發新的Application Framework，
雖然頗有成效，但是微軟自作孽，想弄出一套微軟式的Java，結果被Sun告輸，
Visual J++的開發線大受影響）
Borland在兩年以前之所以開始想放棄OWL也正是這個原因（而MFC還不如OWL優秀）
所以以技術來說，Borland目前的VCL領先MFC至少兩年以上～
以目前Visual C++ 6.0的狀況看來，和已經在美國上市的C++ Builder 4.0比起來
只怕會越輸越多.....
微軟內部不是沒人反應過這些事情
但是比爾蓋資對於Visual Basic情有獨鍾
反而使得在政治考量上Visual C++一直不具有
Rapid Application Development（RAD）的威力與特色
但是Visual Basic卻也輸Delphi很多..
C++ Builder 4.0已經在美國上市了
隨後我會寄上相關的網頁資訊供您參考(http://www.inprise.com/bcppbuilder/)
其中有一篇文章是討論為什麼VC該轉至C++ Builder
大家可以討論一下；）
其實很多公司仍選擇使用VC
其原因不外乎是
1.已經使用VC習慣，也懶得去評估BCB有多好，甚至完全不了解BCB這東西
2.為了和前一個版本的程式保持相容性（以前的程式是用VC開發的）
3.錯認VC比BCB更有穩定性與威力
...
其中我覺得只有第二條比較能禁得起考驗與理性的評量
而第三項也不符合現實...
我剛進公司時也是使用VC5.0
但碰到一個滿開明的上司
在我的大力爭取之下
他願意讓我在開發新的專案時使用BCB3.0
以作為評估與比較
結果我的程式生產力馬上巨幅提升～令他訝異
（當然啦～我原有SDK和Windows Programming的概念）
等我這個專案做完了，我將向全公司做的BCB的Demo
因為老一輩的程式設計師“完全不了解BCB的驚人威力“
能多學一種軟體當然是好事
不過一個人想什麼都學好時，就會什麼都學不好....除非你是天才
我曾經也想精通各種語言與程式開發工具
但最後發現這樣什麼都學不精....
不如把所有的精力都專心投注在一個值得投資的東西上面
好好研究
我選擇的就是BCB（C++ + RAD + 全向位的開發威力）
能把BCB完全摸熟已經是不得了的高手了（包括SDK和VCL）
說實在的～你現在再開始專研VC已經有一點來不及了
在VC上痛下苦功的人太多了
比刻苦耐勞與經驗你是打不過那些人的
但時代與趨勢在變
不如投資在BCB上，你會有機會逆轉成功的
因為那些人就是因為投資在VC上太多心血，所以在“感情“上捨不得放棄
他們會為此付出慘痛的代價
而你卻沒有這樣的包袱；）
我會相信BCB會有更廣闊的空間
原因是當軟體的複雜度越來越高時
而完成專案的時間越來越趕時
使用VC只是自己給自己找麻煩.....
而且我相信VC6.0的推出更證明微軟已經搞不出新花樣了
而BCB4.0技術領先的差距只會越來越大....
在MFC的架構下VC7.0要能大逆轉～難如登天喔～
（除非推出新的Application Framework，但如此一來
原來的VC Programmer也要從頭學起，你那時再切入也不遲）
說實在的～我勸你多花一點時間在BCB上
投資報酬率高太多了
也比較有前瞻性；）
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
政治板的許多行為
正好表現出人類對於正義，道德，真理，自由，幸福的渴望
以及人類仇恨，幼稚，非理性，無知，狂妄自大的劣根性
人類真是矛盾的綜合體啊～
而歷史的悲劇也往往是這樣誕生的...........
[m [1;35m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 203.67.126.174] [m
尚未認證通過
我是很多種開發工具的使用者，嘗試者，每一種開發工具都
有其優缺點。
不過，我的確用BCB寫了超過四萬行的程式，我想BCB的穩定性
與便利性是可以肯定的。
不過去比較開發工具是一種參考性的思考，只要熟悉，我想任何
工具都是好的。我自己也曾用SDK寫了Socket程式庫。
--
[m [1;35m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 163.30.20.235] [m
fisher
csviol...@bbs.tku.edu.tw (尚未認證通過) wrote:
依我來看,BCB比較像是VB.(沒有不敬的想法,純就系統觀念比較)
不妨用一個問題來取代這個主題
"VC++(+MFC) & VB 的差異"來取代比較好理解.
馮京與馬涼本來就沒高下啦,強要分高下就會失之偏頗.
宣傳上BCB是成功的.好像買來拉一拉就會是一個偉大的程式高手.
事實上,沒有一個"堪用級"的產品是可以拉來的.這也是所有的人將BCB
裝起來後只高興一個晚上的原因.
MFC+VC就恰好相反,沒有弄個七八分明白,連個唬外行人的東東也弄不成.
MicrosoftS將C定義成"windows上的組和語言"可見一般.
(舉個例,你可以用BCB隨意拉一個會畫面,然後BCB會替你找出那個地方
塞你的程式碼,但在VC+MFC上連起頭都會找不到,只能看到幾十個檔案
擺那裡----起碼你得花一個星期才能找到在那個地方可以擺上一個
hellow word!雖然它們同樣只需一行)
我的朋友中也有用BCB的人,平時也認為BCB真的比VC+MFC好,但是問到好在
那理時,我老是回一句"你真的熟MFC?",所有人全閉嘴了.(VC2.0到VC6.0的
差異相當大,VC6.0改善多了,越來越像VB,想知道BCB與VB誰較容易入手?
還是執著於傳統觀念Basic是入門級,C是高手的的刻板印像?)
只能說開發環境的比較,菜鳥在BCB比VC+MFC容易入手.
至於GUI的方便性,我覺得差距不明顯了,只是它們的操作方式不太相同而已
至於MFC沒有沒有那麼不濟,想想的Watcom c++就知道,(使用MFC,是我所用過最穩定的Complier,也是唯一在protect
mode時比較沒問題的產品,可惜
也畢業了,聽說Novell以它撰寫的)
在通向ANSI的路上MFC聲勢浩大,OWL,VCL的奇怪設計使得大家都不知道
它要怎樣爭取ANSI法(形容它像一台拼裝車比較傳神些)
BCB主管是不是去MS我不了解,但是就以此論斷VC比不過BCB,太小看
Bill Gtes了,當年他也弄走了DEC VMS 的R&D頭子..(DEC已然由市場畢業)
(當然你也可以說是BCB的頭子,看大勢已去,所以投靠Microsoft ????)
VC早已將BCB打得滿地找牙了,不需多此一舉.
VC VB BCB 都由 NextStep 的 平台系統借來的觀念,
沒有誰領先誰---他們都是同一個父母生的啦.(或說師承相同)
(NextStep 的 Steve Job 又回到Apple當總裁了,
microsoft有Apple的交叉授權及股權,還得向BCB借將?)
至於相容性,我每次拿到新版時總會罵上得好一陣子(不知道Bill Gates
耳朵癢不癢?)別相信他們的說法.不然會死得很慘.....
我使用VC(雖然我古代用BC)基於:
1.它強迫我非從頭下功夫不可,(雖然很累人)
2.我怕BCB會從市場消失(如果那你知道他們的主力是delphi,
好大一堆都是OEM來的---不是BCB原生的...)
3.寫一些亂七八蹧的東東時資料比較如容易取得(有時copy就行了,
尤其是買原始碼時,不必先包裝成OCX或DLL,就可以直接括括樂)
=====================================================
Powered by http://webnews.seeder.net
<!Poster:fis...@seeder.net mail.seeder.net>
fisher
黃金體驗
> 我的朋友中也有用BCB的人,平時也認為BCB真的比VC+MFC好,但是問到好在
> 那理時,我老是回一句"你真的熟MFC?",所有人全閉嘴了.(VC2.0到VC6.0的
> 差異相當大,VC6.0改善多了,越來越像VB,想知道BCB與VB誰較容易入手?
BCB 也可以寫SDK 也可以用MFC
你以為BCB 代表只能拉一拉，VC代表VC+MFC嗎？
我想沒這麼單純吧
VC6 像VB ？不這麼覺得耶
MFC 的確比SDK輕鬆許多
但還不算是VCL
所以VC++ 的visual 名不符實
你一方面說VC 比較紮實(因為難學，需要用SDK or MFC)
另一方面說VC++ 好用多了(因為MFC 比SDK好用)
我想BCB 也可以用SDK 跟MFC(一樣可以紮實，只是他不強迫你用)
另一方面視覺化設計，也就是你說的拉一拉，比VC 好用多了
這樣說來...
VC 把困難的事(SDK) 變簡單了(MFC)
BCB把困難的事(SDK) 變更更簡單了(VCL)
你說誰比較厲害？
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: sun1000.cc.NCTU.edu.tw
尚未認證通過
《 在 fisher. 的大作中提到: 》
: 依我來看,BCB比較像是VB.(沒有不敬的想法,純就系統觀念比較)
: 不妨用一個問題來取代這個主題
: "VC++(+MFC) & VB 的差異"來取代比較好理解.
我想﹐很多使用Delphi和C++ Builder的人
都不會認為Delphi和C++ Builder會是和VB同級的程式開發工具～
因為不論是執行效率上、物件導向的特性上、Application Framework的架構等方面來看
都可以得到這樣的結論....
當然﹐這三者“看起來“都是拉一拉component就可以完成一個程式
但是在背後的延展性和威力上來說﹐可是天差地遠.....
當然啦～聽說延到明年才會推出的VB7.0將具備完整的物件導向能力
不過以目前的版本來看﹐這方面還是有很大的缺陷...
: 馮京與馬涼本來就沒高下啦,強要分高下就會失之偏頗.
: 宣傳上BCB是成功的.好像買來拉一拉就會是一個偉大的程式高手.
: 事實上,沒有一個"堪用級"的產品是可以拉來的.這也是所有的人將BCB
: 裝起來後只高興一個晚上的原因.
的確～若此用者對於SDK或物件導向沒有概念
只會拉拉Component﹐那的確是無法發揮BCB的威力的...
但我想﹐這應該不算是BCB的過錯﹐更不能說是BCB不夠威力；）
: MFC+VC就恰好相反,沒有弄個七八分明白,連個唬外行人的東東也弄不成.
: MicrosoftS將C定義成"windows上的組和語言"可見一般.
: (舉個例,你可以用BCB隨意拉一個會畫面,然後BCB會替你找出那個地方
: 塞你的程式碼,但在VC+MFC上連起頭都會找不到,只能看到幾十個檔案
: 擺那裡----起碼你得花一個星期才能找到在那個地方可以擺上一個
: hellow word!雖然它們同樣只需一行)
的確～若不先被MFC磨一磨﹐是無法進入狀況的:)
: 我的朋友中也有用BCB的人,平時也認為BCB真的比VC+MFC好,但是問到好在
: 那理時,我老是回一句"你真的熟MFC?",所有人全閉嘴了.(VC2.0到VC6.0的
: 差異相當大,VC6.0改善多了,越來越像VB,想知道BCB與VB誰較容易入手?
: 還是執著於傳統觀念Basic是入門級,C是高手的的刻板印像?)
: 只能說開發環境的比較,菜鳥在BCB比VC+MFC容易入手.
很多認為BCB只是玩具的VC Programmer
我問他們﹐你們知道VCL的架構與威力在什麼地方嗎？他們也閉嘴了..
呵呵﹐其實事情可以這樣說
根據我的經驗
喜歡用BCB的人﹐不見得很了解VCL的威力
而這些人對於MFC大概如您所說的﹐也不夠了解
使用VC的人﹐多半“被迫“要了解MFC﹐但這些人有很多也不了解VCL
對於熟悉VCL和MFC的高手來說～其實不會有太大的差異...
不少使用VC的高手﹐若只把BCB當作和VB同級的工具
只怕也對VCL不夠了解....
: 至於GUI的方便性,我覺得差距不明顯了,只是它們的操作方式不太相同而已
哦哦﹐差距不明顯？？
那BCB真的不用混了:P
: 至於MFC沒有沒有那麼不濟,想想的Watcom c++就知道,(使用MFC,是我所用過最穩定的Complier,也是唯一在protect
: mode時比較沒問題的產品,可惜
: 也畢業了,聽說Novell以它撰寫的)
: 在通向ANSI的路上MFC聲勢浩大,OWL,VCL的奇怪設計使得大家都不知道
: 它要怎樣爭取ANSI法(形容它像一台拼裝車比較傳神些)
哎哎～我可以確定您不太了解VCL...
穩定性的問題﹐多半和Compiler本身有關
應該和Application Framework比較沒關係...
再來～BCB對ANSI的相容性一向是非常優秀的～這資料網路上都可以看得到...
OWL早期在message handler上的確使用了特殊的機制（不符合C++標準﹐但卻很方便）
而Delphi延續了同樣的方法（Inprise是Pascal的龍頭﹐不必考慮相容性的問題）
但BCB則是使用和VC相同的message mapper巨集技巧
沒有什麼“奇怪的設計“...
VCL的架構以物件導向的觀點來看﹐的確是比MFC更高階與高明
也完全符合C++的標準（除了要支援component所延伸的保留字）
而低階的東西也比較有彈性﹐這也是實情
: BCB主管是不是去MS我不了解,但是就以此論斷VC比不過BCB,太小看
: Bill Gtes了,當年他也弄走了DEC VMS 的R&D頭子..(DEC已然由市場畢業)
: (當然你也可以說是BCB的頭子,看大勢已去,所以投靠Microsoft ????)
: VC早已將BCB打得滿地找牙了,不需多此一舉.
哈哈﹐您說西瓜靠大邊﹐我倒是不反對
若說是VC技術比BCB好？那倒不符合實情；）
有機會您可以去Inprise網頁﹐看看Microsoft跟Inprise license技術的相關資料
: VC VB BCB 都由 NextStep 的 平台系統借來的觀念,
: 沒有誰領先誰---他們都是同一個父母生的啦.(或說師承相同)
: (NextStep 的 Steve Job 又回到Apple當總裁了,
: microsoft有Apple的交叉授權及股權,還得向BCB借將?)
這裡的推論不夠嚴謹～
就算都是同一個父母生的
那還要看長不長進～在技術的創新上有沒有自力更生與推陳出新...
例如VB是比Delphi早出
但是卻遠不如Delphi優秀..
這不是同一個爸爸就可以交代的；）
: 至於相容性,我每次拿到新版時總會罵上得好一陣子(不知道Bill Gates
: 耳朵癢不癢?)別相信他們的說法.不然會死得很慘.....
: 我使用VC(雖然我古代用BC)基於:
: 1.它強迫我非從頭下功夫不可,(雖然很累人)
的確﹐使用BCB比教會讓人怠惰；）
但這不表BCB做不到VC所能做的事
: 2.我怕BCB會從市場消失(如果那你知道他們的主力是delphi,
: 好大一堆都是OEM來的---不是BCB原生的...)
呵呵～您太多慮了～BCB若真不成材﹐那這樣的擔心才是真的
但今天在Windows環境下還能和VC抗衡的C++ compiler﹐也只剩BCB
在微軟擁有作業系統的先天優勢與西瓜靠大邊的心態之下﹐BCB還能有一片天
必是技術有獨到之處..
: 3.寫一些亂七八蹧的東東時資料比較如容易取得(有時copy就行了,
: 尤其是買原始碼時,不必先包裝成OCX或DLL,就可以直接括括樂)
這倒是～特別是MSDN上的範例﹐只有MFC的範例...
: =====================================================
: Powered by http://webnews.seeder.net
: <!Poster:fis...@seeder.net mail.seeder.net>
: fisher
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
政治板的許多行為
正好表現出人類對於正義，道德，真理，自由，幸福的渴望
以及人類仇恨，幼稚，非理性，無知，狂妄自大的劣根性
人類真是矛盾的綜合體啊～
而歷史的悲劇也往往是這樣誕生的...........
[m [1;32m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 203.67.126.174] [m
墮落之神
> ※ 引述《fis...@seeder.net (fisher)》之銘言：
> > 我的朋友中也有用BCB的人,平時也認為BCB真的比VC+MFC好,但是問到好在
> > 那理時,我老是回一句"你真的熟MFC?",所有人全閉嘴了.(VC2.0到VC6.0的
> 你確定真的瞭解BCB嗎？
> BCB 也可以寫SDK 也可以用MFC
> 你以為BCB 代表只能拉一拉，VC代表VC+MFC嗎？
> 我想沒這麼單純吧
> VC6 像VB ？不這麼覺得耶
> MFC 的確比SDK輕鬆許多
> VC 把困難的事(SDK) 變簡單了(MFC)
> BCB把困難的事(SDK) 變更更簡單了(VCL)
> 你說誰比較厲害？
VC也好...BCB也好...工具本身是無罪的...
每個人都有自己選擇要用什麼工具的權利...
能夠用適當的工具來解決問題這才是最重要的...
不要在挑起工具之間的鬥爭...
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: ieg181.ncue.edu.tw
尚未認證通過
: > VC 把困難的事(SDK) 變簡單了(MFC)
: > BCB把困難的事(SDK) 變更更簡單了(VCL)
: > 你說誰比較厲害？
: VC也好...BCB也好...工具本身是無罪的...
: 每個人都有自己選擇要用什麼工具的權利...
: 能夠用適當的工具來解決問題這才是最重要的...
: 不要在挑起工具之間的鬥爭...
嗨～您好
您說得基本上都是非常正確的
不過我越來越懷疑大多數的人
是不是真的有客觀的評估能力來分析真正對自己有利的開發工具？？
我們常常以為大部分的人可以很客觀的分析與評估出適合的開發工具
但事實上則是不然
大多數的時候，往往是習慣、偏好甚至是盲從決定了開發工具的種類
“理想狀態“常常是不會發生的....
我自己的公司為例
很多老工程師用VC已經用習慣了
雖然他們常常在罵VC不好用
但叫他們重新學習新的開發工具
他們卻也是不願意
甚至對新的開發工具充滿偏見
（不外乎是跟著微軟走、微軟的產品在技術上一定是比較好等等）
而這樣的偏見往往沒有經過任何親身的比較與研究...
（有時反倒是學生會勇於嘗試與學習，上班族的老鳥則不然）
工具本身的確談不上有罪沒罪
但是客觀的比較不是不能談得.....
又如
我的上司是一個非常開明與厲害的角色
他沒用過VB，也沒用過Delphi和BCB
但他就是覺得只有VC是成熟穩重的開發工具
而他也承認，這種觀點“是一種感覺與未經驗證的認知“
他只用過VC，他也沒時間與強烈的意願去研究BCB
很明顯的，就算某個專案用BCB開發會比較有效率
但他根本沒有辦法客觀的評估出選擇什麼開發工具是最有利了...
他會直覺的選擇使用VC，就算比較多的成本也不會改變他的認知與決定..
人總是抗拒新的事物，而偏安於熟悉與舊有的事物
若再加上偏見～那更是無可救藥
對此，我是很悲觀的！
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
政治板的許多行為
正好表現出人類對於正義，道德，真理，自由，幸福的渴望
以及人類仇恨，幼稚，非理性，無知，狂妄自大的劣根性
人類真是矛盾的綜合體啊～
而歷史的悲劇也往往是這樣誕生的...........
[m [1;34m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 163.30.146.45] [m
幽浮
兩個都學阿
這樣就一兼二顧
摸啦阿兼洗褲~~
用兜庸~共價最~
《 在 JoJoHSU@TKU-BBS (尚未認證通過) 的大作中提到: 》
: 《 在 obj...@bbs.cs.nthu.edu.tw (墮落之神) 的大作中提到: 》
--
[m [1;32m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 163.13.93.169] [m