Visual C++采用的框架是MFC，但是許多人對MFC還不算很了解，其實這個並不難理解，MFC是實際上是微軟提供的,用於在C++環境下編寫應用程序的一個框架和引擎，更好的為Visual C++進行工作的框架。
這本來是優點，但很有意思的是，正因為如此，微軟寫MFC時必須考慮最大限度減少對語言本身的改動，而把功夫下在源代碼級，以便能盡可能支持ANSI等標准，結果導致MFC的封裝復雜而不直觀。
太多的宏定義和含義模糊且自動生成、不得改動的注釋使MFC乃至VC讓很多新手望而生畏，不敢"下水"深入學習。而Object Pascal幾乎是Inprise"專用"的，不必考慮"標准"問題，因此Inprise寫VCL時就把全部精力放在了結構與性能上，結果語言與框架的磨合程度非常好。VCL框架的結構清晰，VCL代碼的可讀性非常好。許多人說Delphi比較容易上手，也是這個緣故。天下沒有白吃的午餐。你要工業標准嗎？你要可移植性嗎(關於可移植性和兼容性，下文會詳細比較)？那麼請面對MFC的"天書"級代碼吧。
編譯和連接：The Need For Speed
不同的語言帶來的另一個不同是，編譯和連接的速度的不同，以及執行速度的不同。Delphi的編譯和連接速度，毫不誇張地說，比VC快幾十倍。即使把VC的Incremental Link選項打開，Delphi的編譯和連接速度仍比VC快好幾倍。並不是說微軟的編譯器不行，這是由C++的復雜性決定的。
模板的處理、預處理和宏的展開都是很費時的。前文不是提到Object Pascal沒有模板、預處理和宏嗎？這本來是缺點，但帶來的一個好處就是編譯速度極快。至於編譯完的二進制代碼，在打開相同的優化選項的情況下，Delphi和VC執行速度並沒有太大的差別。
為了克服編譯的速度問題，C++編譯器一般需要增強的連接器和預處理機制。但是預處理機制仍然存在若干問題：
1）程序調試的斷點行可能和代碼行不同；
2）沒有將最新的代碼信息綜合進去；
3）容易產生錯誤的邏輯；
4）因為讀錯文件頭而很容易產生類似"Unexpected End of File"的錯誤。
兩個編譯器有個共同點是都能識別無用的"死"代碼，比如一個沒有用的函數等等。編譯後的程序將不包含這些多余的信息。Delphi在這方面作得更加出色。它可以讓你在編輯器中可視化地提示出那行代碼是"活"的、那行代碼是"死"的。這樣你就能整理出最精簡的代碼。
Delphi在編譯後將在左邊顯示一個小藍點表示這行代碼是"活"的。Visual C++做不到這點。 Delphi編譯後可執行文件至少有200K如果不使用VCL，僅僅使用WinAPI，文件的大小將大大縮小）但是Visual C++編程使用MFC編譯後的可執行文件通常只有幾十K，主要是因為微軟已經將系統運行庫包含在Windows系統了Borland公司曾經和微軟協商這個接口，但是微軟利用操作系統的優勢不願意公開）。
同樣道理，使用BDE開發的的數據庫程序必須附帶3-5M的額外系統文件，也是非常不協調的。 非常有趣的是，Delphi能夠使用由C++ Builder創建的的OBJ文件，但是使用上受很大的局限性。最後，Visual C++的編譯和連接時的錯誤信息比Delphi要詳細和具體的多。特別是使用ATL開發更加如此。
應用框架：MFC？有KFC流行嗎？
應用程序框架(Application Frame)，有時也稱為對象框架。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的一個類庫(同樣，Delphi的VCL也不僅僅是一個控件庫，盡管它的名字叫"可視控件庫")。你如果選擇了MFC，也就選擇了一種程序結構，一種編程風格。
MFC早在Windows 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 API的封裝就不用說了吧。大同小異，也沒什麼技術含量。如果高興，你也可以自己寫一個類庫來封裝。但對Windows消息驅動機制的封裝就不是那麼容易的了。
最自然的封裝方式是采用虛成員函數。如果要響應某個消息就重載相應的虛函數。但出乎我的意料，MFC采用的是"古老"的宏定義方法。用宏定義方法的好處是省去了虛函數VTable的系統開銷(由於Windows的消息種類很多，開銷不算太小)。
不過帶來的缺點就是映射不太直觀。對於MFC，則是"太不直觀"了。它的消息映射代碼雖然是可見的，但"勸君莫碰"。好在VC的ClassWizard可以自動生成消息映射代碼，使用起來還算方便。但和VCL的委托模型相比，MFC的映射方法就顯得太落後了。而Delphi的Object 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)使用起來比較簡單。
如果線程要和界面打交道的話事情就變得麻煩了，因為除了應用程序的主線程，任何線程不能訪問任何可視的C++部件。你不得不使用Synchronize方法等待主線程處理它的消息，然後在主線程中訪問Visual C++部件。而MFC就沒有這樣的限制。
