Cb & Vc 經典大討論

發信人: TopazY (清涼的水罐), 信區: C++Builder
標 題: Cb & Vc 經典大討論（很長的一篇文章！）?
發信站: BBS 水木清華站 (Thu Aug 31 12:26:49 2000)

查看問題及答案
序號 25 請對 Visual C++與Delphi/C++Builder之比較 一文發表看法
wenyy 來自 http://www.vchelp.net：
Visual C++與Delphi/C++Builder之比較
作者：紫雲英
[e-mail] http://jacafe.webprovider.com
如果有什麼看法，請大家在線上討論中進行討論。
寫給站長的話
“Visual C++與Delphi/C++Builder之比較”這個話題也許有些無聊，但既然網上有那麼多的人在爭論這個話題，也許這樣一篇文字也不是全無價值。我覺得你的網站”學術氣氛“比較濃，新開的聊天室裏人們也比較友好。(也許因為大家都為了同一個目標走到一起吧。^_^)我就把這篇可能有爭議的東東發給你了。本文歡迎討論，也歡迎批評，從
語言到內容。

正文

　　經常看見有朋友在CSDN等論壇發帖子問Visual C++和C++Builder這兩個重量級開
發工具孰優孰劣(更多的是問Visual C++與Delphi孰優孰劣)。本文就試圖從技術水平、易用性、穩定性、發展前景等對它們進行比較分析。

　　由於Delphi與C++Builder同為Inprise公司產品，共用集成開發介面(IDE)，而且
使用同一套VCL框架(這一點最關鍵)，它們帶的調試器、PVCS/TeamSource團隊開發支援、資料庫引擎及企業版中集成的其他高級功能等都是相同的，所以本文將其與C++Builder歸入“同一陣線”。我在網上見到一些Delphi程式師認為C++Builder與VC比較接近，這是個誤解。事實上，Delphi和C++Builder除了使用的語言不同，其餘幾乎都相同。為了避免話題轉移到C++語言與Object Pascal語言(即Delphi所用的語言)的比較，下文主要對比分析Visual C++與C++Builder。

　　首先，從它們的應用程式框架(Application Frame，有時也稱為物件框架)進行比較。Visual C++採用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫。(同樣，Delphi和C++Builder使用的VCL的概念也不僅僅是一個控制項庫。)你如果選擇了MFC，也就選擇了一種程式結構，一種編程風格。MFC早在Windows 3.x的時代就出現了，那時的Visual C++還是16位的。經過這些年的不斷補充和完善，MFC已經十分成熟。但由於原型出現得比較早，MFC相比於VCL落後了一個時代。儘管微軟對MFC的更新沒有停止，我也經常讀到持“只要Windows不過時，MFC就不會過時”之類觀點的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。如果MFC青春永駐，微軟的開發人員也不會“私自”開發出基於ATL的WTL呀。當然，WTL的地位不能和MFC比，它並不是微軟官方支持的框架，封裝的功能也相當有限。但至少也反襯出了MFC存在的不足。

　　我以為，最能體現一個應用程式框架的先進性的是它的委託模型，即對Windows消
息的封裝機制。(對Windows API的封裝就不用說了吧。大同小異，也沒什麼技術含量。如果高興，你也可以自己寫一個類庫來封裝。但對Windows消息驅動機制的封裝就不是那麼容易的了。)最自然的封裝方式是採用虛成員函數。如果要回應某個消息就重載相應的虛函數。但出乎我的意料，MFC採用的是“古老”的巨集定義方法。用巨集定義方法的好處是省去了虛函數VTable的系統開銷。(由於Windows的消息種類很多，開銷不算太小。)不過帶來的缺點就是映射不太直觀。好在較新版本VC帶的ClassWizard可以自動生成消息映射代碼，使用起來還是比較方便的。但和VCL的委託模型相比，MFC的映射方法就顯得太落後了。而C++Builder對C++語言進行了擴展，以便引入元件、事件處理、屬性等新特性。由於功夫做在編譯器級，生成的源代碼就顯得十分簡潔。但是由於擴展的非標準特性，使用VCL的C++Builder的源代碼無法被其他編譯器編譯。而MFC的功夫做在源代碼級，雖然消息映射代碼較為複雜且不直觀，但相容性非常好。只要你有MFC庫的源代碼(隨VC企業版的光碟提供)，你的MFC程式理論上用任何符合ANSI標準的編譯器均可編譯通過。C++Builder 3以上版本可以原封不動直接編譯Visual C++程式，很多人認為這是C++Builder的相容性好，實際上很大程度應歸功於MFC的相容性好。微軟辛辛苦苦用標準方法寫MFC，卻為對手製造了方便。不知他們作何感想？而因為C++Builder對語言作了擴展，VC 不能編譯C++Builder的程式。看來在這方面VC要輸給C++Builder了。而且VCL所支援的元件、屬性等都是MFC所缺乏的特性。雖然VC也能支援元件，但要通過AppWizard先生成一 個“包裹”類(wrapper)，不如VCL來得簡潔。有很多人使用C++Builder就是沖著控制項板 上那一大堆元件來的，VC雖然能使用的元件也很多(也許不比C++Builder少)，但由於不 方便而對RAD程式師沒有吸引力。
　　C++Builder的VCL比Visual C++的MFC先進的另一個特性是異常處理。但令人啼笑
皆非的是，它的異常處理代碼有bug，有時會無端拋出異常。不知道在最新的版本中有沒有改正了。而VC的框架MFC也不是一無是處。經歷了那麼多年的發展和完善，MFC功能非常全面，而且十分穩定，bug很少。其中你可能遇到的bug更少。而且有第三方的專門工 具幫助你避開這些bug。如此規模的一個類庫，能做到這一點不容易。不要小看了這一點 ，很多專業程式師就是為這個選擇VC的。而C++Builder的VCL的bug就相對較多了，而且 有些它自己帶的示例程式都有錯誤。看來Inprise還有很長的路要走。

