很早前就想寫點(diǎn)總結(jié)將編程中遇到的各種錯(cuò)誤刨根挖底地羅列出來。但是因?yàn)檫@些錯(cuò)誤（VC中開調(diào)試器遇到的各種錯(cuò)誤對(duì)話框）都是隨機(jī)性的，真正想總結(jié)的時(shí)候又不想不起來有哪些錯(cuò)誤。恰好最近運(yùn)氣比較背，各種錯(cuò)誤都被我遇遍了，于是恰好有機(jī)會(huì)做個(gè)總結(jié)。
這里所說的VC下的錯(cuò)誤對(duì)話框時(shí)指在VC中開調(diào)試器運(yùn)行程序時(shí)，IDE彈出的對(duì)話框。
1.不是錯(cuò)誤的錯(cuò)誤：斷言 .
將斷言視為錯(cuò)誤其實(shí)有點(diǎn)可笑，但是因?yàn)橛行┩瑢W(xué)甚至不知道這個(gè)，所以我稍微提一下。斷言對(duì)話框大致上類似于：
斷言對(duì)話框是由assert引起的，在對(duì)話框上通常會(huì)給出表達(dá)式，例如assert( 0 ); 彈出對(duì)話框時(shí)就會(huì)將0這個(gè)表達(dá)式顯示出來（Expression:0)。關(guān)于assert的具體信息建議自己google。這里稍微提一下一個(gè)技巧：有時(shí)候?yàn)榱俗宎ssert提供更多的信息，我們可以這樣寫一個(gè)assert:
assert( expression && "Function : invalid argument!" );
因?yàn)樽址挥迷诓紶柋磉_(dá)式中時(shí)，始終為true，不會(huì)妨礙對(duì)expression的判斷，當(dāng)斷言發(fā)生時(shí)(expression為false) 時(shí)，斷言對(duì)話框上就會(huì)顯示這個(gè)字符串，從而方便我們調(diào)試。
要解決這個(gè)問題，首先要確定斷言發(fā)生的位置，如果是你自己設(shè)置的斷言被引發(fā)，就很好解決，如果是系統(tǒng)內(nèi)部的函數(shù)產(chǎn)生的，那么一般是因?yàn)槟銈魅氲暮瘮?shù)參數(shù)無效引起。
2.內(nèi)存相關(guān)：最簡單的非法訪問：
C、C++程序中經(jīng)常誤用無效的指針，從而大致各種各樣的非法內(nèi)存訪問（寫/讀）。最簡單的情況類似于：
這樣的情況由類似以下代碼引起：
char *p = 0;
*p = 'a';
當(dāng)你看到類似于“寫入位置XXXX時(shí)發(fā)生訪問沖突“時(shí)，那么你大致可以斷定，你的程序在某個(gè)地方訪問到非法內(nèi)存。開調(diào)試器對(duì)調(diào)用堆棧進(jìn)行跟蹤即可找出錯(cuò)誤。
3.內(nèi)存相關(guān)：不小心的棧上數(shù)組越界：
當(dāng)你寫下類似以下的代碼時(shí)：
char str[3];
strcpy( str, "abc" );
就將看到如下的對(duì)話框：
對(duì)話框大致的意思就是說str周圍的棧被破壞了，因?yàn)閟tr本身就被放在棧上，所以strcpy(str,"abc")多寫入的'\0'就寫到非法的棧區(qū)域。看到這樣的對(duì)話框可以根據(jù)調(diào)用堆棧定位到錯(cuò)誤發(fā)生的函數(shù)，然后檢查此函數(shù)內(nèi)部定義的數(shù)組訪問，即可解決問題。
4.內(nèi)存相關(guān)：不小心的堆上數(shù)組越界：
并不是每次數(shù)組越界都會(huì)得到上面所描述的錯(cuò)誤，當(dāng)數(shù)組是在堆上分配時(shí)，情況就變得隱秘得多：
char *str = new char [2];
strcpy( str, "ab" ); //執(zhí)行到這里時(shí)并不見得會(huì)崩潰
delete [] str;//但是到這里時(shí)就肯定會(huì)崩潰
以上代碼導(dǎo)致的錯(cuò)誤對(duì)話框還要詭異些：
似乎不同的DAMAGE對(duì)應(yīng)的錯(cuò)誤號(hào)（這里是47）都不一樣，因?yàn)檫@里的錯(cuò)誤發(fā)生在delete，而delete跟new很可能在不同的地方，所以這個(gè)錯(cuò)誤調(diào)試起來不是那么容易，很多時(shí)候只能靠經(jīng)驗(yàn)。
當(dāng)看到類似的對(duì)話框時(shí)，根據(jù)調(diào)用堆棧跟到delete時(shí)，你就可以大致懷疑堆上數(shù)組越界。
5.調(diào)用相關(guān)：函數(shù)調(diào)用約定帶來的錯(cuò)誤：
這是所有我這里描述的錯(cuò)誤中最詭異的一種，先看下對(duì)話框大致的樣子：
對(duì)話框大致的意思就是說（沒開調(diào)試器時(shí)對(duì)話框樣式可能不一樣），通過函數(shù)指針調(diào)用某個(gè)函數(shù)時(shí)，函數(shù)指針的類型（函數(shù)原型）可能與函數(shù)指針指向的函數(shù)的類型不一樣。這里的類型不一致主要是調(diào)用約定(call conversation）不一樣。如果函數(shù)類型（參數(shù)個(gè)數(shù)，返回值）不一樣，一般不會(huì)出錯(cuò)。
調(diào)用約定是指調(diào)用一個(gè)函數(shù)時(shí)，函數(shù)參數(shù)的壓入順序、誰來清理?xiàng)５膬?nèi)容等。例如默認(rèn)的C、C++調(diào)用約定__cdecl，對(duì)于函數(shù)的參數(shù)是從右往左壓入。而__stdcall（WIN API的調(diào)用約定）則是從左向右壓。我這里所說的函數(shù)類型不一樣，就是指一個(gè)函數(shù)是使用__cdecl，還是__stdcall。例如以下代碼：
#include <iostream>
void __stdcall show( const char *str )
{
}
void __stdcall show2()
{
}
int main()
{
typedef void (*Func)( const char *);
void *p = show;
Func my_func = (Func) p;
my_func( "kevin" );
return 0;
}
因?yàn)镕unc默認(rèn)地被處理為__cdecl，而show是__stdcall的，所以當(dāng)通過函數(shù)指針my_func時(shí)，就導(dǎo)致了以上對(duì)話框的出現(xiàn)。但是當(dāng)p指向show2時(shí)，又不會(huì)出錯(cuò)，這是因?yàn)閟how2沒有參數(shù)，不同的調(diào)用約定不影響這個(gè)規(guī)則。
6.異常相關(guān)：默認(rèn)終止程序
當(dāng)我們使用C++庫時(shí)，因?yàn)閹毂旧砜赡軙?huì)拋出C++異常，如果你不捕獲這個(gè)異常，那么C++默認(rèn)就會(huì)調(diào)用abort（或者exit）函數(shù)終止程序。例如：
void test()
{
throw std::exception( "some exceptions" );
}
當(dāng)你調(diào)用test函數(shù)時(shí)，如果不catch這個(gè)異常，開調(diào)試器就會(huì)得到類似的錯(cuò)誤對(duì)話框：
而如果不開調(diào)試器，則會(huì)得到：
當(dāng)你看到類似于“This application has requested the Runtime to terminate it…”之類的字眼時(shí)，那就表明程序調(diào)用了abort（或exit）函數(shù)，導(dǎo)致程序異常終止。其實(shí)這個(gè)錯(cuò)誤只要開調(diào)試器，一般可以準(zhǔn)確定位錯(cuò)誤的發(fā)生點(diǎn)。
7.VC運(yùn)行時(shí)檢查-未初始化變量
VC的調(diào)試器會(huì)對(duì)代碼進(jìn)行運(yùn)行時(shí)檢查，這可能會(huì)導(dǎo)致VC彈出對(duì)你看上去正確的代碼。這也許不是一個(gè)錯(cuò)誤。例如：
int test_var;
if( test_var == -1 )
{
test_var = 0;
}
test_var沒有初始化就進(jìn)行if判斷，當(dāng)運(yùn)行以上代碼開調(diào)試器時(shí)，就會(huì)得到如下對(duì)話框：
8.破壞的堆
VC對(duì)于在堆上分配的內(nèi)存都做了記錄，我想這主要用于free釋放內(nèi)存時(shí)做歸還處理。
char *p = (char*) malloc( 100 );
p += 10;
free( p );
當(dāng)執(zhí)行以上代碼時(shí)，因?yàn)閜的值已經(jīng)改變，提交到free的指針值變化，VC就會(huì)給出以下錯(cuò)誤提示：
本文轉(zhuǎn)自：http://m.shnenglu.com/kevinlynx/archive/2008/04/24/47998.html
有一天有個(gè)同事在通過vld調(diào)試一個(gè)內(nèi)存泄漏問題，折騰了很久然后找到我。我瞥了一眼他的代碼，發(fā)現(xiàn)問題和我曾經(jīng)遇到的一模一樣：
1 class Base {
2 public:
3 ~Base();
4 };
5
6 class Derived : public Base {
7 privated:
8 std::vector<int> m_data; };
9
10 Base *obj = new Derived();
11 delete obj;
當(dāng)然，實(shí)際代碼比這個(gè)復(fù)雜得多(這也是導(dǎo)致從發(fā)現(xiàn)問題到找到問題耗費(fèi)大量時(shí)間的原因)。vld在報(bào)內(nèi)存泄漏時(shí)，當(dāng)然報(bào)的位置是new的地方。這個(gè)同事檢查了這個(gè)對(duì)象的整個(gè)生命周期，確定他正確地釋放了這個(gè)對(duì)象。
問題的關(guān)鍵就在于：Base類的析構(gòu)函數(shù)不是virtual的。因?yàn)椴皇?/span>virtual，所以在對(duì)一個(gè)Base類型的指針進(jìn)行delete時(shí)，就不會(huì)調(diào)用到派生類Derived的析構(gòu)函數(shù)。而派生類里的析構(gòu)函數(shù)會(huì)用于析構(gòu)其內(nèi)部的子對(duì)象，也就是這里的m_data。這樣，就造成了內(nèi)存泄漏。
這其實(shí)是一個(gè)很低級(jí)的失誤。但毫不客氣地說C++中有很多這種少個(gè)關(guān)鍵字或者代碼位置不對(duì)就會(huì)造成另一個(gè)結(jié)果的例子。事實(shí)上，針對(duì)這些悲劇也有很多書提出一些準(zhǔn)則來讓大家去無腦遵守。例如針對(duì)這個(gè)例子，我就記得曾有書說，只要你覺得你的類會(huì)被繼承，那么最好給析構(gòu)函數(shù)加上virtual。
摘要: win7下得到操作系統(tǒng)版本錯(cuò)誤（ GetVersionEx）
有一段得到操作系統(tǒng)版本的代碼，用的是 GetVersionEx 方法，在當(dāng)前機(jī)器的硬盤上運(yùn)行，得到的操作系統(tǒng)版本是win7。奇怪的是，在U盤上運(yùn)行，得到的操作系統(tǒng)版本是XP。
直接說原因： 不知道什么時(shí)候，系統(tǒng)在注冊(cè)表中設(shè)置了U盤exe的XP兼容項(xiàng)（在兼容性助手彈出時(shí)，選擇重新啟動(dòng)或者重新安裝時(shí)，系統(tǒng)會(huì)在H...
閱讀全文
摘要: CListCtrl使用技巧
以下未經(jīng)說明，listctrl默認(rèn)view 風(fēng)格為report
1. CListCtrl 風(fēng)格
LVS_ICON: 為每個(gè)item顯示大圖標(biāo) LVS_SMALLICON: 為每個(gè)item顯示小圖標(biāo) &nbs...
閱讀全文
響應(yīng)WM_CTLCOLOR消息
WM_CTLCOLOR消息的響應(yīng)函數(shù).此函數(shù)的原型:
afx_msg HBRUSH OnCtlColor(CDC *pDC,CWnd *pWnd,UINT nCtlColor);
參數(shù)nCtlColor用于指定控件的類型,可以是:
.CTLCOLOR_BTN 按鈕控件
.CTLCOLOR_DLG 對(duì)話框
.CTLCOLOR_EDIT 編輯框
.CTLCOLOR_LISTBOX 列表控件
.CTLCOLOR_MSGBOX 消息控件
.CTLCOLOR_SCROLLBAR 滾動(dòng)條控件
.CTLCOLOR_STATIC 靜態(tài)控件
MSDN中信息:
The framework calls this member function when a child control is about to be drawn.
1 afx_msg HBRUSH OnCtlColor(
2 CDC* pDC,
3 CWnd* pWnd,
4 UINT nCtlColor
5 );
Parameters
Return Value
OnCtlColor must return a handle to the brush that is to be used for painting the control background.
Example
1 // This OnCtlColor handler will change the color of a static control
2 // with the ID of IDC_MYSTATIC. The code assumes that the CPenWidthsDlg
3 // class has an initialized and created CBrush member named m_brush.
4 // The control will be painted with red text and a background
5 // color of m_brush.
6 HBRUSH CPenWidthsDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
7 {
8 // Call the base class implementation first! Otherwise, it may
9 // undo what we're trying to accomplish here.
10 HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
11
12 // Are we painting the IDC_MYSTATIC control? We can use
13 // CWnd::GetDlgCtrlID() to perform the most efficient test.
14 if (pWnd->GetDlgCtrlID() == IDC_MYSTATIC)
15 {
16 // Set the text color to red
17 pDC->SetTextColor(RGB(255, 0, 0));
18
19 // Set the background mode for text to transparent
20 // so background will show thru.
21 pDC->SetBkMode(TRANSPARENT);
22
23 // Return handle to our CBrush object
24 hbr = m_brush;
25 }
26
27 return hbr;
28 }
Requirements
復(fù)雜的東西寫多了，如今寫點(diǎn)簡單的好了。由于功能上的需要，
Vczh Library++3.0被我搞得很離譜。為了開發(fā)維護(hù)的遍歷、減少粗心犯下的錯(cuò)誤以及增強(qiáng)單元測(cè)試、回歸測(cè)試和測(cè)試工具，因此記錄下一些開發(fā)上的小技巧，以便拋磚引玉，造福他人。歡迎高手來噴，菜鳥膜拜。
之前的文章講了指針和內(nèi)存的一些問題，今天說一下單元測(cè)試的問題。如果在團(tuán)隊(duì)里面沒有對(duì)單元測(cè)試的框架有要求的話，其實(shí)我們可以使用一個(gè)最簡單的方法來搭建在IDE里面運(yùn)行的單元測(cè)試框架，整個(gè)框架只需十幾行代碼。我們先來考慮一下功能最少的單元測(cè)試框架需要完成什么樣的內(nèi)容。首先我們要運(yùn)行一個(gè)一個(gè)的測(cè)試用例，其次在一個(gè)測(cè)試用例里面我們要檢查一些條件是否成立。舉個(gè)例子，我們寫一個(gè)函數(shù)將兩個(gè)字符串連接起來，一般來說要進(jìn)行下面的測(cè)試：
1 #include "MyUnitTestFramework.h"//等一下我們會(huì)展示一下如何用最少的代碼完成這個(gè)頭文件的內(nèi)容
2 #include "
"
3
4 TEST_CASE(StringConcat)
5 {
6 TEST_ASSERT(concat("a", "b")=="ab");
7 TEST_ASSERT(concat("a", "")=="a");
8 TEST_ASSERT(concat("", "b")=="b");
9 TEST_ASSERT(concat("", "")=="");
10 .
11 }
12
13 int wmain()
14 {
15 return 0;
16 } 如果我們的單元測(cè)試框架可以這么寫，那顯然做起什么事情來都會(huì)方便很多，而且不需要向一些其他的測(cè)試框架一樣注冊(cè)一大堆東西，或者是寫一大堆配置函數(shù)。當(dāng)然這次我們只做功能最少的測(cè)試框架，這個(gè)框架除了運(yùn)行測(cè)試以外，不會(huì)有其他功能，譬如選擇哪些測(cè)試可以運(yùn)行啦，還是在出錯(cuò)的時(shí)候log一些什么啦之類。之所以要在IDE里面運(yùn)行，是因?yàn)槲覀內(nèi)绻龅絋EST_ASSERT中出現(xiàn)false的話，立刻在該行崩潰，那么IDE就會(huì)幫你定位到出錯(cuò)的TEST_ASSERT中去，然后給你顯示所有的上下文信息，譬如說callstack啦什么的。友好的工具不用簡直對(duì)不起自己啊，干嗎非得把單元測(cè)試做得那么復(fù)雜捏，凡是單元測(cè)試，總是要全部運(yùn)行通過才能提交代碼的。
那么我們來看看上面的單元測(cè)試的代碼。首先寫了TEST_CASE的那個(gè)地方，大括號(hào)里面的代碼會(huì)自動(dòng)運(yùn)行。其次TEST_ASSERT會(huì)在表達(dá)式是false的時(shí)候崩潰。先從簡單的入手吧。如何制造崩潰呢？最簡單的辦法就是拋異常：
1 #define TEST_ASSERT(e) do(if(!(e))throw "今晚沒飯吃。";}while(0)
這里面有兩個(gè)要注意的地方。首先e要加上小括號(hào)，不然取反操作符就有可能做出錯(cuò)誤的行為。譬如說當(dāng)e是a+b==c的時(shí)候，加了小括號(hào)就變成if(!(a+b==c))...，沒有加小括號(hào)就變成if(!a+b==c)...，意思就完全變了。第二個(gè)主意的地方是我使用do{...}while(0)把語句包圍起來了。這樣做的好處是可以在任何時(shí)候TEST_ASSERT(e)都像一個(gè)語句。譬如我們可能這么寫：
1 if(a)
2 TEST_ASSERT(x1);
3 else if(b)
4 {
5 TEST_ASSERT(x2);
6 TEST_ASSERT(x3);
7 }
如果沒有do{...}while(0)包圍起來，這個(gè)else就會(huì)被綁定到宏里面的那個(gè)if，你的代碼就被偷偷改掉了。
那么現(xiàn)在剩下TEST_CASE(x){y}了。什么東西可以在main函數(shù)外面自動(dòng)運(yùn)行呢？這個(gè)我想熟悉C++的人都會(huì)知道，就是全局變量的構(gòu)造函數(shù)啦。所以TEST_CASE(x){y}那個(gè)大括號(hào)里面的y只能在全局變量的構(gòu)造函數(shù)里面調(diào)用。但是我們知道寫一個(gè)類的時(shí)候，構(gòu)造函數(shù)的大括號(hào)寫完了，后面還有類的大括號(hào)，全局變量的名稱，和最終的一個(gè)分號(hào)。為了把這些去掉，那么顯然{y}應(yīng)該屬于一個(gè)普通的函數(shù)。那么全局變量如何能夠使用這個(gè)函數(shù)呢？方法很簡單，把函數(shù)前置聲明一下就行了：
1 #define TEST_CASE(NAME) \
2 extern void TESTCASE_##NAME(); \
3 namespace vl_unittest_executors \
4 { \
5 class TESTCASE_RUNNER_##NAME \
6 { \
7 public: \
8 TESTCASE_RUNNER_##NAME() \
9 { \
10 TESTCASE_##NAME(); \
11 } \
12 } TESTCASE_RUNNER_##NAME##_INSTANCE; \
13 } \
14 void TESTCASE_##NAME()
那我們來看看TEST_CASE(x){y}究竟會(huì)被翻譯成什么代碼：
1 extern void TESTCASE_x();
2 namespace vl_unittest_executors
3 {
4 class TESTCASE_RUNNER_x
5 {
6 public:
7 TESTCASE_RUNNER_x()
8 {
9 TESTCASE_x();
10 }
11 } TESTCASE_RUNNER_x_INSTANCE;
12 }
13 void TESTCASE_x(){y}
到了這里是不是很清楚了捏，首先在main函數(shù)運(yùn)行之前TESTCASE_RUNNER_x_INSTANCE變量會(huì)初始化，然后調(diào)用TESTCASE_RUNNER_x的構(gòu)造函數(shù)，最后運(yùn)行函數(shù)TESTCASE_x，該函數(shù)的內(nèi)容顯然就是{y}了。這里還能學(xué)到宏是如何連接兩個(gè)名字成為一個(gè)名字，和如何寫多行的宏的。
于是MyUnittestFramework.h就包含這兩個(gè)宏，其他啥都沒有，是不是很方便呢？打開Visual C++，建立一個(gè)工程，引用這個(gè)頭文件，然后寫你的單元測(cè)試，最后F5就運(yùn)行了，多方便啊，啊哈哈哈。
這里需要注意一點(diǎn)，那些單元測(cè)試的順序是不受到保證的，特別是你使用了多個(gè)cpp文件的情況下。于是你在使用這個(gè)測(cè)試框架的同時(shí)，會(huì)被迫保證執(zhí)行一次單元測(cè)試不會(huì)對(duì)你的全局狀態(tài)帶來什么副作用，以便兩個(gè)測(cè)試用例交換順序執(zhí)行的時(shí)候仍然能穩(wěn)定地產(chǎn)生相同的結(jié)果。這對(duì)你寫單元測(cè)試有幫助，而且為了讓你的代碼能夠被這么測(cè)試，你的代碼也會(huì)寫的有條理，不會(huì)依賴全局狀態(tài)，真是一舉兩得也。而且說不定單元測(cè)試用例比你的全局變量的初始化還先執(zhí)行呢，因此為了使用這個(gè)測(cè)試框架，你將會(huì)不得不把你的全局變量隱藏在一個(gè)cpp里面，而暴露出隨時(shí)可以被調(diào)用的一組函數(shù)出來。這樣也可以讓你的代碼在使用全局狀態(tài)的時(shí)候更加安全。
今天就講到這里了。下一篇要寫什么我還沒想好，到時(shí)候再說吧。
本文轉(zhuǎn)自：
http://m.shnenglu.com/vczh/archive/2010/06/27/118829.html
摘要: C++實(shí)用技巧（一） 復(fù)雜的東西寫多了，如今寫點(diǎn)簡單的好了。由于功能上的需要，Vczh Library++3.0被我搞得很離譜。為了開發(fā)維護(hù)的遍歷、減少粗心犯下的錯(cuò)誤以及增強(qiáng)單元測(cè)試、回歸測(cè)試和測(cè)試工具，因此記錄下一些開發(fā)上的小技巧，以便拋磚引玉，造福他人。歡迎高手來噴，菜鳥膜拜。 C++實(shí)謂各種語言中的軟肋，功能強(qiáng)大，陷阱...
閱讀全文
在高效C++編程中看到一個(gè)不錯(cuò)的內(nèi)存池實(shí)現(xiàn)方案，這里共享下，大家看看有什么不足。
代碼很簡單，如下：
template<typename T>
class CMemoryPool
{
public:
enum { EXPANSION_SIZE = 32};
CMemoryPool(unsigned int nItemCount = EXPANSION_SIZE)
{
ExpandFreeList(nItemCount);
}
~CMemoryPool()
{
//free all memory in the list
CMemoryPool<T>* pNext = NULL;
for(pNext = m_pFreeList; pNext != NULL; pNext = m_pFreeList)
{
m_pFreeList = m_pFreeList->m_pFreeList;
delete [](char*)pNext;
}
}
void* Alloc(unsigned int /*size*/)
{
if(m_pFreeList == NULL)
{
ExpandFreeList();
}
//get free memory from head
CMemoryPool<T>* pHead = m_pFreeList;
m_pFreeList = m_pFreeList->m_pFreeList;
return pHead;
}
void Free(void* p)
{
//push the free memory back to list
CMemoryPool<T>* pHead = static_cast<CMemoryPool<T>*>(p);
pHead->m_pFreeList = m_pFreeList;
m_pFreeList = pHead;
}
protected:
//allocate memory and push to the list
void ExpandFreeList(unsigned nItemCount = EXPANSION_SIZE)
{
unsigned int nSize = sizeof(T) > sizeof(CMemoryPool<T>*) ? sizeof(T) : sizeof(CMemoryPool<T>*);
CMemoryPool<T>* pLastItem = static_cast<CMemoryPool<T>*>(static_cast<void*>(new char[nSize]));
m_pFreeList = pLastItem;
for(int i=0; i<nItemCount-1; ++i)
{
pLastItem->m_pFreeList = static_cast<CMemoryPool<T>*>(static_cast<void*>(new char[nSize]));
pLastItem = pLastItem->m_pFreeList;
}
pLastItem->m_pFreeList = NULL;
}
private:
CMemoryPool<T>* m_pFreeList;
};
它的實(shí)現(xiàn)思想就是每次從List的頭上取內(nèi)存， 如果取不到則重新分配一定數(shù)量； 用完后把內(nèi)存放回List頭部，這樣的話效率很高，因?yàn)槊看蜭ist上可以取到的話，肯定是空閑的內(nèi)存。
當(dāng)然上面的代碼只是針對(duì)單線程的，要支持多線程的話也很簡單，外面加一層就可以了，
代碼如下：
class CCriticalSection
{
public:
CCriticalSection()
{
InitializeCriticalSection(&m_cs);
}
~CCriticalSection()
{
DeleteCriticalSection(&m_cs);
}
void Lock()
{
EnterCriticalSection(&m_cs);
}
void Unlock()
{
LeaveCriticalSection(&m_cs);
}
protected:
CRITICAL_SECTION m_cs;
};
template<typename POOLTYPE, typename LOCKTYPE>
class CMTMemoryPool
{
public:
void* Alloc(unsigned int size)
{
void* p = NULL;
m_lock.Lock();
p = m_pool.Alloc(size);
m_lock.Unlock();
return p;
}
void Free(void* p)
{
m_lock.Lock();
m_pool.Free(p);
m_lock.Unlock();
}
private:
POOLTYPE m_pool;
LOCKTYPE m_lock;
};
這是我的測(cè)試代碼：
#include <iostream>
#include <windows.h>
using namespace std;
#include "MemoryPool.h"
#include "MTMemoryPool.h"
class CTest
{
public:
int m_n;
int m_n1;
void* operator new(size_t size)
{
void* p = s_pool->Alloc(size);
return p;
}
void operator delete(void* p, size_t size)
{
s_pool->Free(p);
}
static void NewPool()
{
//s_pool = new CMemoryPool<CTest>;
s_pool = new CMTMemoryPool<CMemoryPool<CTest>, CCriticalSection>;
}
static void DeletePool()
{
delete s_pool;
s_pool = NULL;
}
//static CMemoryPool<CTest>* s_pool;
static CMTMemoryPool<CMemoryPool<CTest>, CCriticalSection>* s_pool;
};
//CMemoryPool<CTest>* CTest::s_pool = NULL;
CMTMemoryPool<CMemoryPool<CTest>, CCriticalSection>* CTest::s_pool = NULL;
void testFun()
{
int i;
const int nLoop = 10;
const int nCount = 10000;
for(int j = 0; j<nLoop; ++j)
{
typedef CTest* LPTest;
LPTest arData[nCount];
for(i=0;i <nCount; ++i)
{
arData[i] = new CTest;
}
for(i=0;i <nCount; ++i)
{
delete arData[i];
}
}
}
int main(int argc, char* argv[])
{
{
unsigned int dwStartTickCount = GetTickCount();
CTest::NewPool();
testFun();
CTest::DeletePool();
cout << "total cost" << GetTickCount() - dwStartTickCount << endl;
}
system("pause");
return 0;
}
在我機(jī)器上測(cè)試結(jié)果比系統(tǒng)默認(rèn)的CRT實(shí)現(xiàn)高效N倍。
本文轉(zhuǎn)自：
http://m.shnenglu.com/weiym/archive/2012/05/05/173785.aspx
1、Callback方式
Callback的本質(zhì)是設(shè)置一個(gè)函數(shù)指針進(jìn)去，然后在需要需要觸發(fā)某個(gè)事件時(shí)調(diào)用該方法, 比如Windows的窗口消息處理函數(shù)就是這種類型。比如下面的示例代碼，我們?cè)贒ownload完成時(shí)需要觸發(fā)一個(gè)通知外面的事件：
typedef void (__stdcall *DownloadCallback)(const char* pURL, bool bOK);void DownloadFile(const char* pURL, DownloadCallback callback){ cout << "downloading: " << pURL << "" << endl; callback(pURL, true);}void __stdcall OnDownloadFinished(const char* pURL, bool bOK){ cout << "OnDownloadFinished, URL:" << pURL << " status:" << bOK << endl;} 2、Sink方式
Sink的本質(zhì)是你按照對(duì)方要求實(shí)現(xiàn)一個(gè)C++接口，然后把你實(shí)現(xiàn)的接口設(shè)置給對(duì)方，對(duì)方需要觸發(fā)事件時(shí)調(diào)用該接口， COM中連接點(diǎn)就是居于這種方式。上面下載文件的需求，如果用Sink實(shí)現(xiàn)，代碼如下:
class IDownloadSink{public: virtual void OnDownloadFinished(const char* pURL, bool bOK) = 0;};class CMyDownloader{public: CMyDownloader(IDownloadSink* pSink) :m_pSink(pSink) { } void DownloadFile(const char* pURL) { cout << "downloading: " << pURL << "" << endl; if(m_pSink != NULL) { m_pSink->OnDownloadFinished(pURL, true); } }private: IDownloadSink* m_pSink;};class CMyFile: public IDownloadSink{public: void download() { CMyDownloader downloader(this); downloader.DownloadFile("www.baidu.com"); } virtual void OnDownloadFinished(const char* pURL, bool bOK) { cout << "OnDownloadFinished, URL:" << pURL << " status:" << bOK << endl; }}; 3、Delegate方式
Delegate的本質(zhì)是設(shè)置成員函數(shù)指針給對(duì)方，然后讓對(duì)方在需要觸發(fā)事件時(shí)調(diào)用。C#中用Delegate的方式實(shí)現(xiàn)Event，讓C++程序員很是羨慕，C++中因?yàn)檎Z言本身的關(guān)系，要實(shí)現(xiàn)Delegate還是很麻煩的。上面的例子我們用Delegate的方式實(shí)現(xiàn)如下:
class CDownloadDelegateBase{public: virtual void Fire(const char* pURL, bool bOK) = 0;};template<typename O, typename T>class CDownloadDelegate: public CDownloadDelegateBase{ typedef void (T::*Fun)(const char*, bool);public: CDownloadDelegate(O* pObj = NULL, Fun pFun = NULL) :m_pFun(pFun), m_pObj(pObj) { } virtual void Fire(const char* pURL, bool bOK) { if(m_pFun != NULL && m_pObj != NULL) { (m_pObj->*m_pFun)(pURL, bOK); } }private: Fun m_pFun; O* m_pObj;};template<typename O, typename T>CDownloadDelegate<O,T>* MakeDelegate(O* pObject, void (T::*pFun)(const char* pURL, bool)){ return new CDownloadDelegate<O, T>(pObject, pFun);}class CDownloadEvent{public: ~CDownloadEvent() { vector<CDownloadDelegateBase*>::iterator itr = m_arDelegates.begin(); while (itr != m_arDelegates.end()) { delete *itr; ++itr; } m_arDelegates.clear(); } void operator += (CDownloadDelegateBase* p) { m_arDelegates.push_back(p); } void operator -= (CDownloadDelegateBase* p) { ITR itr = remove(m_arDelegates.begin(), m_arDelegates.end(), p); ITR itrTemp = itr; while (itrTemp != m_arDelegates.end()) { delete *itr; ++itr; } m_arDelegates.erase(itr, m_arDelegates.end()); } void operator()(const char* pURL, bool bOK) { ITR itrTemp = m_arDelegates.begin(); while (itrTemp != m_arDelegates.end()) { (*itrTemp)->Fire(pURL, bOK); ++itrTemp; } }private: vector<CDownloadDelegateBase*> m_arDelegates; typedef vector<CDownloadDelegateBase*>::iterator ITR;};class CMyDownloaderEx{public: void DownloadFile(const char* pURL) { cout << "downloading: " << pURL << "" << endl; downloadEvent(pURL, true); } CDownloadEvent downloadEvent;};class CMyFileEx{public: void download() { CMyDownloaderEx downloader; downloader.downloadEvent += MakeDelegate(this, &CMyFileEx::OnDownloadFinished); downloader.DownloadFile("www.baidu.com"); } virtual void OnDownloadFinished(const char* pURL, bool bOK) { cout << "OnDownloadFinished, URL:" << pURL << " status:" << bOK << endl; }}; 可以看到Delegate的方式代碼量比上面其他2種方式大多了，并且我們上面是固定參數(shù)數(shù)量和類型的實(shí)現(xiàn)方式，如果要實(shí)現(xiàn)可變參數(shù)，要更加麻煩的多。可變參數(shù)的方式可以參考這2種實(shí)現(xiàn):Yet Another C#-style Delegate Class in Standard C++
Member Function Pointers and the Fastest Possible C++ Delegates我們可以用下面的代碼測(cè)試我們上面的實(shí)現(xiàn)：
int _tmain(int argc, _TCHAR* argv[])
{
DownloadFile("www.baidu.com", OnDownloadFinished);
CMyFile f1;
f1.download();
CMyFileEx ff;
ff.download();
system("pause");
return 0;
}
最后簡單比較下上面3種實(shí)現(xiàn)回調(diào)的方法:第一種Callback的方法是面向過程的，使用簡單而且靈活，正如C語言本身。第二種Sink的方法是面向?qū)ο蟮模贑++里使用較多， 可以在一個(gè)Sink里封裝一組回調(diào)接口，適用于一系列比較固定的回調(diào)事件。第三種Delegate的方法也是面向?qū)ο蟮模蚐ink封裝一組接口不同，Delegate的封裝是以函數(shù)為單位，粒度比Sink更小更靈活。 你更傾向于用哪種方式來實(shí)現(xiàn)回調(diào)? 本文轉(zhuǎn)自：http://m.shnenglu.com/weiym/archive/2012/08/28/188515.html
memmove、memcpy和memccpy三個(gè)函數(shù)都是內(nèi)存的拷貝，從一個(gè)緩沖區(qū)拷貝到另一個(gè)緩沖區(qū)。
memmove(void *dest,void*src,int count)
memcpy(void *dest,void *src,int count)
memccpy(void*dest,void*src,int ch,int count)
表頭文件: #include <string.h>
定義函數(shù): void *memcpy(void *dest, const void *src, size_t n)
函數(shù)說明: memcpy()用來拷貝src所指的內(nèi)存內(nèi)容前n個(gè)字節(jié)到dest所指的內(nèi)存地址上。與strcpy()不同的是,memcpy()會(huì)完整的復(fù)制n個(gè)字節(jié),不會(huì)因?yàn)橛龅阶址Y(jié)束'\0'而結(jié)束
返回值: 返回指向dest的指針
表頭文件: #include <string.h>
定義函數(shù): void *memccpy(void *dest, const void *src, int c, size_t n);
函數(shù)說明: memccpy()用來拷貝src所指的內(nèi)存內(nèi)容前n個(gè)字節(jié)到dest所指的地址上。與memcpy()不同的是,memccpy()如果在src中遇到某個(gè)特定值(int c)立即停止復(fù)制。
返回值: 返回指向dest中值為c的下一個(gè)字節(jié)指針。返回值為0表示在src所指內(nèi)存前n個(gè)字節(jié)中沒有值為c的字節(jié)。
表頭文件: #include <string.h>
定義函數(shù): void *memmove(void *dest, const void *src, size_t n);
函數(shù)說明:memmove()是從一個(gè)緩沖區(qū)移動(dòng)到另一個(gè)緩沖區(qū)中。
返回值: 返回指向dest指針。
當(dāng)dest <= src-count 或dest >= src+count時(shí)，以上三個(gè)函數(shù)均不會(huì)產(chǎn)生覆蓋問題，即源數(shù)據(jù)不會(huì)被更改。
若不在以上范圍內(nèi)，則源數(shù)據(jù)會(huì)被更改。如:char a[]={'a','b'};char b[]={'c','d','e','f','g','h'};memmove(a,b,sizeof(b));或是直接char *p=b+2;memmove(p,b,sizeof(b));輸出數(shù)據(jù)會(huì)發(fā)現(xiàn)b中數(shù)據(jù)輸出已被更改。發(fā)現(xiàn)即使a數(shù)組指向的空間不夠存儲(chǔ)數(shù)據(jù)，也能夠移動(dòng)成功。原因|dest - src |<count如果在使用這些函數(shù)時(shí)，分配給足夠的空間，然后再使用就不會(huì)出現(xiàn)覆蓋問題。也就是說如果外部分配給的空間不足以存儲(chǔ)要拷貝的數(shù)據(jù)時(shí)，就有可能出現(xiàn)源數(shù)據(jù)被覆蓋更改的問題。#include <stdio.h>#include <stdlib.h>#include <string.h>void main(void){ int i=0; char a[9]={'a','b','c','d','e','f','g','h','\0'}; char p[2]={'q','w'};//或char *p=a+2; memmove(p,a,sizeof(a)); puts(a); printf("_____________________________________________\n"); puts(p); printf("_____________________________________________\n"); for(i =0;i<10;i++) printf("%c %d \n",*(a+i),a+i); printf("_____________________________________________\n"); for(i =0;i<8;i++) printf("%c %d \n",*(p+i),p+i); }觀察輸出結(jié)果。把memmove(p,a,sizeof(a));改為memcpy(p,a,sizeof(a));或memccpy(p,a,'e',sizeof(a));再觀察輸出結(jié)果。可以看出在目的存儲(chǔ)空間不足時(shí)，便會(huì)出現(xiàn)源數(shù)據(jù)被覆蓋改變的問題。如果目的存儲(chǔ)空間分配足夠的空間，則便不會(huì)出現(xiàn)覆蓋問題。本文轉(zhuǎn)自：http://m.shnenglu.com/kang/archive/2009/04/05/78984.html