#include<iconv.h>
#include <stdio.h>
#include<iconv.h>
using namespace std;
int utf8togb2312(const char *sourcebuf,size_t sourcelen,char *destbuf,size_t destlen) {
iconv_t cd;
if( (cd = iconv_open("gb2312","utf-8")) ==0 )
return -1;
memset(destbuf,0,destlen);
const char **source = &sourcebuf;
char **dest = &destbuf;
if(-1 == iconv(cd,source,&sourcelen,dest,&destlen))
return -1;
iconv_close(cd);
return 0;
}
int gb2312toutf8(const char *sourcebuf,size_t sourcelen,char *destbuf,size_t destlen) {
iconv_t cd; if( (cd = iconv_open("utf-8","gb2312")) ==0 )
return -1; memset(destbuf,0,destlen);
const char **source = &sourcebuf;
char **dest = &destbuf;
if(-1 == iconv(cd,source,&sourcelen,dest,&destlen))
return -1;
摘要: 轉(zhuǎn)載自http://blog.csdn.net/u010984552/article/details/51887108為什么需要線程池目前的大多數(shù)網(wǎng)絡(luò)服務(wù)器，包括Web服務(wù)器、Email服務(wù)器以及數(shù)據(jù)庫(kù)服務(wù)器等都具有一個(gè)共同點(diǎn)，就是單位時(shí)間內(nèi)必須處理數(shù)目巨大的連接請(qǐng)求，但處理時(shí)間卻相對(duì)較短。 傳 統(tǒng)多線程方案中我們采用的服務(wù)器模型則是一旦接受到請(qǐng)求之后，即創(chuàng)建一個(gè)新的線程，由該線程執(zhí)行任...
閱讀全文
摘自http://blog.csdn.net/hackbuteer1/article/details/7722667
在 各種計(jì)算機(jī)體系結(jié)構(gòu)中，對(duì)于字節(jié)、字等的存儲(chǔ)機(jī)制有所不同，因而引發(fā)了計(jì)算機(jī) 通信領(lǐng) 域中一個(gè)很重要的問(wèn)題，即通信雙方交流的信息單元（比特、字節(jié)、字、雙字等等）應(yīng)該以什么樣的順序進(jìn)行傳送。如果不達(dá)成一致的規(guī)則，通信雙方將無(wú)法進(jìn)行正 確的編/譯碼從而導(dǎo)致通信失敗。目前在各種體系的計(jì)算機(jī)中通常采用的字節(jié)存儲(chǔ)機(jī)制主要有兩種：Big-Endian和Little-Endian，下面先從字節(jié)序說(shuō)起。
一、什么是字節(jié)序
字節(jié)序，顧名思義字節(jié)的順序，再多說(shuō)兩句就是大于一個(gè)字節(jié)類型的數(shù)據(jù)在內(nèi)存中的存放順序(一個(gè)字節(jié)的數(shù)據(jù)當(dāng)然就無(wú)需談順序的問(wèn)題了)。其實(shí)大部分人在實(shí)際的開 發(fā)中都很少會(huì)直接和字節(jié)序打交道。唯有在跨平臺(tái)以及網(wǎng)絡(luò)程序中字節(jié)序才是一個(gè)應(yīng)該被考慮的問(wèn)題。
在所有的介紹字節(jié)序的文章中都會(huì)提到字 節(jié)序分為兩類：Big-Endian和Little-Endian，引用標(biāo)準(zhǔn)的Big-Endian和Little-Endian的定義如下：
a) Little-Endian就是低位字節(jié)排放在內(nèi)存的低地址端，高位字節(jié)排放在內(nèi)存的高地址端。
b) Big-Endian就是高位字節(jié)排放在內(nèi)存的低地址端，低位字節(jié)排放在內(nèi)存的高地址端。
c) 網(wǎng)絡(luò)字節(jié)序：TCP/IP各層協(xié)議將字節(jié)序定義為Big-Endian，因此TCP/IP協(xié)議中使用的字節(jié)序通常稱之為網(wǎng)絡(luò)字節(jié)序。
1.1 什么是高/低地址端
首先我們要知道C程序映像中內(nèi)存的空間布局情況：在《C專 家編程》中或者《Unix環(huán)境高級(jí)編程》中有關(guān)于內(nèi)存空間布局情況的說(shuō)明，大致如下圖：
----------------------- 最高內(nèi)存地址 0xffffffff
棧底
棧
棧頂
-----------------------
NULL (空洞)
-----------------------
堆
-----------------------
未初始 化的數(shù)據(jù)
----------------------- 統(tǒng)稱數(shù)據(jù)段
初始化的數(shù)據(jù)
-----------------------
正 文段(代碼段)
----------------------- 最低內(nèi)存地址 0x00000000
由圖可以看出，再內(nèi)存分布中，棧是向下增長(zhǎng)的，而堆是向上增長(zhǎng)的。
以上圖為例如果我們?cè)跅?上分配一個(gè)unsigned char buf[4]，那么這個(gè)數(shù)組變量在棧上是如何布局的呢？看下圖：
棧底 （高地址）
----------
buf[3]
buf[2]
buf[1]
buf[0]
----------
棧頂 （低地址）
其實(shí)，我們可以自己在編譯器里面創(chuàng)建一個(gè)數(shù)組，然后分別輸出數(shù)組種每個(gè)元素的地址，來(lái)驗(yàn)證一下。
1.2 什么是高/低字節(jié)
現(xiàn)在我們弄清了高/低地址，接著考慮高/低字節(jié)。有些文章中稱低位字節(jié)為最低有效位，高位字節(jié)為最高有效位。如果我們有一個(gè)32位無(wú)符號(hào)整型0x12345678，那么高位是什么，低位又是什么呢？ 其實(shí)很簡(jiǎn)單。在十進(jìn)制中我們都說(shuō)靠左邊的是高位，靠右邊的是低位，在其他進(jìn)制也是如此。就拿 0x12345678來(lái)說(shuō)，從高位到低位的字節(jié)依次是0x12、0x34、0x56和0x78。
高/低地址端和高/低字節(jié)都弄清了。我們?cè)賮?lái)回顧 一下Big-Endian和Little-Endian的定義，并用圖示說(shuō)明兩種字節(jié)序：
以u(píng)nsigned int value = 0x12345678為例，分別看看在兩種字節(jié)序下其存儲(chǔ)情況，我們可以用unsigned char buf[4]來(lái)表示value：
Big-Endian: 低地址存放高位，如下圖：
棧底 （高地址）
---------------
buf[3] (0x78) -- 低位
buf[2] (0x56)
buf[1] (0x34)
buf[0] (0x12) -- 高位
---------------
棧頂 （低地址）
Little-Endian: 低地址存放低位，如下圖：
棧底 （高地址）
---------------
buf[3] (0x12) -- 高位
buf[2] (0x34)
buf[1] (0x56)
buf[0] (0x78) -- 低位
--------------
棧 頂 （低地址）
二、各種Endian
2.1 Big-Endian
計(jì)算機(jī)體系結(jié)構(gòu)中一種描述多字節(jié)存儲(chǔ)順序的術(shù)語(yǔ)，在這種機(jī)制中最重要字節(jié)（MSB）存放在最低端的地址 上。采用這種機(jī)制的處理器有IBM3700系列、PDP-10、Mortolora微處理器系列和絕大多數(shù)的RISC處理器。
+----------+
| 0x34 |<-- 0x00000021
+----------+
| 0x12 |<-- 0x00000020
+----------+
圖 1：雙字節(jié)數(shù)0x1234以Big-Endian的方式存在起始地址0x00000020中
在Big-Endian中，對(duì)于bit序列 中的序號(hào)編排方式如下（以雙字節(jié)數(shù)0x8B8A為例）：
bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+-----------------------------------------+
val | 1 0 0 0 1 0 1 1 | 1 0 0 0 1 0 1 0 |
+----------------------------------------+
圖 2：Big-Endian的bit序列編碼方式
2.2 Little-Endian
計(jì)算機(jī)體系結(jié)構(gòu)中 一種描述多字節(jié)存儲(chǔ)順序的術(shù)語(yǔ)，在這種機(jī)制中最不重要字節(jié)（LSB）存放在最低端的地址上。采用這種機(jī)制的處理器有PDP-11、VAX、Intel系列微處理器和一些網(wǎng)絡(luò)通信設(shè)備。該術(shù)語(yǔ)除了描述多字節(jié)存儲(chǔ)順序外還常常用來(lái)描述一個(gè)字節(jié)中各個(gè)比特的排放次序。
+----------+
| 0x12 |<-- 0x00000021
+----------+
| 0x34 |<-- 0x00000020
+----------+
圖3：雙字節(jié)數(shù)0x1234以Little-Endian的方式存在起始地址0x00000020中
在 Little-Endian中，對(duì)于bit序列中的序號(hào)編排和Big-Endian剛好相反，其方式如下（以雙字節(jié)數(shù)0x8B8A為例）：
bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+-----------------------------------------+
val | 1 0 0 0 1 0 1 1 | 1 0 0 0 1 0 1 0 |
+-----------------------------------------+
圖 4：Little-Endian的bit序列編碼方式
注意：通常我們說(shuō)的主機(jī)序（Host Order）就是遵循Little-Endian規(guī)則。所以當(dāng)兩臺(tái)主機(jī)之間要通過(guò)TCP/IP協(xié)議進(jìn)行通信的時(shí)候就需要調(diào)用相應(yīng)的函數(shù)進(jìn)行主機(jī)序 （Little-Endian）和網(wǎng)絡(luò)序（Big-Endian）的轉(zhuǎn)換。
采用 Little-endian模式的CPU對(duì)操作數(shù)的存放方式是從低字節(jié)到高字節(jié)，而Big-endian模式對(duì)操作數(shù)的存放方式是從高字節(jié)到低字節(jié)。 32bit寬的數(shù)0x12345678在Little-endian模式CPU內(nèi)存中的存放方式（假設(shè)從地址0x4000開始存放）為：
內(nèi)存地址 0x4000 0x4001 0x4002 0x4003
存放內(nèi)容 0x78 0x56 0x34 0x12
而在Big- endian模式CPU內(nèi)存中的存放方式則為：
內(nèi)存地址 0x4000 0x4001 0x4002 0x4003
存放內(nèi)容 0x12 0x34 0x56 0x78
具體的區(qū)別如下：
三、Big-Endian和Little-Endian優(yōu)缺點(diǎn)
Big-Endian優(yōu)點(diǎn)：靠首先提取高位字節(jié)，你總是可以由看看在偏移位置為0的字節(jié)來(lái)確定這個(gè)數(shù)字是 正數(shù)還是負(fù)數(shù)。你不必知道這個(gè)數(shù)值有多長(zhǎng)，或者你也不必過(guò)一些字節(jié)來(lái)看這個(gè)數(shù)值是否含有符號(hào)位。這個(gè)數(shù)值是以它們被打印出來(lái)的順序存放的，所以從二進(jìn)制到十進(jìn)制的函數(shù)特別有效。因而，對(duì)于不同要求的機(jī)器，在設(shè)計(jì)存取方式時(shí)就會(huì)不同。
Little-Endian優(yōu)點(diǎn)：提取一個(gè)，兩個(gè)，四個(gè)或者更長(zhǎng)字節(jié)數(shù)據(jù)的匯編指令以與其他所有格式相同的方式進(jìn)行：首先在偏移地址為0的地方提取最低位的字節(jié)，因?yàn)榈刂菲坪妥止?jié)數(shù)是一對(duì)一的關(guān)系，多重精度的數(shù)學(xué)函數(shù)就相對(duì)地容易寫了。
如果你增加數(shù)字的值，你可能在左邊增加數(shù)字（高位非指數(shù)函數(shù)需要更多的數(shù)字）。 因此， 經(jīng)常需要增加兩位數(shù)字并移動(dòng)存儲(chǔ)器里所有Big-endian順序的數(shù)字，把所有數(shù)向右移，這會(huì)增加計(jì)算機(jī)的工作量。不過(guò)，使用Little- Endian的存儲(chǔ)器中不重要的字節(jié)可以存在它原來(lái)的位置，新的數(shù)可以存在它的右邊的高位地址里。這就意味著計(jì)算機(jī)中的某些計(jì)算可以變得更加簡(jiǎn)單和快速。
四、請(qǐng)寫一個(gè)C函數(shù)，若處理器是Big_endian的，則返回0；若是Little_endian的，則返回1。
- int checkCPU(void)
- {
- union
- {
- int a;
- char b;
- }c;
- c.a = 1;
- return (c.b == 1);
- }
說(shuō)明：
1 在c中，聯(lián)合體（共用體）的數(shù)據(jù)成員都是從低地址開始存放。
2 若是小端模式，由低地址到高地址c.a存放為0x01 00 00 00，c.b被賦值為0x01；
————————————————————————————
地址 0x00000000 0x00000001 0x00000002 0x00000003
c.a 01 00 00 00
c.b 01 00
————————————————————————————
3 若是大端模式，由低地址到高地址c.a存放為0x00 00 00 01，c.b被賦值為0x0；
————————————————————————————
地址 0x00000000 0x00000001 0x00000002 0x00000003
c.a 00 00 00 01
c.b 00 00
————————————————————————————
4 根據(jù)c.b的值的情況就可以判斷cpu的模式了。
舉例，一個(gè)16進(jìn)制數(shù)是 0x11 22 33，其存放的位置是
地址0x3000 中存放11
地址0x3001 中存放22
地址0x3002 中存放33
連起來(lái)就寫成地址0x3000-0x3002中存放了數(shù)據(jù)0x112233
而這種存放和表示方式，正好符合大端。
另外一個(gè)比較好理解的寫法如下：
- bool checkCPU() // 如果是大端模式，返回真
- {
- short int test = 0x1234;
-
- if( *((char *)&test) == 0x12) // 低地址存放高字節(jié)數(shù)據(jù)
- return true;
- else
- return false;
- }
-
- int main(void)
- {
- if( !checkCPU())
- cout<<"Little endian"<<endl;
- else
- cout<<"Big endian"<<endl;
-
- return 0;
- }
- int main(void)
- {
- short int a = 0x1234;
- char *p = (char *)&a;
-
- if( *p == 0x34)
- cout<<"Little endian"<<endl;
- else
- cout<<"Big endian"<<endl;
-
- return 0;
- }
-
- int main(void)
- {
- short int a = 0x1234;
- char x0 , x1;
-
- x0 = ((char *)&a)[0];
- x1 = ((char *)&a)[1];
-
- if( x0 == 0x34)
- cout<<"Little endian"<<endl;
- else
- cout<<"Big endian"<<endl;
-
- return 0;
- }
首先看看如下一個(gè)聲明：
int* ( *( *fun )( int* ) )[10];
這是一個(gè)會(huì)讓初學(xué)者感到頭暈?zāi)垦！⒏械娇謶值暮瘮?shù)指針聲明。在熟練掌握C/C++的聲明語(yǔ)法之前，不學(xué)習(xí)一定的規(guī)則，想理解好這類復(fù)雜聲明是比較困難的。
C/C++所有復(fù)雜的聲明結(jié)構(gòu)，都是由各種聲明嵌套構(gòu)成的。如何解讀復(fù)雜指針聲明？右左法則是一個(gè)很著名、很有效的方法。不過(guò)，右左法則其實(shí)并不是C/C++標(biāo)準(zhǔn)里面的內(nèi)容，它是從C/C++標(biāo)準(zhǔn)的聲明規(guī)定中歸納出來(lái)的方法。C/C++標(biāo)準(zhǔn)的聲明規(guī)則，是用來(lái)解決如何創(chuàng)建聲明的，而右左法則是用來(lái)解決如何辯識(shí)一個(gè)聲明的，從嵌套的角度看，兩者可以說(shuō)是一個(gè)相反的過(guò)程。右左法則的英文原文是這樣說(shuō)的：
The right-left rule: Start reading the declaration from the innermost parentheses, go right, and then go left. When you encounter parentheses, the direction should be reversed. Once everything in the parentheses has been parsed, jump out of it. Continue till the whole declaration has been parsed.
這段英文的翻譯如下：
右左法則：首先從最里面的圓括號(hào)看起，然后往右看，再往左看。每當(dāng)遇到圓括號(hào)時(shí)，就應(yīng)該掉轉(zhuǎn)閱讀方向。一旦解析完圓括號(hào)里面所有的東西，就跳出圓括號(hào)。重復(fù)這個(gè)過(guò)程直到整個(gè)聲明解析完畢。
筆者要對(duì)這個(gè)法則進(jìn)行一個(gè)小小的修正，應(yīng)該是從未定義的標(biāo)識(shí)符開始閱讀，而不是從括號(hào)讀起，之所以是未定義的標(biāo)識(shí)符，是因?yàn)橐粋€(gè)聲明里面可能有多個(gè)標(biāo)識(shí)符，但未定義的標(biāo)識(shí)符只會(huì)有一個(gè)。
現(xiàn)在通過(guò)一些例子來(lái)討論右左法則的應(yīng)用，先從最簡(jiǎn)單的開始，逐步加深：
int (*func)(int *p);
首先找到那個(gè)未定義的標(biāo)識(shí)符，就是func，它的外面有一對(duì)圓括號(hào)，而且左邊是一個(gè)*號(hào)，這說(shuō)明func是一個(gè)指針，然后跳出這個(gè)圓括號(hào)，先看右邊，也是一個(gè)圓括號(hào)，這說(shuō)明(*func)是一個(gè)函數(shù)，而func是一個(gè)指向這類函數(shù)的指針，就是一個(gè)函數(shù)指針，這類函數(shù)具有int*類型的形參，返回值類型是int。
int (*func)(int *p, int (*f)(int*));
func被一對(duì)括號(hào)包含，且左邊有一個(gè)*號(hào)，說(shuō)明func是一個(gè)指針，跳出括號(hào)，右邊也有個(gè)括號(hào)，那么func是一個(gè)指向函數(shù)的指針，這類函數(shù)具有int *和int (*)(int*)這樣的形參，返回值為int類型。再來(lái)看一看func的形參int (*f)(int*)，類似前面的解釋，f也是一個(gè)函數(shù)指針，指向的函數(shù)具有int*類型的形參，返回值為int。
int (*func[5])(int *p);
func右邊是一個(gè)[]運(yùn)算符，說(shuō)明func是一個(gè)具有5個(gè)元素的數(shù)組，func的左邊有一個(gè)*，說(shuō)明func的元素是指針，要注意這里的*不是修飾func的，而是修飾func[5]的，原因是[]運(yùn)算符優(yōu)先級(jí)比*高，func先跟[]結(jié)合，因此*修飾的是func[5]。跳出這個(gè)括號(hào)，看右邊，也是一對(duì)圓括號(hào)，說(shuō)明func數(shù)組的元素是函數(shù)類型的指針，它所指向的函數(shù)具有int*類型的形參，返回值類型為int。
int (*(*func)[5])(int *p);
func被一個(gè)圓括號(hào)包含，左邊又有一個(gè)*，那么func是一個(gè)指針，跳出括號(hào)，右邊是一個(gè)[]運(yùn)算符號(hào)，說(shuō)明func是一個(gè)指向數(shù)組的指針，現(xiàn)在往左看，左邊有一個(gè)*號(hào)，說(shuō)明這個(gè)數(shù)組的元素是指針，再跳出括號(hào)，右邊又有一個(gè)括號(hào)，說(shuō)明這個(gè)數(shù)組的元素是指向函數(shù)的指針。總結(jié)一下，就是：func是一個(gè)指向數(shù)組的指針，這個(gè)數(shù)組的元素是函數(shù)指針，這些指針指向具有int*形參，返回值為int類型的函數(shù)。
int (*(*func)(int *p))[5];
func是一個(gè)函數(shù)指針，這類函數(shù)具有int*類型的形參，返回值是指向數(shù)組的指針，所指向的數(shù)組的元素是具有5個(gè)int元素的數(shù)組。
要注意有些復(fù)雜指針聲明是非法的，例如：
int func(void) [5];
func是一個(gè)返回值為具有5個(gè)int元素的數(shù)組的函數(shù)。但C語(yǔ)言的函數(shù)返回值不能為數(shù)組，這是因?yàn)槿绻试S函數(shù)返回值為數(shù)組，那么接收這個(gè)數(shù)組的內(nèi)容的東西，也必須是一個(gè)數(shù)組，但C/C++語(yǔ)言的數(shù)組名是一個(gè)不可修改的左值，它不能直接被另一個(gè)數(shù)組的內(nèi)容修改，因此函數(shù)返回值不能為數(shù)組。
int func[5](void);
func是一個(gè)具有5個(gè)元素的數(shù)組，這個(gè)數(shù)組的元素都是函數(shù)。這也是非法的，因?yàn)閿?shù)組的元素必須是對(duì)象，但函數(shù)不是對(duì)象，不能作為數(shù)組的元素。
實(shí)際編程當(dāng)中，需要聲明一個(gè)復(fù)雜指針時(shí)，如果把整個(gè)聲明寫成上面所示這些形式，將對(duì)可讀性帶來(lái)一定的損害，應(yīng)該用typedef來(lái)對(duì)聲明逐層分解，增強(qiáng)可讀性。
typedef是一種聲明，但它聲明的不是變量，也沒有創(chuàng)建新類型，而是某種類型的別名。typedef有很大的用途，對(duì)一個(gè)復(fù)雜聲明進(jìn)行分解以增強(qiáng)可讀性是其作用之一。例如對(duì)于聲明：
int (*(*func)(int *p))[5];
可以這樣分解：
typedef int (*PARA)[5];
typedef PARA (*func)(int *);
這樣就容易看得多了。
typedef的另一個(gè)作用，是作為基于對(duì)象編程的高層抽象手段。在ADT中，它可以用來(lái)在C/C++和現(xiàn)實(shí)世界的物件間建立關(guān)聯(lián)，將這些物件抽象成C/C++的類型系統(tǒng)。在設(shè)計(jì)ADT的時(shí)候，我們常常聲明某個(gè)指針的別名，例如：
typedef struct node * list;
從ADT的角度看，這個(gè)聲明是再自然不過(guò)的事情，可以用list來(lái)定義一個(gè)列表。但從C/C++語(yǔ)法的角度來(lái)看，它其實(shí)是不符合C/C++聲明語(yǔ)法的邏輯的，它暴力地將指針聲明符從指針聲明器中分離出來(lái)，這會(huì)造成一些異于人們閱讀習(xí)慣的現(xiàn)象，考慮下面代碼：
const struct node *p1;
typedef struct node *list;
const list p2;
p1類型是const struct node*，那么p2呢？如果你以為就是把list簡(jiǎn)單“代入”p2，然后得出p2類型也是const struct node*的結(jié)果，就大錯(cuò)特錯(cuò)了。p2的類型其實(shí)是struct node * const p2，那個(gè)const限定的是p2，不是node。造成這一奇異現(xiàn)象的原因是指針聲明器被分割，標(biāo)準(zhǔn)中規(guī)定：
6.7.5.1 Pointer declarators
Semantics
If in the declaration ‘‘T D1’’, D1 has the form
* type-qualifier-listopt D
and the type specified for ident in the declaration ‘‘T D’’ is
‘‘derived-declarator-type-list T’’
then the type specified for ident is
‘‘derived-declarator-type-list type-qualifier-list pointer to T’’
For each type qualifier in the list, ident is a so-qualified pointer.
指針的聲明器由指針聲明符*、可選的類型限定詞type-qualifier-listopt和標(biāo)識(shí)符D組成，這三者在邏輯上是一個(gè)整體，構(gòu)成一個(gè)完整的指針聲明器。這也是多個(gè)變量同列定義時(shí)指針聲明符必須緊跟標(biāo)識(shí)符的原因，例如：
int *p, q, *k;
p和k都是指針，但q不是，這是因?yàn)?/span>*p、*k是一個(gè)整體指針聲明器，以表示聲明的是一個(gè)指針。編譯器會(huì)把指針聲明符左邊的類型包括其限定詞作為指針指向的實(shí)體的類型，右邊的限定詞限定被聲明的標(biāo)識(shí)符。但現(xiàn)在typedef struct node *list硬生生把*從整個(gè)指針聲明器中分離出來(lái)，編譯器找不到*，會(huì)認(rèn)為const list p2中的const是限定p2的，正因如此，p2的類型是node * const而不是const node*。
雖然typedef struct node* list不符合聲明語(yǔ)法的邏輯，但基于typedef在ADT中的重要作用以及信息隱藏的要求，我們應(yīng)該讓用戶這樣使用list A，而不是list *A，因此在ADT的設(shè)計(jì)中仍應(yīng)使用上述typedef語(yǔ)法，但需要注意其帶來(lái)的不利影響。
摘要: 值得推薦的C/C++框架和庫(kù)【本文系外部轉(zhuǎn)貼，原文地址：http://coolshell.info/c/c++/2014/12/13/c-open-project.htm】留作存檔下次造輪子前先看看現(xiàn)有的輪子吧值得學(xué)習(xí)的C語(yǔ)言開源項(xiàng)目- 1. Webbench Webbench是一個(gè)在linux下使用的非常簡(jiǎn)單的網(wǎng)站壓測(cè)工具。它使用fork()模擬多個(gè)客戶端同時(shí)訪問(wèn)我們?cè)O(shè)定的URL，測(cè)試...
閱讀全文
STL跨平臺(tái)調(diào)用會(huì)出現(xiàn)很多異常，你可以試試.
STL使用模板生成，當(dāng)我們使用模板的時(shí)候，每一個(gè)EXE，和DLL都在編譯器產(chǎn)生了自己的代碼，導(dǎo)致模板所使用的靜態(tài)成員不同步，所以出現(xiàn)數(shù)據(jù)傳遞的各種問(wèn)題，下面是詳細(xì)解釋。
原因分析：
一句話-----如果任何STL類使用了靜態(tài)變量（無(wú)論是直接還是間接使用），那么就不要再寫出跨執(zhí)行單元訪問(wèn)它的代碼。 除非你能夠確定兩個(gè)動(dòng)態(tài)庫(kù)使用的都是同樣的STL實(shí)現(xiàn)，比如都使用VC同一版本的STL，編譯選項(xiàng)也一樣。強(qiáng)烈建議，不要在動(dòng)態(tài)庫(kù)接口中傳遞STL容器！！
STL不一定不能在DLL間傳遞，但你必須徹底搞懂它的內(nèi)部實(shí)現(xiàn)，并懂得為何會(huì)出問(wèn)題。
微軟的解釋：
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b172396
微軟給的解決辦法：
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b168958
1、微軟的解釋：
大部分C++標(biāo)準(zhǔn)庫(kù)里提供的類直接或間接地使用了靜態(tài)變量。由于這些類是通過(guò)模板擴(kuò)展而來(lái)的，因此每個(gè)可執(zhí)行映像（通常是.dll或.exe文件）就會(huì)存在一份只屬于自己的、給定類的靜態(tài)數(shù)據(jù)成員。當(dāng)一個(gè)需要訪問(wèn)這些靜態(tài)成員的類方法執(zhí)行時(shí)，它使用的是“這個(gè)方法的代碼當(dāng)前所在的那份可執(zhí)行映像”里的靜態(tài)成員變量。由于兩份可執(zhí)行映像各自的靜態(tài)數(shù)據(jù)成員并未同步，這個(gè)行為就可能導(dǎo)致訪問(wèn)違例，或者數(shù)據(jù)看起來(lái)似乎丟失或被破壞了。
可能不太好懂，我舉個(gè)例子：假如類A<T>有個(gè)靜態(tài)變量m_s，那么當(dāng)1.exe使用了2.dll中提供的某個(gè)A<int>對(duì)象時(shí)，由于模板擴(kuò)展機(jī)制，1.exe和2.dll中會(huì)分別存在自己的一份類靜態(tài)變量A<int>.m_s。
這樣，假如1.exe中從2.dll中取得了一個(gè)的類A<int>的實(shí)例對(duì)象a，那么當(dāng)在1.exe中直接訪問(wèn)a.m_s時(shí)，其實(shí)訪問(wèn)的是 1.exe中的對(duì)應(yīng)拷貝（正確情況應(yīng)該是訪問(wèn)了2.dll中的a.m_s）。這樣就可能導(dǎo)致非法訪問(wèn)、應(yīng)當(dāng)改變的數(shù)據(jù)沒有改變、不應(yīng)改變的數(shù)據(jù)被錯(cuò)誤地更改等異常情形。
原文：
Most classes in the Standard C++ Libraries use static data members directly or indirectly. Since these classes are generated through template instantiation, each executable image (usually with DLL or EXE file name extensions) will contain its own copy of the static data member for a given class. When a method of the class that requires the static data member is executed, it uses the static data member in the executable image in which the method code resides. Since the static data members in the executable images are not in sync, this action could result in an access violation or data may appear to be lost or corrupted.
1、保證資源的分配/刪除操作對(duì)等并處于同一個(gè)執(zhí)行單元；
比如，可以把這些操作（包括構(gòu)造/析構(gòu)函數(shù)、某些容器自動(dòng)擴(kuò)容{這個(gè)需要特別注意}時(shí)的內(nèi)存再分配等）隱藏到接口函數(shù)里面。換句話說(shuō)：盡量不要直接從dll中輸出stl對(duì)象；如果一定要輸出，給它加上一層包裝，然后輸出這個(gè)包裝接口而不是原始接口。
2、保證所有的執(zhí)行單元使用同樣版本的STL運(yùn)行庫(kù)。
比如，全部使用release庫(kù)或debug庫(kù)，否則兩個(gè)執(zhí)行單元擴(kuò)展出來(lái)的STL類的內(nèi)存布局就可能會(huì)不一樣。
只要記住關(guān)鍵就是：如果任何STL類使用了靜態(tài)變量（無(wú)論是直接還是間接使用），那么就不要再寫出跨執(zhí)行單元訪問(wèn)它的代碼。
解決方法：
1. 一個(gè)可以考慮的方案
比如有兩個(gè)動(dòng)態(tài)庫(kù)L1和L2，L2需要修改L1中的一個(gè)map，那么我在L1中設(shè)置如下接口
int modify_map(int key, int new_value);
如果需要指定“某一個(gè)map”，則可以考慮實(shí)現(xiàn)一種類似于句柄的方式，比如可以傳遞一個(gè)DWORD
不過(guò)這個(gè)DWORD放的是一個(gè)地址
那么modify_map就可以這樣實(shí)現(xiàn)：
int modify_map(DWORD map_handle, int key, int new_value)
{
std::map<int, int>& themap = *(std::map<int, int>*)map_handle;
themap[key] = new_value;
}
map_handle的值也首先由L1“告訴”L2:
DWORD get_map_handle();
L2可以這樣調(diào)用:
DWORD h = get_map_handle();
modify_map(h, 1, 2);
2. 加入一個(gè)額外的層，就可以解決問(wèn)題。所以，你需要將你的Map包裝在dll內(nèi)部，而不是讓它出現(xiàn)在接口當(dāng)中。動(dòng)態(tài)庫(kù)的接口越簡(jiǎn)單越好，不好去傳太過(guò)復(fù)雜的東東是至理名言：）
在動(dòng)態(tài)連接庫(kù)開發(fā)中要特別注意內(nèi)存的分配與釋放問(wèn)題，稍不注意，極可能造成內(nèi)存泄漏，從而訪問(wèn)出錯(cuò)。例如在某DLL中存在這樣一段代碼：
extent "C" __declspec(dllexport)
void ExtractFileName( const std::string& path //!< Input path and filename.
, std::string& fname //!< Extracted filename with extension.
)
{
std::string::size_type startPos = path.find_last_of('\\');
fname.assign(path.begin() startPos 1, path.end() );
}
在DLL中使用STL對(duì)象std::string，并且在其中改變std::string的內(nèi)容，即發(fā)生了內(nèi)存的重分配問(wèn)題,若在EXE中調(diào)用該函數(shù)會(huì)出現(xiàn)內(nèi)存訪問(wèn)問(wèn)題。主要是：因?yàn)镈LL和EXE的內(nèi)存分配方式不同，DLL中的分配的內(nèi)存不能在EXE中正確釋放掉。
解決這一問(wèn)題的途徑如下：
一般情況下：構(gòu)建DLL必須遵循誰(shuí)分配就由誰(shuí)釋放的原則，例如COM的解決方案（利用引用計(jì)數(shù)），對(duì)象的創(chuàng)建（QueryInterface）與釋放均在COM組件內(nèi)部完成。在純C 環(huán)境下，可以很容易的實(shí)現(xiàn)類似方案。
在應(yīng)用STL的情況下，很難使用上述方案來(lái)解決，因此必須另辟蹊徑，途徑有二：
1、自己寫內(nèi)存分配器替代STL中的默認(rèn)分配器。
2、使用STLport替代系統(tǒng)的標(biāo)準(zhǔn)庫(kù)。
其實(shí)，上述問(wèn)題在VC7及以后版本中，已得到解決，注意DLL工程和調(diào)用的工程一定要使用多線程DLL庫(kù)，就不會(huì)發(fā)生內(nèi)存訪問(wèn)問(wèn)題。
一個(gè)很奇怪的問(wèn)題：DLL中使用std::string作為參數(shù)結(jié)果出錯(cuò)
這段時(shí)間,在工程中將一些功能封裝成動(dòng)態(tài)庫(kù),需要使用動(dòng)態(tài)庫(kù)接口的時(shí)候.使用了STL的一些類型作為參數(shù).
比方string,vector,list.但是在使用接口的時(shí)候.- class exportClass
- {
- bool dll_funcation(string &str);
- };
當(dāng)我在使用這個(gè)庫(kù)的時(shí)候.這樣寫代碼:- string str="":
- exportClass tmp;
- tmp.dll_function(str);
一點(diǎn)一點(diǎn)取掉這個(gè)函數(shù)的代碼.最后就剩下
str="qadasdasdasdsafsafas";
還是出錯(cuò)誤.
如果改成很短的字符串,就不會(huì)出錯(cuò)誤.
在這個(gè)時(shí)候,只能嘗試認(rèn)為是字符串的空間太小
最終我修改成這樣,錯(cuò)誤消失了.希望錯(cuò)誤真的是這個(gè)引起的- string str="":
- str.resize(1000);
- exportClass tmp;
- tmp.dll_function(str);
|
今天寫程序的時(shí)候要給一個(gè)模塊的dll傳遞一個(gè)參數(shù)，由于參數(shù)數(shù)量是可變的，因此設(shè)計(jì)成了vector<string>類型，但調(diào)試過(guò)程中發(fā)現(xiàn)在exe中的參數(shù)傳遞到dll中的函數(shù)后，vector變成空的，改成傳引用類型后，vector竟然變得很大，并且是無(wú)意義的參數(shù)。
對(duì)于這個(gè)問(wèn)題，兩種辦法：
1.傳遞vector指針
2.傳遞const vector<TYPE>。
究其原因：
是因?yàn)関ector在exe和dll之間傳遞的時(shí)候，由于在dll內(nèi)可能對(duì)vector插入數(shù)據(jù)，而這段內(nèi)存是在dll里面分配的，exe無(wú)法知道如何釋放內(nèi)存，從而導(dǎo)致問(wèn)題。而改成const類型后，編譯器便知道dll里不會(huì)改變vector，從而不會(huì)出錯(cuò)。
或者可以說(shuō)這是"cross-DLL problem."（This problem crops up when an object is created using new in one dynamically linked library (DLL) but is deleted in a different DLL）的一種吧。
對(duì)于STL，在DLL中使用的時(shí)候，往往存在這些問(wèn)題，在網(wǎng)絡(luò)上搜集了下，這些都是要平時(shí)使用STL的時(shí)候注意的。
***************************************************************************************************************
引用http://www.hellocpp.net/Articles/Article/714.aspx
當(dāng)template 遭遇到dynamic link 時(shí)候, 很多時(shí)候卻是一場(chǎng)惡夢(mèng).
現(xiàn)在來(lái)說(shuō)說(shuō)一部分我已經(jīng)碰到過(guò)的問(wèn)題. 問(wèn)題主要集中在內(nèi)存分配上.
1>
拿STL來(lái)說(shuō), 自己寫模板的時(shí)候,很難免就用到stl. stl的代碼都在頭文件里. 那么表示著內(nèi)存分配的代碼.只有包含了它的cpp 編譯的時(shí)候才會(huì)被決定是使用什么樣的內(nèi)存分配代碼. 考慮一下: 當(dāng)你聲明了一個(gè)vector<> . 并把這個(gè)vector<>交給一個(gè) dll里的代碼來(lái)用. 用完后, 在你的程序里被釋放了. 那么如果你 在dll里往vector里insert了一些東西. 那么這個(gè)時(shí)候insert 發(fā)生的內(nèi)存分配的代碼是屬于dll的. 你不知道這個(gè)dll的內(nèi)存分配是什么. 是分配在哪里的. 而這個(gè)時(shí)候.釋放那促的動(dòng)作卻不在dll里.....同時(shí). 你甚至無(wú)法保證編譯dll的那個(gè)家伙使用的stl版本和你是完全一樣的..>
如此說(shuō)來(lái), 程序crash掉是天經(jīng)地義的....
對(duì)策: 千萬(wàn)別別把你的stl 容器,模板容器在 dll 間傳來(lái)傳去 . 記住string也是....
2>
你在dll的某個(gè)類里聲明了一個(gè)vector之類的容器. 而沒有顯式的寫這個(gè)類的構(gòu)造和析構(gòu)函數(shù). 那么問(wèn)題又來(lái)了.
你這個(gè)類肯定有操作這vector的函數(shù). 那么這些函數(shù)會(huì)讓vecoter<>生成代碼. 這些代碼在這個(gè)dll里都是一致的. 但是別忘了.你沒有寫析構(gòu)函數(shù)...... 如果這個(gè)時(shí)候, 別人在外面聲明了一個(gè)這樣的類.然后調(diào)用這個(gè)類的函數(shù)操作了這個(gè)vector( 當(dāng)然使用者并不知道什么時(shí)候操作了vector) . 它用完了這個(gè)類以后. 類被釋放掉了. 編譯器很負(fù)責(zé)的為它生成了一份析構(gòu)函數(shù)的代碼...... 聽好了.這份代碼并不是在 dll里 ... . 事情于是又和1>里的一樣了.... crash ......(可能還會(huì)伴隨著迷茫.....)
對(duì)策: 記得dll里每個(gè)類,哪怕式構(gòu)造析構(gòu)函數(shù)式空的. 也要寫到cpp里去. 什么都不寫也式很糟糕的.....同時(shí),更要把任何和內(nèi)存操作有關(guān)的函數(shù)寫到 .cpp 里...
3>
以上兩個(gè)問(wèn)題似乎都是比較容易的-----只要把代碼都寫到cpp里去, 不要用stl容器傳來(lái)傳去就可以了.
那么第三個(gè)問(wèn)題就要麻煩的多.
如果你自己寫了一個(gè)模板, 這個(gè)模板用了stl 容器..........
這個(gè)時(shí)候你該怎么辦呢?
顯然你無(wú)法把和內(nèi)存分配相關(guān)的函數(shù)都寫到.cpp里去 . template的代碼都必須放到header file里.....
對(duì)策: 解決這個(gè)問(wèn)題的基本做法是做一個(gè)stl 內(nèi)存分配器 , 強(qiáng)制把這個(gè)模板里和內(nèi)存分配相關(guān)的放到一個(gè).cpp里去.這個(gè)時(shí)候編譯這個(gè)cpp就會(huì)把內(nèi)存分配代碼固定在一個(gè)地方: 要么是dll. 要么是exe里...
模板+動(dòng)態(tài)鏈接庫(kù)的使用問(wèn)題還很多. 要千萬(wàn)留心這個(gè)陷阱遍地的東西啊
***************************************************************************************************************************
微軟關(guān)于這類問(wèn)題的解釋：
You may experience an access violation when you access an STL object through a pointer or reference in a different DLL or EXE
http://support.microsoft.com/default.aspx?scid=KB;en-us;q172396
How to export an instantiation of a Standard Template Library (STL) class and a class that contains a data member that is an STL object
http://support.microsoft.com/default.aspx?scid=KB;en-us;q168958
總結(jié)：
字符串參數(shù)用char*，Vector用char**，
動(dòng)態(tài)內(nèi)存要牢記誰(shuí)申請(qǐng)誰(shuí)釋放的原則。