設(shè)計(jì)模式在C語(yǔ)言中的應(yīng)用--讀nginx源碼（轉(zhuǎn)）

市面上的“設(shè)計(jì)模式“書(shū)籍文章，皆針對(duì)Java/C++/C#等面向?qū)ο笳Z(yǔ)言，似乎離開(kāi)了面向?qū)ο蟮姆N種特性，設(shè)計(jì)模式就無(wú)法實(shí)現(xiàn)，沒(méi)有用武之地了。

是這樣嗎？設(shè)計(jì)模式的概念是從建筑領(lǐng)域引入的，本身從沒(méi)歧視過(guò)面向過(guò)程編程語(yǔ)言，它只是對(duì)一類(lèi)問(wèn)題的普遍解決方案而已。面向?qū)ο笳Z(yǔ)言因?yàn)橛蓄?lèi)、多態(tài)等特點(diǎn)，使得開(kāi)發(fā)者們?nèi)菀走_(dá)到：隱藏細(xì)節(jié)、封裝變化，而這與設(shè)計(jì)模式的目的比較一致，所以大師們愛(ài)把設(shè)計(jì)模式與面向?qū)ο笳Z(yǔ)言二位一體的使用。然而，存在即合理，C語(yǔ)言直到今日仍然在大型軟件工程中擔(dān)綱主角，其種種設(shè)計(jì)方法其實(shí)與我們通常見(jiàn)到的設(shè)計(jì)模式本質(zhì)是相同的。例如nginx這個(gè)純C語(yǔ)言寫(xiě)就的的高性能WEB服務(wù)器，就有許多地方使用到了市面書(shū)籍提到的設(shè)計(jì)模式。下面通過(guò)nginx源碼來(lái)看看C語(yǔ)言是怎么做的。當(dāng)然，UML圖都是我根據(jù)代碼意圖所畫(huà)，并不準(zhǔn)確（C語(yǔ)言真沒(méi)法畫(huà)UML），只用于方便理解，呵呵。

strategy模式：

該模式用于客戶(hù)代碼在“無(wú)知”狀態(tài)下，可以使用種種不同的實(shí)現(xiàn)。下面我們以nginx對(duì)網(wǎng)絡(luò)IO操作的封裝部分來(lái)看看C語(yǔ)言的實(shí)現(xiàn)吧。

設(shè)計(jì)模式就是通過(guò)封裝變化來(lái)解耦，所以，我們先要找出網(wǎng)絡(luò)IO操作的變化點(diǎn)來(lái)。nginx是跨平臺(tái)的，它會(huì)支持linux、freebsd、solaris等操作系統(tǒng)，而每個(gè)操作系統(tǒng)的網(wǎng)絡(luò)IO操作是不同的，這就是變化點(diǎn)了。

 

所以，nginx首先定義了ngx_os_io_t來(lái)封裝這些變化。

 

typedef struct { ngx_recv_pt recv; ngx_recv_chain_pt recv_chain; ngx_recv_pt udp_recv; ngx_send_pt send; ngx_send_chain_pt send_chain; ngx_uint_t flags; } ngx_os_io_t;
這里有五個(gè)函數(shù)指針（*_pt都是函數(shù)指針）和一個(gè)變量，用于收發(fā)網(wǎng)絡(luò)數(shù)據(jù)，我把它理解為OO中的abstract class（每個(gè)ngx_os_io_t定義的變量都會(huì)重新實(shí)現(xiàn)這五個(gè)函數(shù)）。

 

擁有函數(shù)指針的struct，我通常認(rèn)為它們是OO中的abstract class，實(shí)現(xiàn)它們的文件（一堆函數(shù)）要對(duì)應(yīng)到OO上，我則喜歡把它們當(dāng)做子類(lèi)來(lái)看。對(duì)于void*這樣的成員，要根據(jù)意圖來(lái)看了，通常我會(huì)轉(zhuǎn)換成聚合加繼承的關(guān)系。

ngx_io會(huì)在相應(yīng)的ngx_os_specific_init方法中，來(lái)策略性的選擇到底使用哪個(gè)實(shí)現(xiàn)。客戶(hù)代碼只需要簡(jiǎn)單的調(diào)用ngx_io中的方法即可。

adapter模式：

這個(gè)模式用以適配接口，通常都是我們已經(jīng)定義好一種接口了，有一個(gè)新的實(shí)現(xiàn)卻有著不同的接口，接下來(lái)adapter就開(kāi)始發(fā)力了。下面我們?nèi)匀灰詎ginx對(duì)網(wǎng)絡(luò)IO操作的封裝部分來(lái)看。