　　再從它們的易用性比較。VC有ClassWizard、SourceBrowser等一系列工具，還附
帶Visual SourceSafe、Visual Modeler等強大的工具，易用性非常好。(VC自帶建模工 具Visual Modeler，也許說明了它才是工程級的開發平臺，與C++Builder的定位不同。 )它所帶的MSDN這部“開發者的百科全書”更是讓你“沒有找不到的，只有想不到的”。 而且它的AutoComplete之類小功能也比C++Builder要體貼。C++Builder的新版本雖然也 提供了這一功能，但它的提示要等好幾秒才出來，有時你不經意間把滑鼠停在某一處， 也要等硬碟響好幾秒，這可是在566Mhz的賽揚II上呀。不要笑我瑣碎，有時一個開發工 具的成熟和易用，就是從這些小地方體現出來的。C++Builder作為RAD工具，理應強調易 用性。但與VC相比還顯出不成熟。這是不應該的。

　　再來看看它們的可攜性。Inprise正在開發C++Builder和Delphi的Linux版本，
代號為Kylix。也許通過Kylix，用VCL構架編寫的Windows程式向Linux移植成為可能。但 這只是可能。因為在目前Inprise的相容性工作做得並不好。C++Builder可以編譯VC程式 還要多謝微軟使用標準方法寫MFC，而它自己各個版本之間相容性卻不太好。低版本的C ++Builder不能使用高版本的VCL元件(這還別去說它)，而高版本的C++Builder竟然不能 使用低版本的VCL元件。真是豈有此理，我很少看見軟體有不向下相容的。如果Windows 98不能運行95的程式，Windows 95不能運行3.x的程式，Win 3.x不能運行DOS程式，你 還會用Windows嗎？如果不是C++Builder的其他某些方面太出色，光是這個向下不相容就
足以讓我拋棄它。而且雖說通過捆綁編譯器，C++Builder可以編譯Delphi的Object Pascal代碼，但C++Builder仍不能使用為Delphi開發的VCL元件。所以一個元件有for D1/D2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著C++Builder版本的升級可能還會增加。希望Inprise能先解決同門兄弟的相容性問題。而微軟的VC就沒有這類問題 。MFC1.0的程式也可以毫無障礙地在VC6.0下編譯通過。

　　再來看看它們的前景吧。實際上，技術的進步在很多時候是此消彼長的。當初Bo
rland的Turbo C和Borland C++幾乎是唯一的選擇。微軟的Quick C(現在還有人知道這個產品嗎？)和Microsoft C/C++從來也沒有成為過主流。但Borland C++又流行了多少年呢 ？不久就被新崛起的Microsoft Visual C/C++壓下去了。現在的C++Builder又有後來居 上的態勢，如果穩定性再提高一些，bug再少一些，有希望成為主流。但Inprise的總體 實力不及微軟，這也是無可爭議的。從C++Builder 5的Release Notes中的Known Issue s部分，以及它們的幫助文檔的規模和質量都可以看出。(哪個同類產品的幫助文檔能和 MSDN比呢？)Inprise公司應從Netscape吸取教訓，不要讓C++Builder成為第二個Netsca pe Communicator。(Communicator也是一度技術領先，甚至曾佔據了大部分的流覽器市 場，但似乎後勁不足，而且 6.0 PR1、2中bug多多，現在被IE壓得抬不起頭。)C++Buil der是Inprise的旗艦產品之一，前景應當還是比較樂觀的，而且Inprise已經在向Linux 進軍了，而微軟還遲遲沒有動作，難道非要到Linux成燎原之勢(或許已經成燎原之勢了)才會奮起佔領這個新興市場？似乎他們對Linux的態度與幾年前對互聯網的興起的反應 遲緩有些相似。但後來……唉，真希望Inprise不要步Netscape的後塵。C++Builder是 一個很有前途的開發工具。遺憾的是，Inprise公司Delphi的創始人已經跳槽到微軟去主 持Visual J++專案了。但願對Inprise衝擊不會太大。微軟的Visual C++的前景又怎樣呢
？Visual Studio 7.0不久就要推出了。不知能不能在保持穩定性的同時在技術的先進性 上趕上C++Builder。另外，這一版本將加強網路開發的特性。看來微軟雖然被判解體， 開發實力可是一點沒打折扣。

　　就技術(主要指應用框架)來說，C++Builder目前領先於Visual C++。但多多少少
的不盡人意之處讓我對Inprise“想說愛你不容易”。而VC儘管發展到今日已十分完善， 但MFC框架已是明日黃花了。如果不使用MFC，目前又沒有合適的替代品。WFC是支援元件 、屬性和事件的，但那是Visual J++裏邊用的；ATL也很先進，但是用來進行COM/Activ eX開發的；基於ATL的WTL也不錯，可惜是非官方作品，也未必比VCL先進。微軟最近提出 了C#(讀作C Sharp)語言方案，但那屬於和Java同一類的東西。看來是金無足赤啊。根據
你的需要做選擇吧。實際上Visual C++和C++Builder也不是單單競爭關係。它們在許多 領域並不重疊，甚至是互補的。到底怎樣取捨，要根據你的專案特性決定。如果你開發 系統底層的東西，需要極好的相容性和穩定性，選Visual C++吧。你可以只調用Window s的各種API，不用MFC。如果你寫傳統的Windows桌面應用程式，Visual C++的MFC框架是 “正統”的選擇。如果你為企業開發資料庫、資訊管理系統等高層應用(“高層”是相對 於“低層/底層”而言的，不是說技術高級或低級。)而且有比較緊的期限限制，選C++B uilder比較好。如果你用的語言是Object Pascal，Delphi是唯一的選擇(如果GNU Pasc al等免費編譯器不考慮的話)。如果你原先用Delphi(Object Pascal語言)，現在想改學 C++，應當先用C++Builder。熟悉的介面和相同的框架會讓你的轉軌事半功倍。

　　另外，雖說MFC已顯落後，但不是說它不值得學。事實上，不學MFC就等於沒學VC
。利用MFC框架開發程式仍然是目前開發桌面應用的主流模式，而且還會保持相當長的時 間。即使你不使用MFC框架，花點時間學習一下MFC的封裝機制對你熟悉C++的OOP機制和 Windows底層功能也是很有好處的。

　　以上意見僅供參考。

如果有什麼看法，請大家在線上討論中進行討論。 　

惡魔吹著笛子來 來自 蒼天已死,黃天當立–c/c++的時代正在淡去 ：

不要以為這個題目是聳人聽聞,但就目前的形勢來看c/c++是需要退出舞臺或者說的婉
轉一點是需要更新換代了.

我想在未來的一兩年裏,作為程式師等級評判的標準之一c/c++(不管是mfc還是bcb)將
會讓位給三種編程語言,1.sun的java2.windows平臺上的c#3.xml

