delphi編譯器有問題嗎

① delphi編譯器效率高到底是指什麼

所謂delphi編譯器效率高，一般指的是以下三方面：

1、編譯連接時間短，這一點是其他任何編譯器都無法相比的（一般來說，VC, VB編譯過程所用的時間是Delphi的幾倍），原因很簡單：Pascal語法限制嚴格，用戶必須規范地編碼，省去了編譯器的很多麻煩。

2、編譯出的程序執行速度快，產生的代碼長度短。這一點比VB強，但和VC基本一樣，誰也沒有優勢。不過很多人有誤解，以為Delphi類庫龐大復雜，加一個控制項就要把整個一個源文件全部加進來，代碼長度太大，效率太差。其實真實情況是，擁有眾多VCL控制項類庫，是Delphi的一個獨特之處，VC的MFC庫無法與之相比——MFC有的底層簡單封裝的類，VCL庫都有，但VCL有的上層組件，MFC卻根本沒有。使用VCL上層應用控制項後，代碼長度的確比VC大，不過VC卻沒有這方面的選擇，而VC所用的從底層一磚一瓦地編碼的方式，Delphi完全支持，而且絕對沒任何劣勢，代碼長度也不長（VC的語法復雜，按C程序員一般習慣做的話，代碼長的反而會是VC）。產生誤解的原因，是多數Delphi程序員是應用級的，而VC程序員是底層些的，應用程序員大多不太懂得底層代碼的編寫，只會搬控制項、響應事件，以為底層的東西Delphi做不來。

3、對應用級的程序開發周期短——這也就是Borland一貫吹捧的「快速開發工具」的含義。正因為VCL的存在（封裝了很多界面組件以及通訊、資料庫、internet應用等很多後台功能），對高層應用不再需要一磚一瓦地受累，使開發周期縮短了很多倍。

單純從技術角度說，編譯器效率應該指編譯出的代碼是否短小/運行速度是否快，以及是否能用較少的源代碼高效地實現復雜功能。前一方面Delphi並不比VC差，而比VB強，但並非一騎絕塵；後一方面則的確有一騎絕塵之象。

Delphi的致命缺點，其實不是技術——技術它是領先的，毫無疑問，問題是市場策略和公司實力（Borland只是家小公司），微軟「攜操作系統以令諸侯」，誤導了眾多軟體開發公司，讓它們以為微軟的才正宗和好用，造成了事實上的VB，VC用戶群遠比Borland的龐大，源代碼數量也一樣是C/C++遠遠占優，而Borland的C++ Builder卻開發得太晚難以形成市場優勢。

概括來說，如果你要開發上層應用為主的程序，特別是資料庫方面的程序，那麼Delphi能讓你省不少時間；而若開發底層些的軟體，為能有更多相關代碼可以參考利用，為能容易地招聘到更合適的程序員，以及為了代碼維護方便，都適合用C/C++去做，當然，C++ Builder從技術上說是個不錯的選擇，只是用戶群還太小。