linux平臺(tái)下可能存在普通的IO或者異步IO方式。我們?cè)谧畛跻呀?jīng)封裝好ngx_os_io_t接口了，客戶(hù)代碼都是這么直接使用的。現(xiàn)在linux實(shí)現(xiàn)了異步IO，而它的調(diào)用方式與普通的讀寫(xiě)IO接口完全不同，所以，如果要支持aoi就需要一層adapter來(lái)適配ngx_os_io_t，這就是adapter方式了。

上圖中，ngx_os_aio適配了原生的異步IO接口，這樣，用戶(hù)代碼仍然像以前一樣，只要直接使用ngx_io中的五個(gè)接口方法，當(dāng)nginx的IO部分支持linux aio后，用戶(hù)代碼不需要修改。

bridge橋模式：

橋模式用于將抽象和實(shí)現(xiàn)分離，各自都能獨(dú)立的變化。下面以nginx的核心概念module舉例，雖然有些牽強(qiáng)，因?yàn)閚ginx的代碼從來(lái)沒(méi)這么用過(guò)：通常都是一個(gè)抽象module context只對(duì)應(yīng)著一個(gè)實(shí)現(xiàn)module來(lái)用，但是，畢竟這種結(jié)構(gòu)下還是可以達(dá)到抽象與實(shí)現(xiàn)分離的目的，橋模式只好對(duì)應(yīng)到這上面了。

nginx是以module的概念貫穿始終的。它有一個(gè)基本的抽象層ngx_core_module_t（從意圖上判斷，context有抽象接口的功能，雖然簡(jiǎn)單從語(yǔ)法上看不出）。然后，nginx module有三個(gè)基本類(lèi)型，分別是event（處理各種事件模型，如epoll/select等），http（處理各種http協(xié)議的事件），mail（處理mail相關(guān)的事件）。針對(duì)每種類(lèi)型的module，都有許多個(gè)實(shí)現(xiàn)，比如event module就有9個(gè)實(shí)現(xiàn)，這里的每個(gè)實(shí)現(xiàn)其實(shí)也是個(gè)子類(lèi)。

但是，在我們理解橋模式時(shí)，這些子類(lèi)暫時(shí)要被看成是event module的實(shí)例。代碼中看，像ngx_epoll_module這樣的子類(lèi)中，還是把一些通用的細(xì)節(jié)隱藏給ngx_event_core_module來(lái)做（管理這個(gè)詞更合適）了。從這個(gè)角度可以認(rèn)為，通過(guò)context接口，把三個(gè)基本module實(shí)現(xiàn)分開(kāi)了。來(lái)看看類(lèi)圖：

nginx自己用時(shí)，是以ngx_module_t中的type成員來(lái)決定使用哪個(gè)實(shí)現(xiàn)的。目前的nginx代碼中，如果用了一種接口就一定會(huì)指定相應(yīng)的type。可是實(shí)際上，這也可以用來(lái)展示橋模式。以事件module為例來(lái)看看：

由于UML本就是針對(duì)OO語(yǔ)言的，所以以上我畫(huà)的類(lèi)圖都比較牽強(qiáng)，什么是繼承？什么是聚合？在C語(yǔ)言中，往往都是通過(guò)幾個(gè)函數(shù)指針，或者void*指針實(shí)現(xiàn)各種封裝和多態(tài)。沒(méi)有什么語(yǔ)法上的關(guān)聯(lián)，我就只能從代碼意圖中來(lái)判斷了。而代碼意圖這個(gè)比較虛，因?yàn)椴煌慕嵌壤斫獬鰜?lái)都不一樣，所以這個(gè)確實(shí)不好畫(huà)。太靈活了點(diǎn)，我只能從一個(gè)便于說(shuō)明的角度來(lái)看，例如：上面的ngx_devpoll_module其實(shí)就是一個(gè)ngx_module_t，呵呵，但是，實(shí)際上它最關(guān)心的是ngx_event_actions_t的實(shí)現(xiàn)，如果完全根據(jù)語(yǔ)法來(lái)看，根本說(shuō)不通的。但從代碼意圖中看，這些module并不關(guān)心ngx_module_t，所以我認(rèn)為，它們只是在實(shí)現(xiàn)ngx_event_module_t了。

