此為轉貼資料    http://download.pchome.net/user/delphi/delphivsvc.htm    Delphi VS VC++!  方 圓 推薦     ||→相關資源 方圓專題站    如果你還對Delphi的能力懷疑，那麽請看本文！ 注：本文轉載，出處不詳。     偶然來找一個文件，卻發現這裏關於VC++和Delphi的討論很是激烈。看了大家寫的一些文章，覺得有些 看法正確，有些就很偏頗甚至錯誤(也許無知？很抱歉我這樣說:-)。我無意與任何人爭論，更願意把這看成 是技術上的討論。應該本著公正，不帶偏見的態度(這並不意味著非要平分秋色，一切應以事實爲准)。我用 過除tp1以外的所有版本的Turbo Pascal，所有版本的Turbo C/Borland C++，所有版本的Delphi和C++  Builder；以及msc 5.0/6.0，msc/C++ 7.0和visual C++ 4.2/5.0。不敢說有多高的水平，至少也算有一點 經驗吧。下面就談一下我的看法。     1. 編譯器     應該說Borland的編譯器是最好的。因爲Borland有全世界最好的編譯器開發組(雖然anders hejlsberg 離開了)。從技術上來講，Borland領先任何競爭對手至少2~3年。一般來說，Borland的編譯器總是能生成更 小的代碼並且通常(並不是在任何情況下)更快的代碼。      紫雲英、曾登高在文章中說VC++編譯的程式小，這其實是使用了動態連接的結果 。m$把VC++的運行庫 (msvcrt*.dll,msvcp*.dll, mfc*.dll,你看看這些文件加在一起有多大)在安裝Windows時就放在了system/ system32目錄中了。兩位元說“協商介面”的問題，恐怕是對某些英文文章的理解錯誤。m$就是不願意在 Windows中帶上其他公司的運行文件，沒有技術上的原因。     其實Delphi/C++ Builder不論在動態連接或靜態連接的情況下，生成的程式都要比VC++的小。比如mdi的 例副程式：在Delphi/C++ Builder中選new ... | project s |mdi application，在VC++中用mdi app  wizard；生成的程式功能是非常類似的。     下面是比較結果：     (Delphi打開優化，C++ Builder使用最大速度優化，VC++ 5使用最小代碼優化)                      Delphi 3  Delphi 5 C++  Builder 5 VC++ 5     dynamic link       21k        35k          44k       70k     static link       253k       398k         467k      490k     凡是使用了應用類庫的程式(不管是mfc，owl，vcl以及新的clx框架)都要比不使 用的大不少。這是因爲 目前的智慧連接(smart link)技術還只能針對總體變數/過程，而不能用於物件結構。哪怕你只使用了某個類 (或被這個類間接引用)的一個屬性或方法，這個類以及它所引用的所有類都全部被連接到exe中。目前所有的 編譯器都沒有解決這個問題。 (ps: 其實能生成最小代碼(真編譯)的高階語言編譯器是Turbo Pascal，不信 你寫程式比較一下：     program test;     begin     writeln('hello, world.');     end.     生成的exe不到1.5k。而同樣的c程式：     #include     main()     {     printf("hello, world.\n");     }     最精悍的c/C++編譯器生成的代碼也有6k。     那麽幾個編譯器生成的代碼質量又如何呢？     舉一個例子，比如我們在編程時經常用到的for迴圈語句：     (1) object Pascal:     procedure foo;     var     i, j: integer;     begin     for i := 0 to 15 do j := j + i;     end;     (2) C++     void foo(void)     {     int i, j;     for (i = 0; i < 16; i++) j = j + i;     }     Delphi 3生成的代碼(打開優化)： 位元組數 時鐘周期     00424aa9 33c0 xor eax,eax 1     00424aab 40 inc eax 1     00424aac 83f810 cmp eax,0x10 1     00424aaf 75fa jnz -0x06 0 (可並行)     -----------------     8 3     C++ Builder 5生成的代碼(最大速度優化)：     00401535 33c0 xor eax,eax 1     00401537 40 inc eax 1     00401538 83f810 cmp eax,0x10 1     0040153b 7cfa jl -0x06 0 (可並行)     -----------------     8 3     visual C++ 5生成的代碼(最大速度優化)：     27: for (i = 0; i < 16; i ++)     00401205 mov ecx,dowrd ptr [j] 1     00401208 xor eax,eax 0 (可並行)     28: {     29: j = j + i;     0040120a add ecx,eax 1     0040120c inc eax 1     0040120d cmp eax,10h 1     00401210 jl foo(0x0040120a)+0ah 0 (可並行)     00401212 mov dword ptr [j],ecx 0/1 (取決於上一條指令的     分支預測情況)     30: };     -----------------     16 4.2 (假定分支預測準確度80%)     VC++ 5的最小代碼優化生成也有11個位元組：     27: for (i = 0; i < 16; i ++)     00401205 xor eax,eax 1     28: {     29: j = j + i;     00401207 add dword ptr [j],eax 1     0040120a inc eax 1     0040120b cmp eax,10h 1     0040121e jl foo(0x00401207)+7 0 (可並行)     30: };     -----------------     11 4     注：     (1) Delphi/C++ Builder的結果是用Turbo debugger直接反彙編的，VC++ 5的結果是從集成環境的源級 調試得到的。     (2) 時鐘周期數以pentium處理器爲例，實際上，對於沒有並行執行單元的cpu(比如386/486和nx586等) VC++ 5生成的代碼速度還要更慢一些。     (3) 分支預測準確度源自intel的"pentium optimization reference"。不過與具體程式密切相關，一 般來說程式中的條件轉移指令越密集則分支預測準確度越低。     可以看出，Delphi/C++ Builder的這段程式有1~1.2個時鐘周期的優勢。這主要是因爲Delphi/C++  Builder的編譯器比較智慧，根本不編譯無用的廢語句。 (有趣的是，對於這段程式而言，VC++ 5的最大速度 優化反而不如最小代碼優化生成的代碼運行速度快。) 不要以爲1~1.2個時鐘周期不算什麽，整個程式的快與 慢就是這樣一個個時鐘周期積累出來的。而且就這幾條指令而言相當於快25%~28.6%，是非常可觀的數位。我 沒有用VC++ 6測試(我從VC++ 5以後不再使用vc了，因爲C++ Builder 5能完全相容vc --- 這種相容性從C++  Builder 3開始就有了，不過一開始並不完善)，不知道是否有改進。有人有興趣的話請測試一下。     有興趣的話，可以去jake's code efficiency challenge(http://www.xnet.com/~johnjac)看一看。那有 代碼運行性能挑戰。目前Delphi/C++ Builder在6項測試中保持5項 領先。     (ps：Delphi 2就曾在1996年的PC week的性能測試中擊敗過VC++ 4.2)     2. 語言特性     首先我不想評價所謂“Pascal是玩具語言”這種無知的說法。某些連basic都用不好的人是不可能正確 評價其他語言的優劣的。至於“只配高中生使用”就更加可笑了：peter norton沒上過大學，id software的 johncarmack沒上過大學，你不服氣？！請不要嘲笑高中生，大多數程式師可能永遠也達不到這些“高中生” 的水平。創造性工作需要的是天才，你認爲天才相當於什麽學位？:-)     (1) 預處理，宏以及.h文件   object Pascal不支援預處理，其實是不需要。無法直接編譯源代碼的編譯器才需要預處理器的支援(用於 翻譯/規範根源程式(也包括.h之類)以利於編譯)。預處理器的出現是因爲當初ken thompson和dennis ritchie要 在只有256k記憶體的pdp-11上實現c編譯器難度很大，才採取的折衷辦法。現代大多數c/C++産品已經把預處理器 包含在編譯器中了。      (ps：c中採用盡可能短的關鍵字/運算符也是由於這個歷史原因)      至於macro和.h則應該說是垃圾特性，只是由於相容性的考慮才保留下來的。ansi/iso c/C++規範中明確 建議：“不要使用macro和.h，應該使用程式中的常量定義和函數替代”。因爲macro和.h不是c/C++的語言特 性(這是真的！)，沒有明確統一的語法定義。還會導致編譯速度降低，另外由於macro在每個使用的地方被展 開(不是調用)，大量使用macro會使生成的代碼臃腫。     (2) 集合，子界類型     C++不支援這些object Pascal的原生類型(編譯器能直接識別的)。但可以用類來類比，畢竟C++的物件結構 是最複雜靈活的(ada除外)。不過性能有損失。     (3) 枚舉類型     object Pascal不支援爲每個枚舉元素指定值。例如：     c/C++中可以定義：enum aweek {sun = 1, mon, tue ...};     object Pascal中只能定義：aweek = (sun, mon, tue ...);     (4) 陣列     c/C++不支援object Pascal中指定下標的陣列，下標只能從0開始。     (5) 結構     object Pascal不支援struct(在Pascal中稱爲record)中的位域(bitfield)。bit field 可以bit爲單位(不 需要整位元組)來存儲結構成員，可以減小結構的存儲空間。不過存取效率會有所降低。     (6) 字串     字串處理是object Pascal的強項之一。能夠支援靈活高效的串處理。嚴格意義上講，c/C++不能算支 持原生的字串類型。char *和char[]更近似于用戶自定義類型，因爲編譯器不支援字串的記憶體自動分配 和回收，需要用戶自己調用malloc()和free()。object Pascal也支援c/C++風格的字串(稱爲PChar)。 不 過string類型更加強大。從實現上來看，object Pascal的string類型使用字首表示串長度(1位元組字首的 shortstring和4位元組字首的long string，兩種string自動相容，並且long string也相容PChar)，c/C++中 的char *和char[]使用尾碼chr(0)表示串結束。不同的表示方法對串處理性能有很大的影響：對於大量，複 雜的字串操作，用object Pascal可以寫出比c/C++快幾十倍的程式(許多用Pascal寫的Pascal編譯器，比 如free Pascal，Pascal pro等，雖然技術水平一般，但編譯速度也很快，在某種程度上也得益於 Pascal的 字串處理效率)。比如取串長度函數length/strlen()，object Pascal的實現只需要一條mov指令，而c/C++ 的實現則需要進行重復串掃描直到找到結尾0爲止。object Pascal的string類型在支援unicode字元方面也有 優勢。要知道c/C++的字串給現代作業系統支援unicode字元帶來了很大的困擾，比如串'abc'的unicode表 示爲：41 00 42 00 43 00，這使c/C++程式根本無法處理這種字串。雖然修改編譯器可以很容易解決這個 問題，但光修改編譯器是不夠的，還要修改作業系統，否則以前的大量c/C++程式根本無法在新作業系統上 使用(這簡直是災難 --- 你連notepad都沒了，怎麽辦？:-)。Windows採用凡是涉及字串處理的api都提供 兩套的解決方案。比如textout，有用於處理ascii字元的textouta和用於處理unicode字元的textoutw。而 unix/linux採用另一種辦法：凡是涉及字串處理的api都使用utf8壓縮編碼(一種類似於rtf的編碼方法： 凡是ascii字元都直接存儲，多位元組字元則用\進行轉義)，雖然(勉強)保證了相容性卻也代價不小。     (ps：C++中的string/ansistring是用類類比的，所以性能...)     (7) 多重繼承     毫無疑問，object Pascal不支援多重繼承；並且也看不出Borland有增加這一特性的意向(其實增加是輕 而易舉的)。object Pascal通過介面(interface)實現多重繼承.interface不僅可以引入用object Pascal實 現的物件，也可以引入其他語言實現的com/dcom/corba物件。你真的需要多重繼承嗎？我想大多數程式師和 我一樣都從來沒有使用過多重繼承(連vcl這麽強大靈活的體系結構都根本沒有用到多重繼承)。  (ps：java和Delphi一樣不支援多重繼承，也使用interface來實現多重繼承。其實這並不奇怪：jdk 1.2和  java 2主要是由Borland開發的，sun只挂名而已。不信你看java類庫是不是和vcl很象。:-)     (8) 物件模板     object Pascal不支援物件模板。因爲物件模板不過是巨集的語言實現而已(巨集本身不是c/C++的語言特性)。     (9) 重載     object Pascal支援函數/過程的重載，不支援運算符重載。C++全部支援。     (ps：我個人傾向于object Pascal應該增加對運算符重載的支援)     (10) 位元及邏輯操作     object Pascal和c/C++在這方面沒什麽差別。c/C++的&，|，~，^，>>，<<，&&，||，!等效於object  Pascal的and，or，not，xor，shr,shl(and，or，not，xor既用於位元操作也用於邏輯操作)。不過c/C++不支援 邏輯xor(a xor b = a and notb or not a and b，還是可以實現的)。     (11) 風格     其實這是我更傾向於使用Delphi的一個重要原因(由於工作的原因，我也經常使用C++和彙編)。就象有些 文章所說的：“object Pascal和C++是同一重量級的語言”，確實難分軒輊，差別反而主要是在風格上。C++ 強調靈活，而object Pascal更注重整潔和優美。《程式設計語言：設計與實現》一書的作者也稱讚Pascal是 “一種極優美的語言”。有人因此認爲Pascal“笨拙”。其實應該是“大道至簡”。我認爲即使用C++寫程式 也還是工工整整的好，不要賣弄技巧。只有水平不高不低的程式師才喜歡賣弄技巧(水平太低的賣弄不了，太 高的又不願賣弄了)。就象有人評李昌鎬的棋“平淡”，但馬曉春再怎麽“鬼才”也只能甘拜下風。     上面說的其實都是C++ vs object Pascal。不過也適用於VC++ vs Delphi。  (ps：VC++其實並未實現全部ansi/iso C++ 95規範(目前的最新標準)的特性(所以有人戲稱之爲c+)。而 C++ Builder則完全相容ansi/iso C++95規範，並支援at&t(c的誕生地)和unix v的全部C++擴展特性。有人稱 “m$堅持工業標準，Borland隨意修改”，這是不對的。Delphi也全相容ansi/iso Pascal 1983/92規範，以 及apple object Pascal (用過codewarriorprofessional的應該知道apple的object Pascal)。)     3. 功能及其他     (1) 易用性     毫無疑問Delphi有巨大優勢，這不用多說了吧。     (ps：Delphi的真正偉大之處在于並不因爲易用而降低技術水準。你需要複雜性就有複雜性，你需要靈 活性就有靈活性；不用視覺化也一樣寫程式(視覺化只是object Pascal 物件結構的另一面)，不用vcl也一 樣寫程式)     (2) 適用範圍     VC++幾乎能做任何硬體允許的工作。Delphi也能。(“不！！！”，我知道你會這樣說，你會舉出vxd。:-)  Delphi不能寫vxd(其實如果你用Delphi生成obj，再用m$的link連接，是可以的)是有原因的(你見過非m$的工 具能生成vxd的嗎？watcom？symantec？gnu？...)，但不是技術上的原因。vxd的le(linear executable)文 件格式最早出現在Windows 3.0中，格式很簡單(比ne和pe格式都要簡單)，基本上是記憶體映象文件。但m$不知 道出於什麽動機就是不允許其他公司的軟體生成它的這種(專利)格式。Delphi是可以寫Windows nt的sys和新 的wdm(Windows driver model)驅動程式的，這些使用普通的dll格式。      (ps：從法律角度講，你自己寫一個程式，未經m$允許生成ms word文件也是不行的)     (ps：玩過“奇迹時代”(age of wonders，http://www.epicgames.com)嗎？是用Delphi 3寫的。畫面和 速度都優於m$的“帝國時代”。不過我不喜歡玩策略類遊戲，我喜歡的是duke3d和QUAKE系列，還有tomb  raider系列。:-)     (3) 集成開發環境     Delphi的ide更簡潔/好用一些。     (4) 資料庫支援     在這方面除了Delphi的兄弟C++ Builder/jBuilder恐怕只有power Builder能(勉強)與Delphi相比。不過 pb的性能和使用範圍就差得太遠了(要不怎麽叫poor Builder呢 ？:-)。     (ps：我的印象是現在大多數基於網路/大型資料庫的c/s和多層結構的應用都是用Delphi/jBuilder開發  的)     (5) 網路功能     Delphi也有一定的優勢。尤其是在Internet開發方面。     (6) 元件支援     Delphi除了基於object Pascal的vcl/clx外，也支援基於com/dcom的元件(比如activex)，另加corba支 持。VC++只支援支援基於com/dcom的元件。     (7) 應用框架/設計思想     vcl比mfc至少領先一代，這也毋須多言。mfc充其量不過是對owl的(一種不太成功的)模仿而已，從設計 思想上看甚至還不如owl。作爲一種語言的基本類庫(不論可視與否)，應該從大處著眼，力求簡潔有效，保 持一定的彈性和抽象度(抽象意味著從功能出發，比如vcl中的tcanvas就是對Windows中dc(device context) 的一種極好的抽象，比起mfc中的設計高明了何止一點半點)。而不是面面俱到，一一照搬apis(不幸的是， m$的程式師多年以來一直在不辭勞苦地做這項工作)。看看mfc的某些類，簡直慘不忍睹：通常除了省了hwnd 和dc之類的參數(已經作爲類的私有資料保存了)，其方法(method)簡直就是Windows api的翻版。這樣做有 什麽意義呢？Windows api不就擺在那裏嗎？比如說，使用mfc中的線程類還不如直接調用createthread/ exitthread/resumethread/setthreadpriority之類的api更方便快速呢。(ps：用過Delphix(http://www. yks.ne.jp/~hori/)嗎？Directx這麽繁雜的結構可以用object Pascal封裝得如此之好再次證明了vcl體系結 構的強大)     (8) 調試     兩者相差無幾。VC++的源級調試更用戶友好一些，而Delphi/C++ Builder對多線程程式的調試支援更好。     (ps：要比單獨的調試工具，Borland的Turbo debugger可就要比m$的codeview強多了)     (9) 運行環境/系統需求     應該說差不多。VC++的啓動速度確實要快於Delphi(這主要是相對於Delphi 4+而言，Delphi 3的啓動還 是很快的)。這很大程度上是由於一個事實：VC++主要是一個基於文本編輯器的傳統開發環境。code war- riorprofessional不是啓動更快嗎？至於“一個資料庫程式要帶上3~5mb的bde運行文件”的說法，這可能是 由於在安裝製作工具(installsheild，wise之類)中使用了“全部bde安裝”(默認)而不是“部分bde安裝”。 如果你只使用access，dbase，foxpro，paradox之類的桌面資料庫，只需要幾百k的運行文件就可以了。用 m$的工具開發的資料庫程式也要帶上一大堆odbc，dao，jet，ado，msde之類的運行文件。在Delphi 5中， 如果使用adoexpress，interbase express訪問資料庫的話，可以不帶bde。(ps：不管怎麽說，Borland在 Delphi/C++ Builder的啓動速度方面還是要努力改進!)     (10) 産品質量/穩定性     有文章稱“VC++的質量好，穩定性高”。真的是這樣嗎？visual studio的service pack不是都出到4了 嗎？什麽是service pack？主要不就是bug fix + patch嗎？！Borland的工具也並不完美，Delphi 3的vcl 中確實存在“記憶體漏洞”，會導致用d3開發的程式有時(並不總是)退出後不能釋放分配的記憶體。VC++的問題 也不少：ie是用VC++寫的吧，上網時多啓動幾個，開開關關，最後全關閉，看看你的系統資源剩下多少了？ 還經常導致“general protection error”。ultra edit是用VC++寫的吧，也有同樣的問題。其實說到底， 程式質量好不好，運行穩定不穩定，主要取決於開發者的水平/責任心。比如說tomb raider系列和QUAKE系 列遊戲同是用VC++開發的，但畫面質量和運行速度顯然QUAKE系列更勝一籌。象美國航空航天局(nasa)，俄 羅斯宇航局(rsa)，美洲銀行(bankof america，資産超過5000億美元的大銀行)，其他諸如american air- lines，at&t，bmw，compaq，bbc television，british telecom等大型機構/公司都在用Delphi開發複雜的， 企業級(可笑的是，有人居然稱“用vc開發企業級的桌面應用”，殊不知企業級應用和桌面應用是相對而言 的)的應用系統(在http://community.Borland.com(Borland社團站點)上有關於用Delphi和C++ Builder開發 的産品介紹)，如果有人還要說“...穩定和可靠是硬道理，只好忍痛割愛了”，那他恐怕只好自製開發工具。     (ps：關於Delphi與某些顯卡驅動衝突的問題，是由於某些顯卡(如s3 virge gx)的老版本驅動程式不能 正確處理Windows公用控制中的imagelist的繪製方法造成的，在這種情況下所有在imagelist中使用多個圖 象的程式都會有問題)(ps：至於“一看到很多優秀的共用軟體冒出具有Delphi特色的錯誤異常就感到悲哀”， 建議此人先搞清楚你看到的“錯誤異常”消息是這些軟體本身出錯呢，還是運行時的異常處理消息(比如 “沒有找到指定文件”或“索引超出範圍”之類)再說。Delphi中有完善的異常處理，所以很多程式師不再 寫錯誤處理，而放手讓編譯器去處理。我認爲這不是一個好習慣，至少彈出的消息對話方塊可能與你的程式所 用的語言/風格不一致。讓人家誤會了不是？:-)     (11) 幫助/文檔     VC++的幫助和文檔確實要比Delphi/C++ Builder的豐富一些。不過這不應當包括msdn，因爲msdn是一套 獨立的産品，並不是專門給VC++準備的，況且其中包括了相當多的Windows技術資料。作爲一名程式師，不 管用什麽開發工具，可以(也應當)有一套msdn。Windows資料結構/apis是用c風格描述的這一點可能對Delphi 程式師來說略有不便，不過Delphi中已經包括了大多數轉換；另外，如果一個程式師連轉換.h文件這麽簡單 的工作都做不了的話，他(她)可能也做不了什麽像樣的開發。Internet上的一個志願者組織 (www.Delphi-jedi.org/)在這方面也做了大量工作，在他們的站點上有幾乎全部有用的c/C++庫.h的object  Pascal翻譯。(ps：Delphi/C++ Builder程式師爲什麽不可以買一套msdn呢？畢竟我們還在用m$的作業系統， 總不至於連Windows技術資料都不要了吧)      (ps：從msdn看m$msdn中的技術資料主要是以compiled html(.chm)格式存放的，但m$把全部.chm放在disc  #1，而把索引文件(.chi)單獨放在disc #2。這樣一來就無法從光碟上直接看這些文件。要麽安裝，要麽手工 把相應的.chm和.chi拷貝到一起。我看不有什麽技術上的理由(誰知道請告訴我)不把一半.chm和.chi放在一張 盤，而另一半放在第二張盤。這至少反映出m$內部某些人的陰暗心理)     (12) 國際化支援     VC++中已經包括了十多種語言的rtl資源，Delphi中需要自己做資源本地化。雖然franch，german之類 的版本中也包括english資源。:-<     (13) 應用領域     VC++在Windows設備驅動開發(畢竟是m$ Windows)和某些桌面應用(比如遊戲)開發中用得較多。Delphi 更多應用在資料庫/多層結構，多媒體和Internet開發等方面。     (ps：VC++在遊戲開發中用得較多我看主要是價格因素，遊戲使用專用介面，通常不涉及資料庫和inter- net(即使Internet play也不過是簡單的tcp連接，並且Directp lay中已包括此項功能)，昂貴的Delphi和C++  Builder顯示不出優勢。只需要$79的VC++標準版，Directx sdk(可免費下栽)，opengl文檔(也是免費的)，至 多再加一套msdn即可.比如QUAKE，全是手寫的c代碼，連C++特性都很少用到。Borland也認識到了這一問題， 所以發佈了免費的C++編譯器)     (14) 價格     m$的開發工具確實便宜(相對而言)，不過是否物有所值，只能看你幹什麽用了。      (ps：別指望你買的toyota能有ferrari的性能。:-)     (15) 前景     有人認爲m$財大氣粗，Borland難以對抗。我看不能這麽簡單下結論。m$有它自己的問題：法律訴訟， 人才流失，資源分散，四面出擊(m$現在連滑鼠，鍵盤，遊戲杆， 玩具 都生産)。而Borland/inprise集中精 力在開發工具，中件産品(如midas，visibroker和application server)和企業應用/管理環境(如apPCenter 和securityservice)上，應該還是大有可爲的。況且Borland和m$之間並非純粹的競爭關係，Borland開發工 具給m$Windows帶來的收益要遠大于和m$開發工具競爭帶來的損失。畢竟對m$來說，開發工具只占其收入的很 少一部分，即使不搞開發工具也只不過是個面子問題，於m$無損。m$在它面臨壟斷/不正當競爭指控的時候， 因爲長期侵犯知識産權而賠償給Borland一億美元(稱爲“授權費”),這多少也可以看作是一種和解的舉動吧。 另一種經常聽到的論調是“m$的産品市場份額大，Borland能撐得住嗎？”，這其實也有很多問題。鑒於m$出 於競爭的目的，經常虛報數位，影響市場(m$的律師在法庭上承認m$曾誇大過其ie和office的市場佔有率)； m$自己宣傳的其開發工具的市場佔有率也很值得懷疑。m$還有重復計算的問題，比如賣掉一套visual  studio，在計算vb，vc，vj等的銷售量時都計算在內。其實很多人/公司買visual studio只用其中的一兩種。 其實Borland産品的銷售量還是很大的，尤其是在歐洲，北美和澳大利亞，在亞洲...(是因爲d版太多了)。另 外，每個公司都有自己的産品/市場定位，你能因爲toyota，ford，volkswagen賣的多就說ferrari，maclaren， benz不行了嗎？     4. 結論     Delphi(其實應該說Borland産品)在技術上有優勢，VC++(其實應該說m$産品)也佔有相當的市場份額。 (ps：說了半天等於沒說。:-)(ps：m$的c#(讀c sharp)能取得突破嗎？我看不會。因爲m$産品通常達不到所宣 傳的性能；而且一種不符合標準(c#不相容任何一種語言標準，雖然據稱更接近c)的産品也很難取得成功。 j++就是一例)     5. 附：我所知道的Borland和m$的故事     (1) Bill Gates是如何拿到IBM訂單的1979年，tim paterson寫了最初的DOS並以$1000的價格賣給了digi- talreserch。當時apple的apple i和apple ii銷勢很好，所以IBM在1980年也決定搞PC。Billgates知道後，認 爲是個機會，就以$5000從digital reserch買下了DOS，並逼著手下人在一間沒有空調的小黑屋裏日夜不停加 以修改。m$當時是個小公司，只有十幾個人，名叫micro-soft。所以儘管DOS的開價($20000加每拷貝$30授權 費)比cp/m-86(指用於intel8086/8088的版本，不是指年代)的開價($100000加每拷貝$70授權費)便宜不少， IBM的人還是傾向於使用cp/m-86。據“比爾.蓋茨的秘密”(Bill Gates' secrets)一書的作者說，Bill急得團 團轉，只好求助於他媽媽。Bill的母親時任華盛頓大學校長，與當時的IBM董事長john opal是大學同學(據 說...)。Bill這一招果然有效，沒多久就拿到了IBM的訂單，從此DOS成了IBM PC上的首選作業系統。     (2) Borland的名字和歷史     Borland聽起來不象一個公司的名字，倒象一個國家的名字。1982年，philippe kahn帶著3000美元從巴黎 到了美國，除去機票錢已所剩無幾，只好租人家的車庫小閣間住。kahn在矽谷幹了一段時間，並以mit(market  in time，恰好與麻省理工學院的縮寫相同)爲名開了一家公司。1983年，kahn和anders hejlsberg(丹麥人， Turbo Pascal編譯器的主要作者)合作開發了Turbo Pascal，並賒帳在《新聞周刊》上登了一份彩頁廣告。Turbo  Pascal在PC開發工具中是一個里程碑式的産品，它第一次把編譯時間由分縮短到秒，並且其$49的價格在當時也 是創紀錄的(當時的一份編譯器動輒數千美元，便宜的也要幾百美元，還不好用)。Turbo Pascal在不到兩年的 時間裏銷售了超過130萬套(考慮到當時的PC數量，這是一個非常驚人的數位)，Borland從此創立。kahn在解釋 爲什麽以Borland命名時說“我們要起一個與衆不同的名字，其他公司都是叫這個micro，那個soft什麽的”。 不過據認爲這個名稱與德國或北歐的某些地名有關(kahn的父親是德國人，而且Borland的很多開發人員是北歐 人)。     (3) anders hejlsberg爲什麽去了m$1996年，anders hejlsberg離開Borland去了m$。在此之前，m$曾多次 企圖挖走anders，但都沒有成功。據信anders去m$(主要)不是錢的問題，雖然m$的開價也相當有吸引力：130萬 美元年薪外加股票期權和分紅，總計超過300萬美元。主要原因是anders和Delphi開發組的其他成員在修改編譯 器的問題上發生了爭執；     還有，據Borland內部人講，anders認爲自己不再是“不可缺少的人”。 雖然anders hejlsberg去了m$， 我仍然尊敬他是一個天才，Turbo Pascal的主要作者，Delphi的奠基者。     (ps：anders從1999年初就不在j++組了，而去做com+的開發。m$的人講的)     (4) m$産品的秘密     <1> msc最初是從at&t買的授權； <2> vb的1，2，3版實際上不是m$開發的，而是cooper software開發的。john cooper 在m$時未受重用，離 開後m$倒要花錢請他開發産品，真有點黑色幽默的味道； <3> ms sql server最初是買sybase的産品，6.5以前的ms sql server和sybase根本就是一回事； <4> Windows 95的主要技術負責人(名字我不記得了，不過在dejanews(www.deja.com)上可能還能找到有關 文章)是1990年從Borland跳到m$的，不過他在1998年已經離開m$，開了自己的公司； <5> Windows nt的開發組整個是從dec挖來的，是以前做dec vms的那些人。所以 在win32平臺上有很多vms的 痕迹，比如說coff目標文件格式。 (5) .net到底是什麽，Bill Gates也不知道，請看對Bill Gates的採訪： 記者：現在，市場仍然對.net感到困惑。... .net的實質到底是什麽？ 蓋茨：.net是我們對下一代Internet的設想。... 舉個簡單的例子，.net不僅允許你查看自己喜愛的棒球隊的時間安排，並且還能夠對這個時間安排進一步加 以利用。 (？？？究竟怎樣“進一步加以利用”？爲什麽不說？難道現在的軟體不能“進一步加以利用”？) 6. 注： 本文系完全由作者本人所寫，文中提到的所有技術資料均由本人驗證或標明出處，轉載時請保持完整 ********************************************************* 哈哈&兵燹 最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好 Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知 K.表Knowlege 知識,就是本站的標語:Open our mind to make knowledge together! 希望能大家敞開心胸,將知識寶庫結合一起

------
**********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind