開發工具大比拚之Visual C++　vs.　Delphi(二) (轉)

開發工具大比拚之Visual C++　vs.　Delphi(二) (轉)[@more@] 

應用：MFC？有KFC流行嗎？
　　應用框架(Application Frame)，有時也稱為框架。Visual C++採用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫。(同樣，的VCL也不僅僅是一個庫，儘管它的名字叫“可視控制元件庫”。)你如果選擇了MFC，也就選擇了一種程式結構，一種風格。MFC早在 3.x的時代就出現了，那時的Visual C++還是16位的。經過這些年的不斷補充和完善，MFC已經十分成熟。但由於原型出現得比較早，MFC相比於VCL落後了一個時代。儘管對MFC的沒有停止，我也經常讀到“只要Windows不過時，MFC就不會過時”之類觀點的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。其實MFC是和OWL同一個時代的產物。OWL已經不在了，MFC怎能不“居安思危”呢？如果MFC青春永駐，微軟的開發人員也不會“私自”開發出基於ATL的WTL呀。當然，WTL的地位不能和MFC比，它並不是微軟官方支援的框架，封裝的功能也相當有限。但至少也反襯出了MFC存在的不足。
　　我以為，最能體現一個應用程式框架的先進性的是它的委託模型，即對Windows訊息的封裝機制。對Windows 的封裝就不用說了吧。大同小異，也沒什麼技術含量。如果高興，你也可以自己寫一個類庫來封裝。但對Windows訊息機制的封裝就不是那麼容易的了。最自然的封裝方式是採用虛成員。如果要響應某個訊息就過載相應的虛擬函式。但出乎我的意料，MFC採用的是“古老”的宏定義方法。用宏定義方法的好處是省去了虛擬函式VTable的開銷。(由於Windows的訊息種類很多，開銷不算太小。)不過帶來的缺點就是對映不太直觀。對於MFC，則是“太不直觀”了。它的訊息對映程式碼雖然是可見的，但“勸君莫碰”。好在VC的ClassWizard可以自動生成訊息對映程式碼，使用起來還算方便。但和VCL的委託模型相比，MFC的對映方法就顯得太落後了。而Delphi的 Pascal因為沒有“標準負擔”，語言引入了、事件處理、屬性等新特性。由於功夫做在級，生成的就顯得十分簡潔。似乎VC是“讓框架遷就語言”，而Delphi是“讓語言遷就框架”。
　　我想舉一個對字串操作的封裝的例子來說明MFC和VCL的優缺點。在MFC中，CStringList類有加入、獲取、刪除等功能，但VCL的TStringList類除了上述功能還有排序、從逗號分隔的字串讀入、流輸入輸出等功能。但同樣的字串替換功能，VCL的StringReplace要比MFC的CString::Replace慢2~3倍。總的來說，VCL的封裝比MFC更為高層，更為抽象，但不可避免地帶來的問題是某些部分比MFC略低。這就象低階語言(如)的執行效率比高階語言(如Basic)高，但程式設計效率較低。魚和熊掌不可兼得嘛。
　　VCL比之MFC的另一優點是對異常處理的支援，而一大缺點是對多執行緒支援差。VCL的大部分都不是針對多執行緒的。雖說VCL提供了簡化多執行緒操作的類，但只是工作者執行緒(worker threads)使用起來比較簡單。如果執行緒要和介面打交道的話事情就變得麻煩了，因為除了應用程式的主執行緒，任何執行緒不能訪問任何可視的VCL部件。你不得不使用Synchronize方法等待主執行緒處理它的訊息，然後在主執行緒中訪問VCL部件。而MFC就沒有這樣的限制。:namespace prefix = o ns = "urn:schemas--com::office" />

 

