數據庫開發：delphi一枝獨秀
數據庫支持是delphi的強項。這主要體現在delphi與bde的無縫集成，以及delphi提供的那一大堆現成的數據庫操作控件。這是vc望塵莫及的。目前delphi支持bde、ado、interbase三種數據庫訪問方式。所有的方式都能拖拉到應用程序中實現可視化操作。正是因為delphi對數據庫類的包裝，使得用戶操作數據庫不像在visual c++中必須從開始到最後都要干預。明顯地提高了開發速度。
在delphi中使用webbroker控件還能很方便地構造出基於數據庫的web頁面，通過html管理web數據庫。
visual c++訪問數據主要通過ado和oledb，很多activex控件也能添加數據庫功能。但是沒有像paradox這樣的桌面數據庫，access相對太輕量級了。也許sql server是不錯的選擇。
com：新技術的力量
com是組件對象模型的縮寫。它是ole和activex技術的基礎，com定義了一組api和一個二進制標准，讓不同的編程語言、不同平台的彼此獨立的對象相互進行通訊。
com是microsoft制訂的行業標准。但是，delphi也為com提供了強大的語言支持。支持接口、variant、寬字符串功能。這些對com的封裝確實比c++更方便。比如在c++（沒有類框架）進行com編程時，變體定義為oaidl.h文件中德variant結構。要處理變體，必須手工調整oleaut32.dll中variantxxxx() api函數對其進行初始化和管理，如variantinit()、variantcopy()、variantclear()等等。
visual c++實現com編程有一種特殊的方法就是使用atl。atl使用visual c++特有的多重繼承來實現com接口。雖然不見得實現com服務和控制更容易，但是atl和最新com技術的接口，基於模板的構造都比delphi強。atl更有利於建立小巧、快捷的com組件程序。
按照目前通用的觀點，visual c++應用到com服務程序更有優勢，delphi應用到com組件程序更合適。
昨天，今天，明天
技術的進步在很多時候是此消彼長的。當初borland的turbo c和borland c++幾乎是c/c++程序員唯一的選擇。微軟的quick c(現在還有人知道這個產品嗎？)和microsoft c/c++從來也沒有成為過主流。但borland c++又流行了多少年呢？不久就被新崛起的microsoft visual c/c++壓下去了。於是inprise(原borland)揀起了當年turbo pascal和borland pascal的輝煌(事實上borland的成名作就是第一個pascal編譯器)，全力推出了delphi。delphi當初推出時被稱為vb殺手，但vb現在仍然活得挺好。畢竟微軟是靠basic起家的嘛，vb不是那麼容易被打敗的。inprise想了想不和vb爭了，使用delphi的ide和vcl配上c++語言，推出了c++builder，又向visual c++的市場發起了夾攻。c++builder似乎是個不錯的折衷選擇了？再仔細想想！c++builder的優點delphi都有，但delphi的優點c++builder未必有。比如c++builder的編譯速度比vc還慢，哪能和delphi比？而且因為vcl是object pascal寫的，c++語言和vcl磨合得並不好。c++builder的bug比delphi還多，甚至sample代碼中還有錯。vcl的部分功能不能使用，要靠嵌入pascal代碼訪問。c++builder可用的第三方控件遠沒有delphi多。
唉，真是金無足赤。microsoft和inprise，誰會笑在最後呢？
魚和熊掌：艱難的選擇
選擇一個開發工具依賴於很多不同的因素，每個人都能因為某種語言的某個缺陷而放棄學習或使用這種語言。任何程序員都希望自己喜歡的工具能達到理想的境界，通過上面不完善的比較，我想大家都有自己的看法。我們認為影響大家選擇開發語言的因素主要包括：
１）哪門語言更容易入門？
學習一種語言需要投入大量的時間和精力。開發程序的開發成本是值得考慮的現實。一個熟練的delphi程序員和一個熟練的vc程序員工作效率是一樣的。但是，成為熟練的程序員必須很快掌握一門語言的技巧。不幸的是，目前熟練的visual c++程序員是十裡挑一。相對而言，delphi更適合初學者。
２）哪門語言有更多可繼承的代碼？
語言代碼的可重用性是加快開發效率明顯方面，從早期的過程、函數到現在的組件技術都是朝這個目標在奮斗。這兩種語言對代碼重用的理解是不一樣的，delphi主要通過vcl控件來實現代碼重用，visual c++實現起來就比較復雜。
３）語言自身的本性。
就技術(主要指應用框架)來說，delphi目前領先於visual c++。但穩定性和健壯性的不足又讓我對inprise“想說愛你不容易”。而vc盡管發展到今日已十分完善，但mfc框架已是明日黃花了。如果不使用mfc，目前又沒有合適的替代品。
根據你的需要和實際情況做選擇吧。實際上visual c++和delphi也不是單單競爭關系。它們在許多領域並不重疊，甚至是互補的。到底怎樣取捨，要根據你的項目特性決定。如果你開發系統底層的東西，需要極好的兼容性和穩定性，選visual c++吧。你可以只調用windows的各種api，不用mfc。如果你寫傳統的windows桌面應用程序，visual c++的mfc框架是“正統”的選擇；如果界面部分占這個應用程序代碼比例較大的話，或者delphi中有相關功能的控件的話，delphi是事半功倍的選擇。如果你為企業開發數據庫、信息管理系統等高層應用(“高層”是相對於“低層/底層”而言的，不是說技術高級或低級。)而且有比較緊的期限限制，選delphi比較好。如果你熟悉的語言是object pascal，又不打算學復雜的c++，那麼delphi幾乎是唯一的選擇。傳統的觀點是：delphi適合編寫internet/intranet、表格制圖、數據庫操作、高級用戶界面等等。visual c++適合編寫設備驅動、com服務程序、科學計算、控制台（console）程序、wince的應用和一些小的工具等等。應用范圍的不同要求好的程序員精通這兩門語言。
４）語言的前景和可擴充性。
delphi是inprise的旗艦產品之一，前景應當還是比較樂觀的，而且inprise已經在向linux進軍了，而微軟還遲遲沒有動作。遺憾的是，inprise公司delphi的創始人已經跳槽到微軟去主持visual j++項目了。但願對inprise沖擊不會太大。
微軟的visual c++的前景又怎樣呢？visual studio 7.0就要推出了。這一版本將加強網絡開發的特性。看來微軟雖然被判解體，開發實力可是一點沒打折扣。
另外，雖說mfc已稍顯落後，但不是說它不值得學。事實上，不學mfc就等於沒學vc。利用mfc框架開發程序仍然是目前開發桌面應用的主流模式，而且還會保持相當長的時間。微軟公司ceo史蒂夫·巴爾默(steve ballmer)曾說，.net流行還得等2~3年。那麼，mfc至少還有2~3年的生命空間。在技術日新月異的it界，2~3年實在是很長一段時間了。好好把握吧。即使你不使用mfc框架，花點時間看一下mfc的封裝機制對你熟悉c++的oop機制和windows底層功能也是很有好處的。而vcl的源代碼是object pascal的，對c/c++程序員就沒有這個“額外”的作用了。