為什麼這麼說呢,我認為最大理由是目前的應用程式正在從基於獨立的作業系統,傳向
基於internet平臺.

我們以前開發應用程式都是依賴於平臺的功能調用,mfc,bcb都是這樣.而現在日益火熱
的internet編程卻最不想關心的就是某一個平臺的調用,譬如說要實現b2b的電子商務那麼就需要做不同平臺的集成,如果我是程式師我最care的就是如何實現商務邏輯

而不是各種平臺之間的通信和管理.那麼我們最迫切需要的就是一種與各種平臺調用無
關的語言,這中語言只注重程式邏輯的設計而不涉及平臺的調用.而我們熟悉的c/c++卻恰 恰不是為這個而設計的(赫赫這也不能怪c/c++在70年代誰能知道現在internet的情況呢 ).c/c++的最初設計目的是為了設計unix產生一種介於彙編和高階語言之間的一種開發高 效而性能不低的語言.他要比其他任何高階語言都要關心系統的物理結構,譬如一直是毀 譽攙半的指針.指標之所以強大就是應為涉及了系統實體記憶體的管理.他可以使得程式師 和系統之間成為一種半透明狀態.但是就是這種半透明的狀態讓指標帶來了更多的不穩定 性.

c/c++在面向Internet的編程中卻無任何優勢可言.跨平臺的電子商務軟體最害怕顧及
各種平臺之間的天差地別的系統調用,最害怕時不時的由於記憶體洩漏而crash.c/c++的優 勢在這裏卻成為了劣勢.即使在windows平臺上開發基於windows dna的solution

用的最多的還是vb做的dcom而不是vc的atl做的dcom,因為c/c++雖然高效但是太容易

出錯,如果不是很小心的釋放記憶體nt很快就會資源不足.

java就是最先看到這種情況,他用jvm實現了平臺無關用記憶體回收實現了穩定健壯.但是
相當多的c/c++程式師抱怨java太慢了.的確即使到java2速度仍然是一個大問題.我曾經 是一個c/c++堅決擁護者在許多論壇裏和java程式師打筆仗.但是我逐漸意識到面對與in ternet平臺而不是特定的作業系統的時候java的速度問題往往是一個小小的瑕疵.我們可 以想像那一個電子商務網站會用我們手頭的pc做伺服器,他們不是sun的e1000就是ibm的 risc6000.在這種平臺上java這點速度問題只是a peice of cake.程式師只需要專注與商 務邏輯的編程,而不必要關心陣列是否越界,物件記憶體是否釋放更不需要關心是不是unix 和windows的系統調用不一樣.

微軟的c#可以說是一種java與c/c++的雜合體,他可以回收記憶體,可以平臺無關.但是

他又可以實現一些java沒有的功能譬如在標記的程式段內用指標自己管理記憶體,可以實
現操作符的重載等等.為什麼要這樣做我想也許c#還肩負了一定的面向作業系統開發的任 務例如winform.他基本上的思想和java類似,但是實現的方法又不一樣他不通過jvm解釋 中間代碼,而是吧源代碼編譯成p代碼然後通過CLS庫和JIT在平臺上及時編譯為100%的本 地代碼來執行.他的pe代碼是獨立於平臺的,但是cls和jit卻根據不同的平臺而設計.因此 c#的平臺獨立有點類似於c/c++在不同平臺上的移植使得c#比java來的更快.而且微軟還 許諾cls和jit不僅針對c#還可以針對任何語言譬如pascal,smaltalk,basic因此將來有可 能所有的編程語言都是可以平臺無關的(ms真是毒,所有的語言都平臺無關java還有什麼 優勢呢,據說ms正在開發基於pascal smaltalk的asp+).

xml很多人可能認為與html相類似的語言和c/c++,java,c#完全不在一個檔次上的語言
.其實不然.我們知道不管是c#還是java都是通過統一地層計算來實現平臺無關.那就必須 在性能上付出一點代價.而xml卻能夠實現不同的語言之間的調用.譬如說一個網佔用jav a用bean實現一個出貨功能,另一個網站用dcom實現一個入庫功能 .如果這個網站需要實 現b2b,用一般的方式就是在他們之間寫轉換程式.而xml通過標記語言來描述各自的藉口 特性.兩端通過解析xml文本來實現互相的調用,無需任何中間轉換程式

只要一張xml文本就能實現bean和dcom之間的通訊(要說清楚其中的機理,需要很多xml
概念如果有興趣可以到msdn.microsoft.com/xml或者www.s3c.org去看看).目前ms的.net中最核心的技術soap就是完全基於xml的遠程序呼叫.

介紹了那麼多可能有點跑題,其實我最想說的就是21世紀的程式師應該從面向作業系統
的傳統方法中走出來,學習一點如何面向Internet平臺編程的技術和概念.不要在無畏的 那種c/c++工具好之類的地方爭論.我想不出一兩年不管是bcb還是mfc都要淘汰,

到那個時候要爭論的不是bcb好還是mfc好而是c#好還是java好.至於xml那是不管sun和 ms以至於世界任何大的IT公司包括Intel,hp都在奮力研究的技術,不學習可能就要被淘汰 .至於c/c++可能就會淪落到現在彙編的地位在某些系統效能敏感的地方還能見得到.