穩定性與完善程度：VC是老大哥
　　VC要比Delphi穩定和完善。VC的發展歷史比Delphi長，微軟的總體實力比Inprise強。VC的框架MFC經歷了那麼多年的發展和完善，功能非常全面，而且十分穩定，很少。其中你可能遇到的bug更少。而且有第三方的專門工具幫助你避開這些bug。如此規模的一個類庫，能做到這一點不容易。不要小看了這一點，很多專業程式設計師就是為這個選擇VC的。因為儘管VCL比MFC的抽象程度高，封裝較為高層，但由此帶來的開發效率的提高對高手來說畢竟是有限的。而如果你遇到一個怪問題，了半天，發現不是你的程式碼有錯，而是VCL的bug，你作何感想？雖說遇到這類問題的可能性很小，但對VCL的形象的影響可不小。Delphi的太佔資源，啟動速度太慢，和某些驅動程式衝突，VCL中有bug，偵錯程式不夠健壯，對不穩定的第三方控制元件沒有防護措施……問題多多，在這方面Delphi不如VC。希望Inprise能更上一層樓。順便說一下，我在網上看到有些人極言Delphi的不穩定，說幾分鐘出現20多次操作。Delphi的確不如Visual C++穩定，但也不至於如此呀。我估計是那位朋友的Delphi裝了某些有問題的第三方控制元件，導致了Delphi的頻頻出錯。不妨卸下那些控制元件試試？

 

可移植性：立足現實，放眼未來
　　Inprise正在開發Delphi的版本，代號為Kylix。也許透過Kylix，用VCL構架編寫的Windows程式向Linux移植成為可能。但這只是可能。因為在目前Inprise的相容性工作做得並不好。低版本的Delphi不能使用高版本的VCL元件(這還別去說它)，而高版本的Delphi竟然不能使用低版本的VCL元件。真是豈有此理，我很少看見有不向下二進位制相容的。如果不能執行95的程式，Windows 95不能執行3.x的程式，Win 3.x不能執行DOS程式，你還會用Windows嗎？如果Windows 95的程式必須經過重新編譯才能在98下執行，98會賣得那麼好嗎？“同門兄弟”C++Builder和Delphi也不能互相使用對方的元件，甚至同一套VCL庫的名也不一樣。所以一個元件有for D1/D2/D3/D4/D5/C1/C3/C4/C5這些不同版本是常有的事，而且隨著Delphi和C++Builder版本的升級可能還會增加。希望Inprise能先解決同門兄弟的相容性問題。而微軟的VC就沒有這類問題。MFC1.0的程式也可以毫無障礙地在VC6.0下編譯透過。

 

整合介面：宏觀與微觀
　　就大處說，VC的整合介面是不如Delphi的。Delphi僅僅一個Object Inspector就可以將VC的一堆Wizards比下去，何況它還有Code Explorer、ToDo List等。但從小處，又可以看出Delphi的不成熟。比如“自動完成”功能的智慧化程度和提示詳細程度不如VC，響應速度也沒有VC快。

Visual C++所帶的MSDN是一部“開發者的百科全書”，資訊龐大，查詢方便，這方面比Delphi更加專業。很多幫助項都有源程式示範。

Delphi的OpenTools是完全面向第三方的開放系統，開發者可以修改很多Borland公司自身的功能，從IDE的可擴充性上說Delphi更好。

 

除錯：細微之處見真功

Visual C++和Delphi的除錯功能都非常強大，同時都具有單步視覺化除錯、斷點跟蹤、執行時改變變數、滑鼠指向可以得到變數值等等功能。對DLL的輸入輸出也能方便的管理，能夠進行原始碼級別的除錯。

相對而言，Visual C++能夠更加方便地看到變數的變化情況，這包括對結構可以展開成資料樹，從而瞭解每一個變數的值，每一步除錯，變化了的變數會加紅，從而使除錯更加方便。另外，Visual C++的塊察看比Delphi也要方便。

當然，Delphi也有很多體貼的細微之處，比如線上程除錯的時候，Delphi能夠很方便地察看執行緒的變化，Visual C++確必須要彈出一個對話方塊。