當(dāng)然以上只是一家之言，不必當(dāng)真，如果對(duì)nginx源碼有研究的話(huà)，歡迎各位拍磚。

客觀的說(shuō)，C語(yǔ)言確實(shí)在封裝上很差，就像nginx，如果我們要開(kāi)發(fā)一個(gè)處理http協(xié)議的module嵌入進(jìn)nginx進(jìn)程，必須了解ngx_http_module里到底做了什么，真沒(méi)隱藏啥細(xì)節(jié)，module開(kāi)發(fā)者們表示很郁悶。上面的這些設(shè)計(jì)模式，只是做到了代碼上的解藕。如果nginx用C++寫(xiě)的話(huà)，我相信，現(xiàn)在第三方module都能數(shù)以萬(wàn)計(jì)了。


原文地址：
http://blog.csdn.net/russell_tao/article/details/7220237

posted @ 2012-02-01 18:01 xuht 閱讀(506) | 評(píng)論 (0) | 編輯 收藏

VC2008中影響exe大小和速度的全部編譯選項(xiàng)(轉(zhuǎn))

 我再次強(qiáng)調(diào)，完全脫離編程環(huán)境的C/C++學(xué)習(xí)方法，不是好的方法，現(xiàn)在所謂的環(huán)境中立理論就是“什么都不學(xué)”理論，VC、GCC，主流的就兩個(gè)，精通其中一個(gè)就能吃遍天下，教材里就應(yīng)該選擇一個(gè)大講特講！

    作為VC的代表，今天我給大家介紹VC中的編譯器選項(xiàng)，全面介紹不需要，MSDN里從頭到尾都介紹完了，今天我只講對(duì)生成的exe文件大小和速度有影響的。

    用VC就得用IDE，我也以IDE的工程設(shè)置里面的排列順序介紹，某些選項(xiàng)需要自己手動(dòng)添加的最后介紹，我后面說(shuō)的默認(rèn)值是release的，debug版本一般不需要調(diào)選項(xiàng)。

項(xiàng)目 - 屬性 - 配置屬性 - C/C++，這是編譯器選項(xiàng)。

優(yōu)化：
    通常，算法程序選擇最大化速度(/O2)，界面程序選擇最小化大小(/O1)，可以獲得最佳的效果。
    優(yōu)選大小或速度，只有在使用完全優(yōu)化(/Ox)時(shí)才有效，完全優(yōu)化一般不推薦使用，用處就是可以生成速度與/O2基本相當(dāng)，但是體積更小的代碼（選速度優(yōu)先的話(huà)）。
    其他幾個(gè)選項(xiàng)實(shí)際上已包含在/O1、/O2之中，具體請(qǐng)看MSDN。

代碼生成：
    啟用字符串池(/GF)，會(huì)將相同的字符串合并，當(dāng)然可以減小空間占用，雖然本項(xiàng)目默認(rèn)沒(méi)有打開(kāi)，但是默認(rèn)的/Zi選項(xiàng)會(huì)自動(dòng)打開(kāi)/GF，這里打不打開(kāi)一樣。
    啟用C++異常：該項(xiàng)默認(rèn)打開(kāi)，在C++項(xiàng)目中（比如MFC中），會(huì)大大增加程序體積，增加約30%，關(guān)閉并不代表try不能用了，但會(huì)一定程度上降低健壯性，對(duì)于空間要求較高的程序，建議關(guān)閉。對(duì)于正式項(xiàng)目，請(qǐng)參見(jiàn)MSDN，看看會(huì)不會(huì)造成不利影響。
    運(yùn)行庫(kù)：默認(rèn)多線(xiàn)程DLL(/MD)，體積最優(yōu)的方案，如果對(duì)方?jīng)]有VS運(yùn)行時(shí)庫(kù)，選擇/MT會(huì)將C/C++運(yùn)行庫(kù)靜態(tài)編譯，體積增加不少，因此，我的選擇一般是程序與redist包一起發(fā)布，也就幾M，而且以后永遠(yuǎn)可以接受/MD版本了。
    緩沖區(qū)安全檢查：關(guān)閉的話(huà)，減少0.5K~1K體積（默認(rèn)情況，VC的段長(zhǎng)度512字節(jié)，因此程序體積變化的最小單位是0.5K）。
    啟用增強(qiáng)指令集：真想用SSE3的話(huà)去用Intel C++，VS2008只支持到SSE2，而且，在我的機(jī)器上貌似使用默認(rèn)設(shè)置就能達(dá)到選擇SSE2的相同速度，如果安裝了Intel C++ 11，可集成與VS2008，同樣的地方選擇SSE3效果超群。
    浮點(diǎn)模型：精確還是快速理論上肯定對(duì)速度有影響，但是我極少使用浮點(diǎn)編程，我的方向是系統(tǒng)、安全和密碼，都是整數(shù)的天下。

