再談Delphi vs VC++(非常精彩) (轉)

再談Delphi vs VC++(非常精彩) (轉)[@more@]

這是一篇非常精彩的文章，無意中在網上發現，

比起原來《員》發表的開發工具大比拼更專業。

可惜不知道作者是誰，如果作者看到或者有誰知道作者，

請一定和我聯絡。（to:mail:jiangtao@csdn">mail:jiangtao@csdn.net）

偶然來找一個，卻發現這裡關於vc++和的討論很是激烈。看了大家寫的一些
文章，覺得有些看法正確，有些就很偏頗甚至錯誤(也許無知？很抱歉我這樣說:-)。我
無意與任何人爭論，更願意把這看成是技術上的討論。應該本著公正，不帶偏見的態度
(這並不意味著非要平分秋色，一切應以事實為準)。我用過除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, 你看看這些檔案加在一起有多大)
在時就放在了system/system32目錄中了。兩位說“協商介面”的問題，恐
怕是對某些英文文章的理解錯誤。m$就是不願意在windows中帶上其他公司的執行檔案，
沒有技術上的原因。

其實delphi/c++ builder不論在動態連線或靜態連線的情況下，生成的程式都要比
vc++的小。比如mdi的例子程式：在delphi/c++ builder中選new ... | projects |
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 ＜stdio.h＞
main()
{
  printf("hello, world.n");
}
最精悍的c/c++編譯器生成的程式碼也有6k。
)

那麼幾個編譯器生成的程式碼質量又如何呢？
舉一個例子，比如我們在時經常用到的for迴圈語句：
(1) 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  d 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 deger直接反的，vc++ 5的結果是從
整合環境的源級得到的。
(2) 時鐘週期數以pentium為例，實際上，對於沒有並行單元的(比如
386/486和nx586等)vc++ 5生成的程式碼速度還要更慢一些。
(3) 分支預測準確度源自的"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能完全相容
--- 這種相容性從c++ builder 3開始就有了，不過一開始並不完善)，不知道是否
有改進。有人有興趣的話請測試一下。

有興趣的話，可以去jake's code efficiency challenge(~johnjac)
看一看。那有程式碼執行挑戰。目前delphi/c++ builder在6項測試中保持5項領先。
(ps：delphi 2就曾在1996年的pc week的效能測試中擊敗過vc++ 4.2)

2. 語言特性
首先我不想評價所謂“pascal是玩具語言”這種無知的說法。某些連basic都用不好的
人是不可能正確評價其它語言的優劣的。至於“只配高中生使用”就更加可笑了：
peter 沒上過大學，id software的john carmack沒上過大學，你不服氣？！
請不要嘲笑高中生，大多數程式設計師可能永遠也達不到這些“高中生”的水平。創造性工
作需要的是天才，你認為天才相當於什麼學位？:-)

(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)。bitfield
可以bit為單位(不需要整位元組)來結構成員，可以減小結構的儲存空間。不過存取
會有所降低。

