建站
咨詢
售后
建站咨詢
新聞中心
Visual C++采用的框架是MFC，但是許多人對(duì)MFC還不算很了解，其實(shí)這個(gè)并不難理解，MFC是實(shí)際上是微軟提供的,用于在C++環(huán)境下編寫應(yīng)用程序的一個(gè)框架和引擎，更好的為Visual C++進(jìn)行工作的框架。
創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比旺蒼網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式旺蒼網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋旺蒼地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴。
這本來(lái)是優(yōu)點(diǎn)，但很有意思的是，正因?yàn)槿绱?，微軟寫MFC時(shí)必須考慮最大限度減少對(duì)語(yǔ)言本身的改動(dòng)，而把功夫下在源代碼級(jí)，以便能盡可能支持ANSI等標(biāo)準(zhǔn)，結(jié)果導(dǎo)致MFC的封裝復(fù)雜而不直觀。
太多的宏定義和含義模糊且自動(dòng)生成、不得改動(dòng)的注釋使MFC乃至VC讓很多新手望而生畏，不敢"下水"深入學(xué)習(xí)。而Object Pascal幾乎是Inprise"專用"的，不必考慮"標(biāo)準(zhǔn)"問(wèn)題，因此Inprise寫VCL時(shí)就把全部精力放在了結(jié)構(gòu)與性能上，結(jié)果語(yǔ)言與框架的磨合程度非常好。VCL框架的結(jié)構(gòu)清晰，VCL代碼的可讀性非常好。許多人說(shuō)Delphi比較容易上手，也是這個(gè)緣故。天下沒(méi)有白吃的午餐。你要工業(yè)標(biāo)準(zhǔn)嗎？你要可移植性嗎(關(guān)于可移植性和兼容性，下文會(huì)詳細(xì)比較)？那么請(qǐng)面對(duì)MFC的"天書"級(jí)代碼吧。
編譯和連接：The Need For Speed
不同的語(yǔ)言帶來(lái)的另一個(gè)不同是，編譯和連接的速度的不同，以及執(zhí)行速度的不同。Delphi的編譯和連接速度，毫不夸張地說(shuō)，比VC快幾十倍。即使把VC的Incremental Link選項(xiàng)打開，Delphi的編譯和連接速度仍比VC快好幾倍。并不是說(shuō)微軟的編譯器不行，這是由C++的復(fù)雜性決定的。
模板的處理、預(yù)處理和宏的展開都是很費(fèi)時(shí)的。前文不是提到Object Pascal沒(méi)有模板、預(yù)處理和宏嗎？這本來(lái)是缺點(diǎn)，但帶來(lái)的一個(gè)好處就是編譯速度極快。至于編譯完的二進(jìn)制代碼，在打開相同的優(yōu)化選項(xiàng)的情況下，Delphi和VC執(zhí)行速度并沒(méi)有太大的差別。
為了克服編譯的速度問(wèn)題，C++編譯器一般需要增強(qiáng)的連接器和預(yù)處理機(jī)制。但是預(yù)處理機(jī)制仍然存在若干問(wèn)題：
1）程序調(diào)試的斷點(diǎn)行可能和代碼行不同；
2）沒(méi)有將最新的代碼信息綜合進(jìn)去；
3）容易產(chǎn)生錯(cuò)誤的邏輯；
4）因?yàn)樽x錯(cuò)文件頭而很容易產(chǎn)生類似"Unexpected End of File"的錯(cuò)誤。
兩個(gè)編譯器有個(gè)共同點(diǎn)是都能識(shí)別無(wú)用的"死"代碼，比如一個(gè)沒(méi)有用的函數(shù)等等。編譯后的程序?qū)⒉话@些多余的信息。Delphi在這方面作得更加出色。它可以讓你在編輯器中可視化地提示出那行代碼是"活"的、那行代碼是"死"的。這樣你就能整理出最精簡(jiǎn)的代碼。
Delphi在編譯后將在左邊顯示一個(gè)小藍(lán)點(diǎn)表示這行代碼是"活"的。Visual C++做不到這點(diǎn)。 Delphi編譯后可執(zhí)行文件至少有200K（如果不使用VCL，僅僅使用WinAPI，文件的大小將大大縮?。┑荲isual C++編程使用MFC編譯后的可執(zhí)行文件通常只有幾十K，主要是因?yàn)槲④浺呀?jīng)將系統(tǒng)運(yùn)行庫(kù)包含在Windows系統(tǒng)了（Borland公司曾經(jīng)和微軟協(xié)商這個(gè)接口，但是微軟利用操作系統(tǒng)的優(yōu)勢(shì)不愿意公開）。
同樣道理，使用BDE開發(fā)的的數(shù)據(jù)庫(kù)程序必須附帶3-5M的額外系統(tǒng)文件，也是非常不協(xié)調(diào)的。 非常有趣的是，Delphi能夠使用由C++ Builder創(chuàng)建的的OBJ文件，但是使用上受很大的局限性。最后，Visual C++的編譯和連接時(shí)的錯(cuò)誤信息比Delphi要詳細(xì)和具體的多。特別是使用ATL開發(fā)更加如此。
應(yīng)用框架：MFC？有KFC流行嗎？
應(yīng)用程序框架(Application Frame)，有時(shí)也稱為對(duì)象框架。Visual C++采用的框架是MFC。MFC不僅僅是人們通常理解的一個(gè)類庫(kù)(同樣，Delphi的VCL也不僅僅是一個(gè)控件庫(kù)，盡管它的名字叫"可視控件庫(kù)")。你如果選擇了MFC，也就選擇了一種程序結(jié)構(gòu)，一種編程風(fēng)格。
MFC早在Windows 3.x的時(shí)代就出現(xiàn)了，那時(shí)的Visual C++還是16位的。經(jīng)過(guò)這些年的不斷補(bǔ)充和完善，MFC已經(jīng)十分成熟。但由于原型出現(xiàn)得比較早，MFC相比于VCL落后了一個(gè)時(shí)代。
盡管微軟對(duì)MFC的更新沒(méi)有停止，我也經(jīng)常讀到"只要Windows不過(guò)時(shí)，MFC就不會(huì)過(guò)時(shí)"之類觀點(diǎn)的文章，但就象Inprise(原Borland)的OWL框架的淡出一樣，MFC的淡出也是早晚的事。其實(shí)MFC是和OWL同一個(gè)時(shí)代的產(chǎn)物。
OWL已經(jīng)不在了，MFC怎能不"居安思危"呢？如果MFC青春永駐，微軟的開發(fā)人員也不會(huì)"私自"開發(fā)出基于ATL的WTL呀。當(dāng)然，WTL的地位不能和MFC比，它并不是微軟官方支持的框架，封裝的功能也相當(dāng)有限。但至少也反襯出了MFC存在的不足。
我們以為，最能體現(xiàn)一個(gè)應(yīng)用程序框架的先進(jìn)性的是它的委托模型，即對(duì)Windows消息的封裝機(jī)制。對(duì)Windows API的封裝就不用說(shuō)了吧。大同小異，也沒(méi)什么技術(shù)含量。如果高興，你也可以自己寫一個(gè)類庫(kù)來(lái)封裝。但對(duì)Windows消息驅(qū)動(dòng)機(jī)制的封裝就不是那么容易的了。
最自然的封裝方式是采用虛成員函數(shù)。如果要響應(yīng)某個(gè)消息就重載相應(yīng)的虛函數(shù)。但出乎我的意料，MFC采用的是"古老"的宏定義方法。用宏定義方法的好處是省去了虛函數(shù)VTable的系統(tǒng)開銷(由于Windows的消息種類很多，開銷不算太小)。
不過(guò)帶來(lái)的缺點(diǎn)就是映射不太直觀。對(duì)于MFC，則是"太不直觀"了。它的消息映射代碼雖然是可見的，但"勸君莫碰"。好在VC的ClassWizard可以自動(dòng)生成消息映射代碼，使用起來(lái)還算方便。但和VCL的委托模型相比，MFC的映射方法就顯得太落后了。而Delphi的Object Pascal因?yàn)闆](méi)有"標(biāo)準(zhǔn)負(fù)擔(dān)"，語(yǔ)言引入了組件、事件處理、屬性等新特性。由于功夫做在編譯器級(jí)，生成的源代碼就顯得十分簡(jiǎn)潔。
似乎VC是"讓框架遷就語(yǔ)言"，而Delphi是"讓語(yǔ)言遷就框架"。 我想舉一個(gè)對(duì)字符串操作的封裝的例子來(lái)說(shuō)明MFC和VCL的優(yōu)缺點(diǎn)。在MFC中，CStringList類有加入、獲取、刪除等功能，但VCL的TStringList類除了上述功能還有排序、從逗號(hào)分隔的字串讀入、流輸入輸出等功能。
但同樣的字符串替換功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。總的來(lái)說(shuō)，VCL的封裝比MFC更為高層，更為抽象，但不可避免地帶來(lái)的問(wèn)題是某些部分執(zhí)行效率比MFC略低。這就象低級(jí)語(yǔ)言(如匯編)的執(zhí)行效率比高級(jí)語(yǔ)言(如Basic)高，但編程效率較低。魚和熊掌不可兼得嘛。
VCL比之MFC的另一優(yōu)點(diǎn)是對(duì)異常處理的支持，而一大缺點(diǎn)是對(duì)多線程支持差。VCL的大部分都不是針對(duì)多線程優(yōu)化的。雖說(shuō)VCL提供了簡(jiǎn)化多線程操作的類，但只是工作者線程(worker threads)使用起來(lái)比較簡(jiǎn)單。
如果線程要和界面打交道的話事情就變得麻煩了，因?yàn)槌藨?yīng)用程序的主線程，任何線程不能訪問(wèn)任何可視的C++部件。你不得不使用Synchronize方法等待主線程處理它的消息，然后在主線程中訪問(wèn)Visual C++部件。而MFC就沒(méi)有這樣的限制。
網(wǎng)站題目：淺析VisualC++如何選取對(duì)象框架
當(dāng)前路徑：http://m.fisionsoft.com.cn/article/dheochi.html