如果是編程語言的初學者那麼我建議學習java同時關注c#,他們首先比c/c++簡單沒有
複雜的宏,指標,摸版等等讓人摸不招頭腦的概念.而且是完全面向物件,比c/c++的半調子 面向物件清楚的多好學的多.(我推薦目前學習java,畢竟c#還沒有發佈而且剛發佈的beta版的編譯器要求高的嚇人需要win2000 adv server沒有128M記憶體的別想跑.話說回來c# 和java一摸一樣沒有什麼太大的區別學好了java將來的c#將會信手拈來)

對於目前的windows下的編程者來說學習mfc的價值還是有一點的但是不是太大.至少可
以熟悉windows內在機理.但是我還是推薦關注一下c#將來的windows.net都是基於c#而不是mfc.而且c#要比mfc簡單的多實現一個同樣的windows桌面應用c#的開發速度是mfc的兩到三倍而且幾乎看不見性能的損失. visual studio 7.0中 vc將是一個次要的開發工具 最主要的開發工具就是c#和vb7.0.至於borland我想是不可能不跟著ms走至少windows平 臺上是這樣說不定明年就有一個c# builder出來作為borland的主打產品而不是c++builder了.說一句玩笑話wenny說不定很快會把這裏變成www.c#help.net了

zhangxiuyong 來自 http://www.ucancode.com ：

其實我認為，對於Visual C++本身的理解不是向你上面談到的那麼簡單，Microsoft
在開發Visual C++的時候是希望為其開發人員提供一個可靠的開發平臺，便於用戶可以
為Windows上面編寫各個方面應用程式，包括：資料庫應用程式，硬體驅動程式，網路程
序，多媒體程式，遊戲程式等等方方面面，試想如果一個開發平臺要同時完成這麼多個
方面的開發任務，是需要考慮多少的問題，因此Visual C++在設計的時候就考慮了提供
一套類庫而不是直接提供黑匣子式的開發元件來完成開發任務，提供的類庫MFC具有很靈
活的設計結構，以及良好的繼承性，同時配合DVS文擋視圖結構來組織程式開發，雖然我
們承認利用VC開發程式（資料庫方面的程式）沒有其他的RAD開發工具來的快，但是如果
你真正利用VC來開發的話，你會覺得你不會去選用其他的開發工具的，對了各位聽說個
多少開發人員是從VC熟練的開發師轉向VB,Dephi的開發工具的嗎，當然DVS結構本身也有
其很大的弱點，如很難重用。同時在CView中再嵌套CView的變得不可能。不過對於開發
中小型的程式（代碼在50萬行以內的程式卻是可以的了）。對於特大型的程式我想最好
可以借鑒一種新的技術叫做MVC的開發技術來組織你的程式吧。好了各位此些文字，僅代
表個人之言，如果各位感興趣可以到:http://www.ucancode.com上面看看。

zhangxiuyong 來自 http://www.ucancode.com ：

其實我認為，對於Visual C++本身的理解不是向你上面談到的那麼簡單，Microsoft
在開發Visual C++的時候是希望為其開發人員提供一個可靠的開發平臺，便於用戶可以
為Windows上面編寫各個方面應用程式，包括：資料庫應用程式，硬體驅動程式，網路程
序，多媒體程式，遊戲程式等等方方面面，試想如果一個開發平臺要同時完成這麼多個
方面的開發任務，是需要考慮多少的問題，因此Visual C++在設計的時候就考慮了提供
一套類庫而不是直接提供黑匣子式的開發元件來完成開發任務，提供的類庫MFC具有很靈
活的設計結構，以及良好的繼承性，同時配合DVS文擋視圖結構來組織程式開發，雖然我
們承認利用VC開發程式（資料庫方面的程式）沒有其他的RAD開發工具來的快，但是如果
你真正利用VC來開發的話，你會覺得你不會去選用其他的開發工具的，對了各位聽說個
多少開發人員是從VC熟練的開發師轉向VB,Dephi的開發工具的嗎，當然DVS結構本身也有
其很大的弱點，如很難重用。同時在CView中再嵌套CView的變得不可能。不過對於開發
中小型的程式（代碼在50萬行以內的程式卻是可以的了）。對於特大型的程式我想最好
可以借鑒一種新的技術叫做MVC的開發技術來組織你的程式吧。好了各位此些文字，僅代
表個人之言，如果各位感興趣可以到:http://www.ucancode.com上面看看。

zhangxiuyong 來自 http://www.ucancode.com ：

其實我認為，對於Visual C++本身的理解不是向你上面談到的那麼簡單，Microsoft
在開發Visual C++的時候是希望為其開發人員提供一個可靠的開發平臺，便於用戶可以
為Windows上面編寫各個方面應用程式，包括：資料庫應用程式，硬體驅動程式，網路程
序，多媒體程式，遊戲程式等等方方面面，試想如果一個開發平臺要同時完成這麼多個
方面的開發任務，是需要考慮多少的問題，因此Visual C++在設計的時候就考慮了提供
一套類庫而不是直接提供黑匣子式的開發元件來完成開發任務，提供的類庫MFC具有很靈
活的設計結構，以及良好的繼承性，同時配合DVS文擋視圖結構來組織程式開發，雖然我
們承認利用VC開發程式（資料庫方面的程式）沒有其他的RAD開發工具來的快，但是如果
你真正利用VC來開發的話，你會覺得你不會去選用其他的開發工具的，對了各位聽說個
多少開發人員是從VC熟練的開發師轉向VB,Dephi的開發工具的嗎，當然DVS結構本身也有
其很大的弱點，如很難重用。同時在CView中再嵌套CView的變得不可能。不過對於開發
中小型的程式（代碼在50萬行以內的程式卻是可以的了）。對於特大型的程式我想最好
可以借鑒一種新的技術叫做MVC的開發技術來組織你的程式吧。好了各位此些文字，僅代
表個人之言，如果各位感興趣可以到:http://www.ucancode.com上面看看。

wenyy 來自 http://www.vchelp.net ：

我一定程度上同意 惡魔吹著笛子來 的說法，

畢竟VC開發速度是比較慢的，

而且硬體速度的大規模提升也為使用JAVA開闢了道路，

不過microsoft.net的目的是一定程度上改變MS的經營性質，和開發關係不是很大，但
是MS的一貫方針都是在平臺上為開發人員提供方便，

所以C#是為了.net服務的。

此外我想我沒有精力再搞個c#help.net了。:-P

果子 來自 http:// ：

“惡魔吹著笛子來”是比較“前衛”的一類程式師。我就聽業界的人多次說過JAVA也是

個吹得很響的東西，但實際如何，大家都看得見。至於認為C/C++開發工具（VC，

BCB等）會在一兩年內退出市場，就是無稽之談了。

Wesley 來自 http:// ：

惡魔吹著笛子來，你的觀點很有啟發性。能不能寫一篇或推薦一篇剖析、比較Java開
發工具的文章？比如Visual J++, JBuilder，以及Symantec和IBM的對應工具。(可能和
本站的初衷有些不合^o^)

LeoCN 來自 http:// ：

It’s not a time for us to determine which language will more better!

in factly,In China,too many corporation just writting some codes for

enterprise’s MIS,OA,ERP or other application.It do not need so speed

and do not need so good original code. just want more data,more easy and m
ore quickly.

so c++ is not a choice in such enviroment. and u know,many codes we write
today will be useless.and there r so many easy tools such as VB

for windows designer, Developer/2000 or PB for database,Domino Designer fo
r OA application,why c++???

in DOS mode. i like Turbo c2.0, with it and MASM i can do everything.

but now i hate c++, it has waste my time! my corporation do not need

c++,just need java,xml,php,pb,vb,delphi,developer/2000,domino designer etc
.

so, a tool is just a tool,if the advantages in some aspect of the tool

u needed. it’s will be a good tool for u. others it can bring u unfortunat
ly!

惡魔吹著笛子來 來自 ：

果子,國內的Java應用不到10%基本上是ms的天下.這些可能是由於中國軟體業規模太小
的緣故.而在國外40%的商務系統的開發都是Java,c/c++不到10%.譬如BEA公司一個有3個
java程式師創立的公司開發了第一個基於J2EE的Application Server—weblogic.BEA公
司依靠weblogic在短短4年裏成為世界第四大軟體公司僅次於CA公司.可見JAVA的功能是
如何的強大.微軟的.NET的負責人說,你們想要知道.NET是什麼樣子,那就去看看JAVA.JA
VA是什麼樣子.NET就是什麼樣子.

惡魔吹著笛子來 來自 http:// ：

Wesley你好.關於Java開發工具的問題.從我的觀點來看,目前的Java開發工具沒有一個
令人滿意的.最主要的是,在技術上考慮的太多,卻不像MS的開發工具考慮到程式師的方便
(vj++是另外一會事情我後面會講).

基本上流行的是sun的jdk,ibm的visual age for jave,samtic 的visual cafe,和bor
land的jbuilder(vj++基本上沒有什麼人用).

在這幾個工具來講,jdk是老大哥,但是僅僅是一個command line compile.在某些方面
用ultreditor+jdk會比較方便,譬如你的機器的配置比較的低(memory<64M).一般來說,幾
乎所有的Java工具需要的機器配置都比較高.

visual cafe是第一個可以使用的Java IDE工具,我當初學習Java的時候就是用這個.它
的配置要求比較低.一些比較低的版本譬如1.5 2.032M就可以使用了.但是現在最新的版
本5.0的要求就比較高了,可惜2.0以後的版本沒有用過.cafe的IDE開發也不是很方便,懂
一個視窗西一個視窗比較的亂.而且bug還很多.有的時候trace到一定的地方

就會crash.samtic是一個系統安全公司不知道為什麼cafe卻那麼不穩定.而且從技術上
來說到目前為止還沒有完全支持java2.更不要說j2ee了.從幫助來說cafe的幫助基本上還
是jdk的幫助沒有什麼特別的地方.

IBM的東西往往是吹的比做的好.visual age很複雜功能也很多.支持100%pure Java和
J2EE.但是使用起來不方便,當初為了設一個class path找了半天的help都沒有結果.後來
聽別人說要在nt下面設置環境變數才能成功.而且與其說是visual age還不如說是comma
nd line套了一個windows殼子.做application還要自己寫layout代碼更本就不visual.

Jbuilder是我目前遇到最好的一個,它的介面基本上和delphi c++duilder差不多.他是
第一個真正的java的rad系統,第一個全面支援j2ee 13項Java技術的工具(bean,jsp,rmi
都實現了).100%的pure Java.相當全面的help document.

但是他最大的缺點是系統要求實在高,沒有128M別想用.64M下麵慢的像烏龜,help更本
不能開(它的help都是java寫的64m下面打開help慢的能夠看到一格一格awt畫視窗的過程
).但是不管怎麼說他是一個比較理想的系統.

至於visual j++.MS更本不是想用他來打開java市場,而是想用他來分裂java.從很大程
度上來說vj是一個windows 程式的java開發工具他不是100%的pure java.在windows平臺
上他是最visual的.用他開發application,你不必用複雜的layout,只要像vb一樣填寫坐
標,而且開發的windows程式速度很快完全100%的本地代碼.你可以把它看成java版的vb.
他的wfc庫僅僅在windows上能夠用,而且使java和com捆在一起.他自己開發jvm,java庫.
但是ms污染java的策略相當的成功,不僅把java逼的走投無路還在法庭上贏了sun的java
官司.因此ms的目的一達倒就把vj便賣給另一個公司而且隨著c#得開發和得不到sun的j2
ee的許可我想ms不會再開發任何關於java的工具.如果你開發java的同時還想使用ms下的
com,ado那麼vj可以適合你的需要.

chenxiqi 來自 http://[e-mail] ：

VC++開發資料庫軟體確實比較慢，可有許多軟體只能用C/C++來開發，如果VC++退出曆
史舞臺，那豈不是說只有資料庫軟體才叫軟體,我想世界不會如此單一。

zhangxiuyong 能告訴我什麼是MVC的開發技術嗎

惡魔吹著笛子來 來自 ：

什麼樣的的軟體只能用c/c++開發?

作業系統?apple的OS7,os8,os9都是PASCAL開發的.

資料庫?oracle8i就是JAVA開發的

遊戲?你也許沒有見過用DELPHI開發的< 笑傲江湖>< 風雲>,甚至有VB開發的< 神龍教>

同時VB7.0全面支持direx8.0.可想而知遊戲的難度會大大的降低吧.

MVC=Model, View, Controller Design Pattern

惡魔吹著笛子來 來自 ：

什麼樣的的軟體只能用c/c++開發?

作業系統?apple的OS7,os8,os9都是PASCAL開發的.

資料庫?oracle8i就是JAVA開發的

遊戲?你也許沒有見過用DELPHI開發的< 笑傲江湖>< 風雲>,甚至有VB開發的< 神龍教>

同時VB7.0全面支持direx8.0.可想而知遊戲的開發難度會大大的降低吧.

我的意思不是說c/c++會消失而是應用的範圍將會大大的降低並且將會進行脫胎換骨的
升級(用了20幾年升升級總可以吧,java的升級不算太成功,但是是一個不錯的先例我想c
#的前景會更好).

BTW:

MVC=Model, View, Controller Design Pattern

xubin 來自 http:// ：

在工業控制中，直接對I/O位址操作，就要用C++。

惡魔吹著笛子來 來自 ：

俺有一個同學畢業設計用VB做單片機。你這不是在討論問題是在抬杠。

wenyy 來自 http://www.vchelp.net ：

我想一種語言並不會因為其他語言的出現而消失，

比如說c與C++，C++與C#的關係。

所以我想討論問題時首先是要排除敵視，

然後才是透徹的分析。

IT世界不光只有網路，還有其他很多。

所以某些工具在一定範圍內適用是正常的，

其實在國外，

SERVER端軟體大都用JAVA，而CLIENT卻沒有多少用JAVA，

這和速度有關，當然也與MS對JAVA的態度有關。

不過我一直認為C/C++不會因為JAVA的出現而消失。

就象COBOL目前為止還在使用一樣，

不過以後會有愈來愈多的解釋性語言出現，因為解釋語言比編譯語言的相容性好，這
是不得不承認的。

惡魔吹著笛子來 來自 http:// ：

是的wenny.也許我說c/c++的消失有點誇張化了,但是實事求是的說.java和c#的出現

c/c++的升級換代是在所難免的.對麼.

惡魔吹著笛子來 來自 http:// ：

而且我一直認為java和c#不是另外一種語言而是c++的升級.就像是c到c++的升級一樣
.對不對.

xcc 來自 http:// ：

同意惡魔吹著笛子，你簡直是我的偶像,順便貼一篇關於C#和.NET專訪

NET and C# Questions with Jeffrey Richter

In the weeks after Microsoft made a huge splash in the development communi
ty with their .NET and C# announcments at the July 2000 PDC, Jeffrey Richter
accepted our request to field 20 questions from our readers about these new
technologies. As many of you already know, Jeffrey is a cofounder of Wintel
lect, a company that specializes in Windows & Microsoft.Net training and deb
ugging. Jeff is also a consultant at Microsoft working on the Microsoft.NET
Common Runtime Language (CLR) team in which C# and Visual Basic 7 applicatio
ns operate. Below are the 20 most popular questions that were sent in and Je
ffrey’s responses.

For Visual C++ developers everywhere still trying to get a handle on all t
his: Thanks Jeff!!

Question #1 Is .NET a runtime service or a development platform?

Answer It’s both and actually a lot more. Microsoft .NET is a company-wide
initiative. It includes a new way of delivering software and services to bu
sinesses and consumers. A part of Microsoft.NET is the .NET Frameworks. The
frameworks is the first part of the MS.NET initiate to ship and it was given
out to attendees at the PDC in July. The .NET frameworks consists of two pa
rts: the .NET common language runtime and the .NET class library. These two
components are packaged together into the .NET Frameworks SDK which will be
available for free download from Microsoft’s MSDN web site later this month.
In addition, the SDK also includes command-line compilers for C#, C++, JScr
ipt, and VB. You use these compilers to build applications and components. T
hese components require the runtime to execute so this is a development plat
form. When Visual Studio.NET ships, it will include the .NET SDK and a GUI e
ditor, wizards, tools, and a slew of other things. However, Visual Studio.NE
T is NOT required to build .NET applications.

Question #2 How likely it is for C# to become a general-purpose (meaning:
not MS-specific) language and if so, have any other vendors committed to pro
viding compilers on any non-Windows platforms?

Answer It’s hard to answer this right now. I have been programming in C# a
lmost exclusively for about the past year and I love it. It only took me a f
ew days to learn most of it since it is very similar to C++. It was designed
to compliment the common language runtime and I think that it’s unlikely to
gain much momentum if decoupled from the runtime. However, you never know.
Microsoft is submitting C# to the ECMA standards body so any company will ea
sily be able to produce their own C# compiler however, without a runtime, th
e compiler itself is not that useful. I’m not aware of any companies current
ly working on their own C# compiler. Certainly, porting the runtime to anoth
er OS is no small undertaking.

Question #3 Can you tell us specific practical problems that C# can fix be
tter than Java?

Answer I must be honest with you: I have never programmed in Java. I know
what C# offers the C/C++ programmer: simpler syntax, components that seamles
sly fit together, type safety, and so on. Other people should be able to add
ress the C# < -> Java comparison.

Question #4 Will ADO+ be the preferred and most efficient method to access
databases from C# or will it have it own (or .NET) class wrappers for the O
LEDB API?

Answer The .NET class library includes a System.Data namespace with many t
ypes for database access. These wrappers will be the best (and most efficien
t) way for a C# programmer to access data.

Question #5 Can C# be used to develop Windows applications or is it soley
used for developing distributed applications?

Answer C# can absolutely be used to develop classic-style Windows applicat
ions. Actually, this is more a function of the runtime, not the language. So
, the runtime supports console apps, GUI applications, NT Service applicatio
ns, simple components which can be used in applications, web pages and so on
. You can’t write a device driver but that’s about all I can think of that t
he runtime doesn’t support.

Question #6 What is the C# relationship to WinForms?

Answer Win Forms is a set of classes in the .NET class library that wrap W
in32 windows, brushes, pens, etc. Any language targeting the runtime (includ
ing C#) can construct instances of these types and manipulate them. This is
how you would create an app like Notepad, Calc, or Wordpad. I know that Win
Forms has similarity to J++’s WFC library but I also know that there have be
en some major changes.

Question #7 Rumor has it that the C# language has been submitted to the EC
MA for ratification. Is this true and what impact do you see that having on
other companies adopting it as a general language (such as C and C++)?

Answer Yes, it is true. I pretty much answered this in question 2.

Question #8 Which will be the role of ATL and COM in the new .NET technolo
gies?

Answer The .NET frameworks offers a replacement for many existing librarie
s, like ATL, MFC, C runtime library, standard template library and so on. .N
ET programming is significantly easier than using any of these older technol
ogies. For this reason, I suspect many developers will move away from using
the older technologies. The older technologies can buy you performance howev
er; so, some people that are very concerned about this will stick with what’
s around. As for COM, developing components with .NET is orders of magnitude
easier and the interoperation between components pretty much happens for fr
ee. Again performance may be an issue for some. And, for the time being COM+
services, like transactions, are not being offered directly to .NET code. Y
ou can still access these COM+ services but .NET code must incur an interope
rability transition, which translates to a performance hit.

Question #9 Why was the templates feature not carried over from C++ to C#?

Answer Again, this is more of a runtime issue than a C# issue. First, temp
lates are difficult to implement and Microsoft choose not to do the work for
Version 1 of the product. They may do templates or something similar in fut
ure versions. Second, since the runtime is a multi-language runtime, introdu
cing templates means that all languages targeting the runtime would be requi
red to support templates in some form. There are a lot of issues here that n
eed to be carefully considered.

Question #10 Will C# replace the pseudo keywords that clutter ATL COM code
with real keywords? Examples: OLE_COLOR, BOOL, VARIANT_BOOL, and DISPID_XXX
XXX.

Answer Absolutely, all types have new names as provided by the .NET class
library.

Question #11 We’ve seen managed extensions, but aside from that, what futu
re does C++ have at MS and in .NET?

Answer C++ is unique in that it is the only Microsoft language that allows
the developer to write managed and unmanaged code. So, I can easily see dev
elopers writing in unmanaged C++ for performance-critical algorithms and the
n using managed C++ for type-safety and component interoperability. I’m sure
Microsoft will keep C++ going for years to come: device drivers need it, Wi
ndows is built with it, SQL Server< Exchange, and other BackOffice products
will probably use C++ for a long, long time.

Question #12 If .NET supports ActiveX/COM, how will security be assured if
a C# application runs from within a browser?

Answer The .NET runtime offers code access security, which allows an admin
istrator/user to configure security based on code identify. By default, any
code downloaded via the Internet or intranet is untrusted and will not be ab
le to access files and other resources. In fact, when I build a console appl
ication and run it from a network share, I get an exception when it tries to
access certain resources. If I copy the same file to a local disk directory
and run it, it runs fine. Code access security is integrated with the runti
me and is too deep a subject to cover here.

Question #13 With regards to the .NET runtime, do I need it on the machine
that I deploy C# apps on?

Answer Yes. All managed apps need a manager; the runtime is the manager. M
icrosoft will eventually package the runtime so that it is freely redistribu
ted. For now, end-users will have to install the full .NET SDK from MSDN web
site (when available). This is similar to how VB developer must ship the VB
runtime today.

Question #14 There has been mention of being able to derive C# classes fro
m VB classes. Is this true and where can we see an example of how to do this
?

Answer This is true. In fact, any language that targets the runtime can de
rive from any type created in another language. Also, the Visual Studio debu
gger fully supports debugging across languages. Each entry in the call stack
window shows the function on the stack and the language that the function w
as written in. This is very cool and got a round of spontaneous applause whe
n shown at the PDC. There are samples in the .NET SDK that demonstrate how t
o do this. It’s really quite simple. Actually it just happens, there is noth
ing for you to do. You can also throw exception across language boundaries a
s well for error handling.

Question #15 Can I derive a C# class from a C++ class? If so, how?

Answer Same as the answer above: Any managed language can inherit from a t
ype in another other managed language. If you use native C++, then you can’t
do this, however.

Question #16 Will the new version of MFC have the option of working in a m
anaged environment?

Answer I haven’t been tracking the new version of MFC but I’m pretty sure
the answer is no. MFC is all unmanaged just like it has always been. For man
aged applications, Win Forms is the window manager that people should use.

Question #17 If the new version of MFC will operate in a managed environme
nt, will it have the option of building desktop Win32 apps and not needing .
NET runtime support?

Answer I’m pretty sure MFC is unmanaged and will never require the runtime
.

Question #18 Stroustrup has been quoted as saying “I have not expressed a
technical opinion on C#, and I don’t plan to do so. C# is yet another propri
etary language specialized for Microsoft’s Windows system.” Do you agree or
do you think C# is more of a generic language open to other platforms?

Answer C# is a language designed for the common language runtime; not Wind
ows. The CLR can be ported to other operating system like Linux and Solaris
and if the CLR is there, then C# will probably be there as well. In the gran
d scheme of things, C# is not that important or interesting. It is a syntax
checker that spits out intermediate language consumable by the runtime. You
can love C# or hate C# - your choice. I happen to love it and think is the b
est programming language for the types of applications I write.

Question #19 I heard a rumor that VB7 will allow static linking of the run
time, like MFC. Is there any truth in this? If so, will C# also be able to c
reate standalone apps?

Answer This is absolutely not true. No language will able to statically li
nk to the runtime.

Question #20 Does C# still use resource files? If not, what mechanism is p
rovided to allow for localization?

Answer The .NET frameworks designers have created a new resource model. Re
sources can be embedded in EXE or DLL files the way Win32 resources are or r
esources files can now be stand-alone files like a single jpg or bmp file. T
here is also the concept of fall-back cultures. If the Swiss German resource
can’t be found, the runtime looks for the German resource. If the German re
source can’t be fond, it looks for the “default” resource. Each language wil
l typically be built and shipped as a separate assembly rather than packagin
g everything up into a single file. Like code access security, a full discus
sion of the new resource model is too much to put here.

wenyy 來自 http://www.vchelp.net ：

我想應該這樣說，一種新語言的出現會在一定的功能領域上替代其他的開發語言，以
前的開發語言的使用範圍會縮小，但不會消失。（就算是出於保護現有資源的目的）

但沒有一中語言是十全十美的，

JAVA，C#都不是。

wenyy 來自 http://www.vchelp.net ：

》》惡魔吹著笛子來

你好，

很高興能夠與你進行討論，

雖然本站名字叫做vchelp.net

但我不排斥其他的開發語言，只是自己的能力有限不能將本站內容擴展到其他的語言
，

但我很希望大家在本站對開發中可能遇到的問題和矛盾進行討論，不論是關於語言還
是開發方法的。

我想邀請你成為本站個人專欄的作者，

你可以發表一些你關於開發的想法，就算是與VC無關也沒關係。當然在時間上也沒有
要求，你有時間就寫寫。

盼複：[e-mail]

cuixue 來自 http:// ：

看了各位大俠的話，覺得好像在討論java,其實歷來有兩派，smth幾乎天天在吵，

喜歡java的同志到各個地方佈道，連perl也不放過。呵呵。我個人覺得java先天有一
些劣勢使得他無法取代c/c++的，他的垃圾收集只不過通過一個線程來完成，這對即時系
統是來不及的，EJB的推出也說明java原來是不適合企業級開發的，沒有語言是天生完美
的。java最大的困難我覺得來自microsoft的刁難，c#的推出無疑會奪走windows平臺上
的java份額。java的速度也就不說了。jbuidler的速度不能夠忍受阿，可是這樣一個產
品就是java寫的。由於個人見識不夠，實在不能理解海量吞吐的

server用java.oracle用java是實現了ejb的集成把，他的資料庫engine是不是java 的
那？請大俠指點。而且當時號稱8i不要作業系統，結果市場反應平平，還好

搭上了e-commerce這班車，：）

在說說我對vc和bcb的看法，這兩樣我都算粗粗用過，紫雲影說得挺好的，比較公正。
MFC的確穩定，ATL未免有點複雜，要不WTL就不會出來了。vcl的源碼有一部分是pascal
寫的，這點有點差，不過他的擴展性很好，用用就知道了，決不是好多人認為的vb式的
傻瓜工具。道理很簡單，應為他是符合ansi標準的c/c++語言。其實vc是不夠ansi的，C
String就是不符合的，所以bcb用了 AnsiString.可惜bcb不夠穩定。

提示太慢。幫助的問題我是這樣看得，msdn不是專門給vc的，他是windows開發的指南
，用bcb一樣也很有用，是個寶貝。

好了，不說了，反正按需所取把。

cuixue 來自 http:// ：

xml遠端調用無疑是平臺無關調用的一大進步，可是這也不能說corba就要消失了，

xml這種標記語言雖然提供了強大的標誌檢索的能力，可是它本身的缺點是與以前系統
的相容性，所以最近推出了xhtml以相容以前的應用。電子商務的應用有不同的類型，

對於一般的b2c的應用，sun e1000上跑跑java或許可以，如果是銀行的主機，起碼

1000筆每秒，java是不是可以 那？硬體的提高不是沒有限度的，而且現在資料中心和
OLAP的流行，對即時的要求更高了，實際上對於單位應用硬體資源並沒有什麼起色。而
且資料發掘的應用要求對原有資源的相容，對於中間件而言java開發是有優勢的，corb
a提供了對異構網路的良好支援，ejb也在向它靠，畢竟在這個年代，不可能只存在一個
系統，一種語言，對自身的改造和對異構網路的支援以及原有應用的支援是每種語言都
要面對的難題。

楊寧 來自 http:// ：

世界是多樣性的世界。

不面向應用，一切都是廢物。

學好編譯原理和作業系統，以不變應萬變。

人的精力有限，面面俱到等於面面難到！

妖刀 來自 http:// ：

我不會編一輩子程式,我需要簡單,快速.我只要他好掌握,能實現功能.

至於是專家型的C++還是傻瓜型的VB(Delphi也差不多)我不在乎.

老闆也不在乎

TOM 來自 http:// ：

用VC++和Delphi都各有千秋，Delphi寫介面方便，大部分是寫資料庫程式。但寫出來
的程式太大，如果做一個元件（為HTML寫的）還是用VC好，有句話很好，專業的程式師
用VC,聰明的程式師用Delphi,

TOM 來自 http:// ：

用VC++和Delphi都各有千秋，Delphi寫介面方便，大部分是寫資料庫程式。但寫出來
的程式太大，如果做一個元件（為HTML寫的）還是用VC好，有句話很好，專業的程式師
用VC,聰明的程式師用Delphi,

宇服 來自 http:// ：

作為一個真正的程式師，不懂c/c++ 只能與非專業人士一樣，改改屬性來作程式罷了
。

宇服 來自 http:// ：

惡魔吹著笛子來的話太可怕了，世界可能只有java存在了？？？？？

wenyy 來自 http://www.vchelp.net ：

我很同意楊寧的觀點

》》》世界是多樣性的世界。 不面向應用，一切都是廢物。

蘇 來自 http:// ：

對於DELPHI跟VC的爭議已經不是一天兩天的了,要理論它們的長短處確實比較困難.

作為比較出色的RAD開發工具我認為是DELPHI,VC是稱不上RAD的!對於編程者而言,如果
是低層的東西用VC開發具有明朗的線條–一句一句來,而用DELPHI就必須借用API了(當然
用起來就不是很方便了);而對於從事資料庫開發DELPHI不失為一個好工具!我覺得兩者各
有長處吧!

雅各賓派 來自 http:// ：

呵呵，明朗的線條，此言得之。

Hintell 來自 http:// ：

我愛JAVA,如果不是為了謀生,我立馬放棄現在的UNIX/C PROGRAMMING,不過幸好搞的算
是交易中間件

JAVA是個好東東!

惡魔吹著笛子來 來自 ：

我從來就沒有說果,只有JAVA會存在.我只是說,將來的很多我們熟悉的桌面應用都要以
WEB服務形式出現(包括我們的現在常用的office,windows,visualstudio等等),而用戶端
僅僅是一個外殼.你沒有聽說5年以後ms將不再買osftware,而是靠買網上的服務(office
.net,windows.net).這個時候我想傳統的c/c++的應用範圍就會小的多,而c/c++的升級版
本類似於java,c#就是主流因為他們是為internet設計的而c/c++不是.還有我認為,java
,c#和c/c++不是對立,要我把java,c#和c/c++對立起來,我寧願

把java,c#看作是c/c++的一種internet延伸和升級,使得c/c++更加符合internet的需
要.我們用java,c#的時候我們很大程度上使用了c/c++大約60%的legcy功能,我們能不感
謝c/c++麼.我一直強調的是java和c#是C/C++的衍生,我們在用JAVA時我並不感到是在另
外一個世界裏寫程式我感到的是我仍然在C語言的世界.我想我們不該

有JAVA,C#和c/c++語言的門戶之間.有可能的話我希望稱他們為c語言族(c/c++/java|
c#).

hfgh 來自 http://無 ：

不要再去爭論什麼DELPHI、VC了，語言只是工具。軟體的關鍵是創新和設計，

有了這個前提，用什麼工具去做就看你熟悉什麼工具了，看你的工具能不能

滿足你的設計目標，有限制就選擇別的工具。就這麼簡單，有必要去爭論用

什麼工具嗎？應該是爭論一個軟體的創意和設計有沒有前途，而不是先去爭

論用什麼工具。每個工具都有它的優缺點，主要是看你是否熟悉它，它能不

能順利實現你的目標。如果不能，沒辦法，選另外一個工具。做介面還是

DELPHI合適，做高效率的通信，還是VC，要做大量涉及SDK或底層的東西，還

是VC，就看你專案的目標是什麼，而且是每個目標，不是其中某一個目標。

中國的程式師都受中國教育的限制，老是在一些細節和工具的層次上思考，

沒有在全面的系統層次上思考，在整個電腦技術、通信技術、軟體技術的

整體面上思考問題，才是中國軟體技術進步的道路和方向，而不是去爭論用

什麼工具。另外，本人認為VCHELP網站在中國還是辦得不錯，但欠缺的是整體

技術層面上的東西，而這一點在中國是尤其重要和迫切需要。