(6) 字串
字串處理是object pascal的強項之一。能夠支援靈活高效的串處理。嚴格意義上講，
c/c++不能算支援原生的字串型別。char *和char[]更近似於自定義型別，因為
編譯器不支援字串的記憶體自動分配和回收，需要使用者自己呼叫malloc()和free()。
object pascal也支援c/c++風格的字串(稱為pchar)。不過string型別更加強大。從
實現上來看，object pascal的string型別使用字首表示串長度(1位元組字首的short
string和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採用凡是涉及字串處理的都提供兩套的解決方案。比如textout，
有用於處理ascii字元的textouta和用於處理unicode字元的textoutw。而/採
用另一種辦法：凡是涉及字串處理的api都使用utf8編碼(一種類似於rtf的編碼
方法：凡是ascii字元都直接儲存，多位元組字元則用進行轉義)，雖然(勉強)保證了兼
容性卻也代價不小。
(ps：c++中的string/ansistring是用類模擬的，所以效能...)

(7) 多重繼承
毫無疑問，object pascal不支援多重繼承；並且也看不出borland有增加這一特性的意
向(其實增加是輕而易舉的)。object pascal透過介面(interface)實現多重繼承。
interface不僅可以引入用object pascal實現的物件，也可以引入其他語言實現的
com/dcom/物件。你真的需要多重繼承嗎？我想大多數程式設計師和我一樣都從來沒有
使用過多重繼承(連vcl這麼強大靈活的體系結構都根本沒有用到多重繼承)。
(ps：和delphi一樣不支援多重繼承，也使用interface來實現多重繼承。其實這並
不奇怪： 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 not b 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
(用過code warrior professional的應該知道apple的object pascal)。
)

3. 功能及其他
(1) 易用性
毫無疑問delphi有巨大優勢，這不用多說了吧。
(ps：delphi的真正偉大之處在於並不因為易用而降低技術水準。你需要複雜性就有復
雜性，你需要靈活性就有靈活性；不用視覺化也一樣寫程式(視覺化只是object pascal
物件結構的另一面)，不用vcl也一樣寫程式)

(2) 適用範圍
vc++幾乎能做任何允許的工作。delphi也能。
(“不！！！”，我知道你會這樣說，你會舉出vxd。:-)
delphi不能寫vxd(其實如果你用delphi生成obj，再用m$的link連線，是可以的)是有原
因的(你見過非m$的工具能生成vxd的嗎？watcom？？？...)，但不是技術
上的原因。vxd的le(linear executable)檔案格式最早出現在windows 3.0中，格式很
簡單(比ne和pe格式都要簡單)，基本上是記憶體映象檔案。但m$不知道出於什麼動機就是
不允許其他公司的生成它的這種(專利)格式。
delphi是可以寫的sys和新的wdm(windows model)程式的，這些
使用普通的dll格式。
(ps：從法律角度講，你自己寫一個程式，未經m$允許生成ms word檔案也是不行的)
(ps：玩過“奇蹟時代”(age of wonders，)嗎？是用
delphi 3寫的。畫面和速度都優於m$的“帝國時代”。不過我不喜歡玩策略類遊戲，我
喜歡的是duke3d和quake系列，還有tomb rar系列。:-)

(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的元件(比如)，
另加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(~hori/)嗎？這麼繁雜的結構可以用
object pascal封裝得如此之好再次證明了vcl體系結構的強大)

(8) 除錯
兩者相差無幾。vc++的源級除錯更使用者友好一些，而delphi/c++ builder對多執行緒程式
的除錯支援更好。
(ps：要比單獨的除錯工具，borland的turbo debugger可就要比m$的codeview強多了)

(9) 執行環境/系統需求
應該說差不多。vc++的啟動速度確實要快於delphi(這主要是相對於delphi 4+而言，
delphi 3的啟動還是很快的)。這很大程度上是由於一個事實：vc++主要是一個基於文
本編輯器的傳統開發環境。code warrior professional不是啟動更快嗎？
至於“一個資料庫程式要帶上3~5mb的bde執行檔案”的說法，這可能是由於在安裝製作
工具(installsheild，wise之類)中使用了“全部bde安裝”(預設)而不是“部分bde安
裝”。如果你只使用access，ase，foxpro，paradox之類的桌面資料庫，只需要幾百
k的執行檔案就可以了。用m$的工具開發的資料庫程式也要帶上一大堆odbc，dao，jet，
ado，msde之類的執行檔案。在delphi 5中，如果使用adoexpress，interbase express
訪問資料庫的話，可以不帶bde。
(ps：不管怎麼說，borland在delphi/c++ builder的啟動速度方面還是要努力改進!)

(10) 產品質量/穩定性
有文章稱“vc++的質量好，穩定性高”。真的是這樣嗎？的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)，美洲銀行(bank
of america，資產超過5000億美元的大銀行)，其他諸如american airlines，at＆t，
bmw，compaq，bbc television，british telecom等大型機構/公司都在用delphi開發
複雜的，企業級(可笑的是，有人居然稱“用vc開發企業級的桌面應用”，殊不知企業
級應用和桌面應用是相對而言的)的應用系統(在
(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上的一個志願者組織
()在這方面也做了大量工作，在他們的站點上有幾乎全部有用的
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++在遊戲開發中用得較多我看主要是價格因素，遊戲使用專用介面，通常不涉
及資料庫和internet(即使internet play也不過是簡單的tcp連線，並且directplay中
已包括此項功能)，昂貴的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和security service)上，應
該還是大有可為的。
況且borland和m$之間並非純粹的競爭關係，borland開發工具給m$ windows帶來的收益
要遠大於和m$開發工具競爭帶來的損失。畢竟對m$來說，開發工具只佔其收入的很少一
部分，即使不搞開發工具也只不過是個面子問題，於m$無損。m$在它面臨壟斷/不正當
競爭指控的時候，因為長期侵犯智慧財產權而賠償給borland一億美元(稱為“授權費”)，
這多少也可以看作是一種和解的舉動吧。
另一種經常聽到的論調是“m$的產品市場份額大，borland能撐得住嗎？”，這其實也
有很多問題。鑑於m$出於競爭的目的，經常虛報數字，影響市場(m$的律師在法庭上承
認m$曾誇大過其ie和的市場佔有率)；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$的(讀)能取得突破嗎？我看不會。因為m$產品通常達不到所宣傳的性
能；而且一種不符合標準(c#不相容任何一種語言標準，雖然據稱更接近c)的產品也很
難取得成功。j++就是一例)

5. 附：我所知道的borland和m$的故事
(1) bill gates是如何拿到ibm訂單的
1979年，tim paterson寫了最初的dos並以$1000的價格賣給了digital reserch。當時
apple的apple i和apple ii銷勢很好，所以ibm在1980年也決定搞pc。bill gates知道
後，認為是個機會，就以$5000從digital reserch買下了dos，並逼著手下人在一間沒
有空調的小黑屋裡日夜不停加以修改。m$當時是個小公司，只有十幾個人，名叫
micro-soft。所以儘管dos的開價($20000加每複製$30授權費)比cp/m-86(指用於intel
8086/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$開發的，而是cer software開發的。john cooper
在m$時未受重用，離開後m$倒要花錢請他開發產品，真有點黑色幽默的味道；
＜3＞ ms SERVER最初是買的產品，6.5以前的ms 和sybase根本就
是一回事；
＜4＞ windows 95的主要技術負責人(名字我不記得了，不過在dejanews()
上可能還能找到有關文章)是1990年從borland跳到m$的，不過他在1998年已經離開m$，
開了自己的公司；
＜5＞ windows nt的開發組整個是從dec挖來的，是以前做dec vms的那些人。所以在
平臺上有很多vms的痕跡，比如說coff目標檔案格式。

(5)到底是什麼，bill gates也不知道
請看對bill gates的採訪：
記者：現在，市場仍然對.net感到困惑。... .net的實質到底是什麼？
蓋茨：.net是我們對下一代internet的設想。... 舉個簡單的例子，.net不僅允許你查
看自己喜愛的棒球隊的時間安排，並且還能夠對這個時間安排進一步加以利用。
(？？？究竟怎樣“進一步加以利用”？為什麼不說？難道現在的軟體不能“進一步加
以利用”？)

6. 注：
本文系完全由作者本人所寫，文中提到的所有技術資料均由本人驗證或標明出處，轉載
時請保持完整。


best regards

herman wolfenswicz




對該文的評論
  SuperFir (2000-12-11 18:34:38) 

不錯！我是個菜鳥！可我還準備學習vc6呢。
打擊我！

  lixiaolei (2000-12-6 13:31:34) 


【】我為什麼進步去？

  yunn (2000-12-1 22:15:29) 

同意筆者的意見
我也是三種工具都用很長的時間了，對vc++的感覺就是沒有DELPHI好
哎，說起來，工具就是工具，就看你合適哪個了

  GuXl (2000-12-1 15:50:17) 

Vc ＆ Delphi 都只不過是 工具

當然工具也要挑好用的用，
化大量時間去 訓練人適應工具好像不大合宜吧


  dogbear2000 (2000-12-1 11:41:08) 

我非常喜歡你的文章，如果轉載，需不需要付費？

  r3000 (2000-12-1 10:38:24) 

我以一個程式老兵的身份，象你致敬，說的非常好，不過，
有這樣一個事實，delphi確實比VC強，VCL也確實強於MFC，
但大多數商業軟體仍舊是使用VC開發的，並且有很多根本就是
用API開發的，所以一個所謂先進的技術，比如C++，比如物件導向，
並不代表開發出的東西是先進的，可能只是時髦而已。

所以我說，還是別比了，根本就是兩回事，
Delphi可能是搖滾樂，VB可能是流行樂，
VC可能是嚴肅，不能因為個人好惡否定任何一種。

也經常聽初學者問：那種開發工具更好？
我的回答是：不在工具而在人，人不行好琴也只出噪音！