高級(jí)：
    編譯為C還是C++影響不大，這充分說(shuō)明了C++簡(jiǎn)單面向?qū)ο筇匦院虲效率差不多（如重載，默認(rèn)情況下，編譯器會(huì)檢查擴(kuò)展名決定目標(biāo)代碼類(lèi)型，對(duì)于cpp文件，所有的函數(shù)都會(huì)編譯為可重載的類(lèi)型，但是對(duì)效率幾乎沒(méi)有影響）。

項(xiàng)目 - 屬性 - 配置屬性 - 鏈接器，這是鏈接器選項(xiàng)。

輸入：
    忽略庫(kù)只有在庫(kù)沖突時(shí)候才有用，VC絕對(duì)不會(huì)連接沒(méi)有調(diào)用到的庫(kù)，哪怕你明確指定了。

清單文件：
    完全使用API編程可以不生成清單。減少約1K體積。
    一般情況下，關(guān)閉UAC的那一項(xiàng)，可減少0.5K。

調(diào)試：
    關(guān)閉“生成調(diào)試信息(/DEBUG)”，根據(jù)程序規(guī)模，可減少1K~幾十K。

優(yōu)化：
    release模式，默認(rèn)情況下已經(jīng)該組已經(jīng)最優(yōu)了，/OPT:REF和/OPT:ICF已經(jīng)打開(kāi)，注意，VS2005、VS2008中Windows 98優(yōu)化那一項(xiàng)沒(méi)用，不像VC6取消Windows 98優(yōu)化可以大大減小體積。因?yàn)閂S2005、VS2008中段大小已經(jīng)是512字節(jié)，VC6默認(rèn)4K。

高級(jí)：
    指定入口點(diǎn)，可以大大減小程序體積，但是不調(diào)用CRT的入口無(wú)法自動(dòng)處理參數(shù)，可用GetCommandLine和CommandLineToArgvW這兩個(gè)API來(lái)處理參數(shù)。
    隨機(jī)基址：默認(rèn)模式啟用映像隨機(jī)化(/DYNAMICBASE)，會(huì)大大增加程序體積，因?yàn)檫@是個(gè)增加程序防反編譯、防破解能力的選項(xiàng)。如無(wú)需求，請(qǐng)選擇禁用映像隨機(jī)化(/DYNAMICBASE:NO)，文件越大，體積縮小越明顯，至少30%。

命令行：
    小程序，可以指定段大小/ALIGN，/O1編譯的化最小可以使用/ALIGN:4，這個(gè)選項(xiàng)不推薦，第一有點(diǎn)規(guī)模的程序就不能用太小的段，/O2優(yōu)化的也不能用小段，而且默認(rèn)的512字節(jié)段可以使用UPX壓縮，再小就不能了，除非咱們編譯那種600字節(jié)的Hello World，這個(gè)選項(xiàng)意義不大，因此微軟才沒(méi)有給他一個(gè)圖形選項(xiàng)。
    同樣，編譯600字節(jié)hello world還需要/merge合并段選項(xiàng)，同樣不推薦使用。

    有些選項(xiàng)VS2005和VS2003沒(méi)有，VS2003還包括幾個(gè)VS2008廢除的選項(xiàng)，實(shí)際上VC里面程序優(yōu)化效率最高的個(gè)人感覺(jué)是VS2003。VC6的界面差別比較大，選項(xiàng)有一定差異，但畢竟都是微軟的產(chǎn)品，差別不大，甚至于MASM這個(gè)匯編編譯器，連接選項(xiàng)大都與VC相同……

    再說(shuō)一點(diǎn)，VS2008SP1的MFC工程會(huì)自動(dòng)生成巨大的256*256真彩圖標(biāo)，因此默認(rèn)的MFC對(duì)話(huà)框程序都有近100K，建議刪除多余的圖標(biāo)，配合上述選項(xiàng)能減到10多K


原文地址：http://blog.csdn.net/jackyjkchen/article/details/4676635

posted @ 2011-10-13 16:10 xuht 閱讀(921) | 評(píng)論 (0) | 編輯 收藏