市面上的“設計模式“書籍文章，皆針對Java/C++/C#等面向對象語言，似乎離開了面向對象的種種特性，設計模式就無法實現，沒有用武之地了。
是這樣嗎？設計模式的概念是從建筑領域引入的，本身從沒歧視過面向過程編程語言，它只是對一類問題的普遍解決方案而已。面向對象語言因為有類、多態等特點，使得開發者們容易達到：隱藏細節、封裝變化，而這與設計模式的目的比較一致，所以大師們愛把設計模式與面向對象語言二位一體的使用。然而，存在即合理，C語言直到今日仍然在大型軟件工程中擔綱主角，其種種設計方法其實與我們通常見到的設計模式本質是相同的。例如nginx這個純C語言寫就的的高性能WEB服務器，就有許多地方使用到了市面書籍提到的設計模式。下面通過nginx源碼來看看C語言是怎么做的。當然，UML圖都是我根據代碼意圖所畫，并不準確（C語言真沒法畫UML），只用于方便理解，呵呵。
strategy模式：
該模式用于客戶代碼在“無知”狀態下，可以使用種種不同的實現。下面我們以nginx對網絡IO操作的封裝部分來看看C語言的實現吧。
設計模式就是通過封裝變化來解耦，所以，我們先要找出網絡IO操作的變化點來。nginx是跨平臺的，它會支持linux、freebsd、solaris等操作系統，而每個操作系統的網絡IO操作是不同的，這就是變化點了。
所以，nginx首先定義了ngx_os_io_t來封裝這些變化。
- 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;
這里有五個函數指針（*_pt都是函數指針）和一個變量，用于收發網絡數據，我把它理解為OO中的abstract class（每個ngx_os_io_t定義的變量都會重新實現這五個函數）。
擁有函數指針的struct，我通常認為它們是OO中的abstract class，實現它們的文件（一堆函數）要對應到OO上，我則喜歡把它們當做子類來看。對于void*這樣的成員，要根據意圖來看了，通常我會轉換成聚合加繼承的關系。
ngx_io會在相應的ngx_os_specific_init方法中，來策略性的選擇到底使用哪個實現。客戶代碼只需要簡單的調用ngx_io中的方法即可。
adapter模式：
這個模式用以適配接口，通常都是我們已經定義好一種接口了，有一個新的實現卻有著不同的接口，接下來adapter就開始發力了。下面我們仍然以nginx對網絡IO操作的封裝部分來看。
linux平臺下可能存在普通的IO或者異步IO方式。我們在最初已經封裝好ngx_os_io_t接口了，客戶代碼都是這么直接使用的。現在linux實現了異步IO，而它的調用方式與普通的讀寫IO接口完全不同，所以，如果要支持aoi就需要一層adapter來適配ngx_os_io_t，這就是adapter方式了。
上圖中，ngx_os_aio適配了原生的異步IO接口，這樣，用戶代碼仍然像以前一樣，只要直接使用ngx_io中的五個接口方法，當nginx的IO部分支持linux aio后，用戶代碼不需要修改。
bridge橋模式：
橋模式用于將抽象和實現分離，各自都能獨立的變化。下面以nginx的核心概念module舉例，雖然有些牽強，因為nginx的代碼從來沒這么用過：通常都是一個抽象module context只對應著一個實現module來用，但是，畢竟這種結構下還是可以達到抽象與實現分離的目的，橋模式只好對應到這上面了。
nginx是以module的概念貫穿始終的。它有一個基本的抽象層ngx_core_module_t（從意圖上判斷，context有抽象接口的功能，雖然簡單從語法上看不出）。然后，nginx module有三個基本類型，分別是event（處理各種事件模型，如epoll/select等），http（處理各種http協議的事件），mail（處理mail相關的事件）。針對每種類型的module，都有許多個實現，比如event module就有9個實現，這里的每個實現其實也是個子類。
但是，在我們理解橋模式時，這些子類暫時要被看成是event module的實例。代碼中看，像ngx_epoll_module這樣的子類中，還是把一些通用的細節隱藏給ngx_event_core_module來做（管理這個詞更合適）了。從這個角度可以認為，通過context接口，把三個基本module實現分開了。來看看類圖：
nginx自己用時，是以ngx_module_t中的type成員來決定使用哪個實現的。目前的nginx代碼中，如果用了一種接口就一定會指定相應的type。可是實際上，這也可以用來展示橋模式。以事件module為例來看看：
由于UML本就是針對OO語言的，所以以上我畫的類圖都比較牽強，什么是繼承？什么是聚合？在C語言中，往往都是通過幾個函數指針，或者void*指針實現各種封裝和多態。沒有什么語法上的關聯，我就只能從代碼意圖中來判斷了。而代碼意圖這個比較虛，因為不同的角度理解出來都不一樣，所以這個確實不好畫。太靈活了點，我只能從一個便于說明的角度來看，例如：上面的ngx_devpoll_module其實就是一個ngx_module_t，呵呵，但是，實際上它最關心的是ngx_event_actions_t的實現，如果完全根據語法來看，根本說不通的。但從代碼意圖中看，這些module并不關心ngx_module_t，所以我認為，它們只是在實現ngx_event_module_t了。
當然以上只是一家之言，不必當真，如果對nginx源碼有研究的話，歡迎各位拍磚。
客觀的說，C語言確實在封裝上很差，就像nginx，如果我們要開發一個處理http協議的module嵌入進nginx進程，必須了解ngx_http_module里到底做了什么，真沒隱藏啥細節，module開發者們表示很郁悶。上面的這些設計模式，只是做到了代碼上的解藕。如果nginx用C++寫的話，我相信，現在第三方module都能數以萬計了。
原文地址：
http://blog.csdn.net/russell_tao/article/details/7220237
我再次強調，完全脫離編程環境的C/C++學習方法，不是好的方法，現在所謂的環境中立理論就是“什么都不學”理論，VC、GCC，主流的就兩個，精通其中一個就能吃遍天下，教材里就應該選擇一個大講特講！
作為VC的代表，今天我給大家介紹VC中的編譯器選項，全面介紹不需要，MSDN里從頭到尾都介紹完了，今天我只講對生成的exe文件大小和速度有影響的。
用VC就得用IDE，我也以IDE的工程設置里面的排列順序介紹，某些選項需要自己手動添加的最后介紹，我后面說的默認值是release的，debug版本一般不需要調選項。
項目 - 屬性 - 配置屬性 - C/C++，這是編譯器選項。 優化：
通常，算法程序選擇最大化速度(/O2)，界面程序選擇最小化大小(/O1)，可以獲得最佳的效果。
優選大小或速度，只有在使用完全優化(/Ox)時才有效，完全優化一般不推薦使用，用處就是可以生成速度與/O2基本相當，但是體積更小的代碼（選速度優先的話）。 其他幾個選項實際上已包含在/O1、/O2之中，具體請看MSDN。
代碼生成：
啟用字符串池(/GF)，會將相同的字符串合并，當然可以減小空間占用，雖然本項目默認沒有打開，但是默認的/Zi選項會自動打開/GF，這里打不打開一樣。
啟用C++異常：該項默認打開，在C++項目中（比如MFC中），
會大大增加程序體積，增加約30%，關閉并不代表try不能用了，但會一定程度上降低健壯性，對于空間要求較高的程序，建議關閉。對于正式項目，請參見MSDN，看看會不會造成不利影響。
運行庫：默認多線程DLL(/MD)，
體積最優的方案，如果對方沒有VS運行時庫，選擇/MT會將C/C++運行庫靜態編譯，體積增加不少，因此，我的選擇一般是程序與redist包一起發布，也就幾M，而且以后永遠可以接受/MD版本了。
緩沖區安全檢查：關閉的話，減少0.5K~1K體積（默認情況，VC的段長度512字節，因此程序體積變化的最小單位是0.5K）。
啟用增強指令集：真想用SSE3的話去用Intel C++，VS2008只支持到SSE2，而且，在我的機器上貌似使用默認設置就能達到選擇SSE2的相同速度，
如果安裝了Intel C++ 11，可集成與VS2008，同樣的地方選擇SSE3效果超群。
浮點模型：精確還是快速理論上肯定對速度有影響，但是我極少使用浮點編程，我的方向是系統、安全和密碼，都是整數的天下。
高級：
編譯為C還是C++影響不大，這充分說明了C++簡單面向對象特性和C效率差不多（如重載，默認情況下，編譯器會檢查擴展名決定目標代碼類型，對于cpp文件，所有的函數都會編譯為可重載的類型，但是對效率幾乎沒有影響）。
項目 - 屬性 - 配置屬性 - 鏈接器，這是鏈接器選項。 輸入：
忽略庫只有在庫沖突時候才有用，VC絕對不會連接沒有調用到的庫，哪怕你明確指定了。
清單文件：
完全使用API編程可以不生成清單。減少約1K體積。
一般情況下，關閉UAC的那一項，可減少0.5K。
調試：
關閉“生成調試信息(/DEBUG)”，
根據程序規模，可減少1K~幾十K。
優化：
release模式，默認情況下已經該組已經最優了，/OPT:REF和/OPT:ICF已經打開，注意，VS2005、VS2008中Windows 98優化那一項沒用，不像VC6取消Windows 98優化可以大大減小體積。因為VS2005、VS2008中段大小已經是512字節，VC6默認4K。
高級：
指定入口點，
可以大大減小程序體積，但是不調用CRT的入口無法自動處理參數，可用GetCommandLine和CommandLineToArgvW這兩個API來處理參數。
隨機基址：默認模式啟用映像隨機化(/DYNAMICBASE)，會大大增加程序體積，因為這是個增加程序防反編譯、防破解能力的選項。如無需求，請選擇禁用映像隨機化(/DYNAMICBASE:NO)，
文件越大，體積縮小越明顯，至少30%。
命令行：
小程序，可以指定段大小/ALIGN，/O1編譯的化最小可以使用/ALIGN:4，這個選項不推薦，第一有點規模的程序就不能用太小的段，/O2優化的也不能用小段，而且默認的512字節段可以使用UPX壓縮，再小就不能了，除非咱們編譯那種600字節的Hello World，這個選項意義不大，因此微軟才沒有給他一個圖形選項。
同樣，編譯600字節hello world還需要/merge合并段選項，同樣不推薦使用。
有些選項VS2005和VS2003沒有，VS2003還包括幾個VS2008廢除的選項，實際上VC里面程序優化效率最高的個人感覺是VS2003。VC6的界面差別比較大，選項有一定差異，但畢竟都是微軟的產品，差別不大，甚至于MASM這個匯編編譯器，連接選項大都與VC相同……
再說一點，VS2008SP1的MFC工程會自動生成巨大的256*256真彩圖標，因此默認的MFC對話框程序都有近100K，建議刪除多余的圖標，配合上述選項能減到10多K
原文地址：
http://blog.csdn.net/jackyjkchen/article/details/4676635