更改结构体的内存字节对齐方式--经典
結(jié)構(gòu)體字節(jié)對(duì)齊??
http://blog.163.com/ecy_fu/blog/static/4445126200910603739941/
?
? ? ??http://hi.baidu.com/skyland_lee/blog/item/45604bca81e1928cc91768d7.html，這篇文章比較專業(yè)地分析了字節(jié)對(duì)齊在VC和GCC的特點(diǎn)，寫得非常不錯(cuò)。這兩天我在為畢業(yè)設(shè)計(jì)做準(zhǔn)備，所以要花點(diǎn)時(shí)間研究字節(jié)對(duì)齊的問題。
文章中有這樣一段話： Win32平臺(tái)下的微軟C編譯器(cl.exe for 80×86)的對(duì)齊策略： 1)?結(jié)構(gòu)體變量的首地址能夠被其最寬基本類型成員的大小所整除； 備注：編譯器在給結(jié)構(gòu)體開辟空間時(shí)，首先找到結(jié)構(gòu)體中最寬的基本數(shù)據(jù)類型，然后尋找內(nèi)存地址能被該基本數(shù)據(jù)類型所整除的位置，作為結(jié)構(gòu)體的首地址。將這個(gè)最寬的基本數(shù)據(jù)類型的大小作為上面介紹的對(duì)齊模數(shù)。 2)?結(jié)構(gòu)體每個(gè)成員相對(duì)于結(jié)構(gòu)體首地址的偏移量（offset）都是成員大小的整數(shù)倍，如有需要編譯器會(huì)在成員之間加上填充字節(jié)（internal adding）； 備注:為結(jié)構(gòu)體的一個(gè)成員開辟空間之前，編譯器首先檢查預(yù)開辟空間的首地址相對(duì)于結(jié)構(gòu)體首地址的偏移是否是本成員的整數(shù)倍，若是，則存放本成員，反之，則在本成員和上一個(gè)成員之間填充一定的字節(jié)，以達(dá)到整數(shù)倍的要求，也就是將預(yù)開辟空間的首地址后移幾個(gè)字節(jié)。 3)?結(jié)構(gòu)體的總大小為結(jié)構(gòu)體最寬基本類型成員大小的整數(shù)倍，如有需要，編譯器會(huì)在最末一個(gè)成員之后加上填充字節(jié)（trailing padding）。 備注：結(jié)構(gòu)體總大小是包括填充字節(jié)，最后一個(gè)成員滿足上面兩條以外，還必須滿足第三條，否則就必須在最后填充幾個(gè)字節(jié)以達(dá)到本條要求。通過一個(gè)例子來驗(yàn)證之，有這樣一個(gè)結(jié)構(gòu)體： struct S { int a; double b; int c; }; sizeof得到它的大小為24，顯然為了滿足第2)條，在a后面填充了4個(gè)字節(jié)，以保證b成員的地址相對(duì)于結(jié)構(gòu)體首地址的偏移量是8的倍數(shù)；為了滿足 3)條，在c的后面填充了4個(gè)字節(jié)，使得結(jié)構(gòu)體的總大小為結(jié)構(gòu)體最寬基本類型成員大小的整數(shù)倍。這樣sizeof(S)就是24了。至于第一條，我倒是第一次看到，驗(yàn)證了下發(fā)現(xiàn)有點(diǎn)奇怪，測(cè)試代碼如下（VS2008）： struct S s1; int a = 4;
struct S s2;
printf("%d, %d\n", &s1, (int)(&s1) % 8);
printf("%d, %d\n", &s2, (int)(&s2) % 8); 觀察內(nèi)存可知，&s1是能被8整除的，s1后面填充了好多字節(jié)，然后就是a，a后面又填充了一些字節(jié)，然后才是s2，感覺有點(diǎn)亂？最后發(fā)現(xiàn)"(int)&s2 % 8"等于4，這就不符合1)條了。 如果使用“#pragma pack(4)聲明下”，這個(gè)結(jié)構(gòu)體的大小就會(huì)變成16，也就是按照4字節(jié)對(duì)齊了。pack(n)用于指明對(duì)齊的最大值。 文章中對(duì)于位域結(jié)構(gòu)體有這樣一段話： 如果結(jié)構(gòu)體中含有位域(bit-field)，那么VC中準(zhǔn)則又要有所更改： 1) 如果相鄰位域字段的類型相同，且其位寬之和小于類型的sizeof大小，則后面的字段將緊鄰前一個(gè)字段存儲(chǔ)，直到不能容納為止； 2) 如果相鄰位域字段的類型相同，但其位寬之和大于類型的sizeof大小，則后面的字段將從新的存儲(chǔ)單元開始，其偏移量為其類型大小的整數(shù)倍； 3) 如果相鄰的位域字段的類型不同，則各編譯器的具體實(shí)現(xiàn)有差異，VC6采取不壓縮方式（不同位域字段存放在不同的位域類型字節(jié)中），Dev-C++和GCC都采取壓縮方式； 用幾個(gè)例子來測(cè)試一下： struct S2 { int a: 2; int b: 3; int c: 3; };
struct S3 { char a : 2; int b : 3; }; sizeof(S2)=4，滿足1)條；sizeof(S3)=8，滿足3)條。
????? 同GCC的差異性。GCC最大的對(duì)齊模數(shù)為4，所以S的大小為16；S2，S3的大小為4，因?yàn)镚CC會(huì)將S3中的a和b壓縮在一個(gè)4字節(jié)中，VC卻采用非壓縮方式。
?
C語言結(jié)構(gòu)體的字節(jié)對(duì)齊原則
http://blog.csdn.net/shenbin1430/article/details/4292463
為什么要對(duì)齊?
??? 現(xiàn)代計(jì)算機(jī)中內(nèi)存空間都是按照byte劃分的，從理論上講似乎對(duì)任何類型的變量的訪問可以從任何地址開始，但實(shí)際情況是在訪問特定類型變量的時(shí)候經(jīng)常在特定的內(nèi)存地址訪問，這就需要各種類型數(shù)據(jù)按照一定的規(guī)則在空間上排列，而不是順序的一個(gè)接一個(gè)的排放，這就是對(duì)齊。
??? 對(duì)齊的作用和原因：各個(gè)硬件平臺(tái)對(duì)存儲(chǔ)空間的處理上有很大的不同。一些平臺(tái)對(duì)某些特定類型的數(shù)據(jù)只能從某些特定地址開始存取。比如有些架構(gòu)的CPU在訪問一個(gè)沒有進(jìn)行對(duì)齊的變量的時(shí)候會(huì)發(fā)生錯(cuò)誤,那么在這種架構(gòu)下編程必須保證字節(jié)對(duì)齊.其他平臺(tái)可能沒有這種情況，但是最常見的是如果不按照適合其平臺(tái)要求對(duì)數(shù)據(jù)存放進(jìn)行對(duì)齊，會(huì)在存取效率上帶來?yè)p失。比如有些平臺(tái)每次讀都是從偶地址開始，如果一個(gè)int型（假設(shè)為32位系統(tǒng)）如果存放在偶地址開始的地方，那么一個(gè)讀周期就可以讀出這32bit，而如果存放在奇地址開始的地方，就需要2個(gè)讀周期，并對(duì)兩次讀出的結(jié)果的高低字節(jié)進(jìn)行拼湊才能得到該32bit數(shù)據(jù)。顯然在讀取效率上下降很多。
二.字節(jié)對(duì)齊對(duì)程序的影響:
??? 先讓我們看幾個(gè)例子吧(32bit,x86環(huán)境,gcc編譯器):
設(shè)結(jié)構(gòu)體如下定義：
struct A
{
??? int a;
??? char b;
??? short c;
};
struct B
{
??? char b;
??? int a;
??? short c;
};
現(xiàn)在已知32位機(jī)器上各種數(shù)據(jù)類型的長(zhǎng)度如下:
char:1(有符號(hào)無符號(hào)同)???
short:2(有符號(hào)無符號(hào)同)???
int:4(有符號(hào)無符號(hào)同)???
long:4(有符號(hào)無符號(hào)同)???
float:4??? double:8
那么上面兩個(gè)結(jié)構(gòu)大小如何呢?
結(jié)果是:
sizeof(strcut A)值為8
sizeof(struct B)的值卻是12
結(jié)構(gòu)體A中包含了4字節(jié)長(zhǎng)度的int一個(gè)，1字節(jié)長(zhǎng)度的char一個(gè)和2字節(jié)長(zhǎng)度的short型數(shù)據(jù)一個(gè),B也一樣;按理說A,B大小應(yīng)該都是7字節(jié)。
之所以出現(xiàn)上面的結(jié)果是因?yàn)榫幾g器要對(duì)數(shù)據(jù)成員在空間上進(jìn)行對(duì)齊。上面是按照編譯器的默認(rèn)設(shè)置進(jìn)行對(duì)齊的結(jié)果,那么我們是不是可以改變編譯器的這種默認(rèn)對(duì)齊設(shè)置呢,當(dāng)然可以.例如:
#pragma pack (2) /*指定按2字節(jié)對(duì)齊*/
struct C
{
??? char b;
??? int a;
??? short c;
};
#pragma pack () /*取消指定對(duì)齊，恢復(fù)缺省對(duì)齊*/
sizeof(struct C)值是8。
修改對(duì)齊值為1：
#pragma pack (1) /*指定按1字節(jié)對(duì)齊*/
struct D
{
??? char b;
??? int a;
??? short c;
};
#pragma pack () /*取消指定對(duì)齊，恢復(fù)缺省對(duì)齊*/
sizeof(struct D)值為7。
后面我們?cè)僦v解#pragma pack()的作用.
三.編譯器是按照什么樣的原則進(jìn)行對(duì)齊的?
??? 先讓我們看四個(gè)重要的基本概念：
1.數(shù)據(jù)類型自身的對(duì)齊值：
? 對(duì)于char型數(shù)據(jù)，其自身對(duì)齊值為1，對(duì)于short型為2，對(duì)于int,float,double類型，其自身對(duì)齊值為4，單位字節(jié)。
2.結(jié)構(gòu)體或者類的自身對(duì)齊值：其成員中自身對(duì)齊值最大的那個(gè)值。
3.指定對(duì)齊值：#pragma pack (value)時(shí)的指定對(duì)齊值value。
4.數(shù)據(jù)成員、結(jié)構(gòu)體和類的有效對(duì)齊值：自身對(duì)齊值和指定對(duì)齊值中小的那個(gè)值。
有了這些值，我們就可以很方便的來討論具體數(shù)據(jù)結(jié)構(gòu)的成員和其自身的對(duì)齊方式。有效對(duì)齊值N是最終用來決定數(shù)據(jù)存放地址方式的值，最重要。有效對(duì)齊N，就是表示“對(duì)齊在N上”，也就是說該數(shù)據(jù)的"存放起始地址%N=0".而數(shù)據(jù)結(jié)構(gòu)中的數(shù)據(jù)變量都是按定義的先后順序來排放的。第一個(gè)數(shù)據(jù)變量的起始地址就是數(shù)據(jù)結(jié)構(gòu)的起始地址。結(jié)構(gòu)體的成員變量要對(duì)齊排放，結(jié)構(gòu)體本身也要根據(jù)自身的有效對(duì)齊值圓整(就是結(jié)構(gòu)體成員變量占用總長(zhǎng)度需要是對(duì)結(jié)構(gòu)體有效對(duì)齊值的整數(shù)倍，結(jié)合下面例子理解)。這樣就不能理解上面的幾個(gè)例子的值了。
例子分析：
分析例子B；
struct B
{
??? char b;
??? int a;
??? short c;
};
假設(shè)B從地址空間0x0000開始排放。該例子中沒有定義指定對(duì)齊值，在筆者環(huán)境下，該值默認(rèn)為4。第一個(gè)成員變量b的自身對(duì)齊值是1，比指定或者默認(rèn)指定對(duì)齊值4小，所以其有效對(duì)齊值為1，所以其存放地址0x0000符合0x0000%1=0.第二個(gè)成員變量a，其自身對(duì)齊值為4，所以有效對(duì)齊值也為4，所以只能存放在起始地址為0x0004到0x0007這四個(gè)連續(xù)的字節(jié)空間中，復(fù)核0x0004%4=0,且緊靠第一個(gè)變量。第三個(gè)變量c,自身對(duì)齊值為 2，所以有效對(duì)齊值也是2，可以存放在0x0008到0x0009這兩個(gè)字節(jié)空間中，符合0x0008%2=0。所以從0x0000到0x0009存放的都是B內(nèi)容。再看數(shù)據(jù)結(jié)構(gòu)B的自身對(duì)齊值為其變量中最大對(duì)齊值(這里是b）所以就是4，所以結(jié)構(gòu)體的有效對(duì)齊值也是4。根據(jù)結(jié)構(gòu)體圓整的要求， 0x0009到0x0000=10字節(jié)，（10＋2）％4＝0。所以0x0000A到0x000B也為結(jié)構(gòu)體B所占用。故B從0x0000到0x000B 共有12個(gè)字節(jié),sizeof(struct B)=12;其實(shí)如果就這一個(gè)就來說它已將滿足字節(jié)對(duì)齊了, 因?yàn)樗钠鹗嫉刂肥?,因此肯定是對(duì)齊的,之所以在后面補(bǔ)充2個(gè)字節(jié),是因?yàn)榫幾g器為了實(shí)現(xiàn)結(jié)構(gòu)數(shù)組的存取效率,試想如果我們定義了一個(gè)結(jié)構(gòu)B的數(shù)組,那么第一個(gè)結(jié)構(gòu)起始地址是0沒有問題,但是第二個(gè)結(jié)構(gòu)呢?按照數(shù)組的定義,數(shù)組中所有元素都是緊挨著的,如果我們不把結(jié)構(gòu)的大小補(bǔ)充為4的整數(shù)倍,那么下一個(gè)結(jié)構(gòu)的起始地址將是0x0000A,這顯然不能滿足結(jié)構(gòu)的地址對(duì)齊了,因此我們要把結(jié)構(gòu)補(bǔ)充成有效對(duì)齊大小的整數(shù)倍.其實(shí)諸如:對(duì)于char型數(shù)據(jù)，其自身對(duì)齊值為1，對(duì)于short型為2，對(duì)于int,float,double類型，其自身對(duì)齊值為4，這些已有類型的自身對(duì)齊值也是基于數(shù)組考慮的,只是因?yàn)檫@些類型的長(zhǎng)度已知了,所以他們的自身對(duì)齊值也就已知了.
同理,分析上面例子C：
#pragma pack (2) /*指定按2字節(jié)對(duì)齊*/
struct C
{
??? char b;
??? int a;
??? short c;
};
#pragma pack () /*取消指定對(duì)齊，恢復(fù)缺省對(duì)齊*/
第一個(gè)變量b的自身對(duì)齊值為1，指定對(duì)齊值為2，所以，其有效對(duì)齊值為1，假設(shè)C從0x0000開始，那么b存放在0x0000，符合0x0000%1= 0;第二個(gè)變量，自身對(duì)齊值為4，指定對(duì)齊值為2，所以有效對(duì)齊值為2，所以順序存放在0x0002、0x0003、0x0004、0x0005四個(gè)連續(xù)字節(jié)中，符合0x0002%2=0。第三個(gè)變量c的自身對(duì)齊值為2，所以有效對(duì)齊值為2，順序存放
在0x0006、0x0007中，符合 0x0006%2=0。所以從0x0000到0x00007共八字節(jié)存放的是C的變量。又C的自身對(duì)齊值為4，所以C的有效對(duì)齊值為2。又8%2=0,C 只占用0x0000到0x0007的八個(gè)字節(jié)。所以sizeof(struct C)=8.
四.如何修改編譯器的默認(rèn)對(duì)齊值?
1.在VC IDE中，可以這樣修改：[Project]|[Settings],c/c++選項(xiàng)卡Category的Code Generation選項(xiàng)的Struct Member Alignment中修改，默認(rèn)是8字節(jié)。
2.在編碼時(shí)，可以這樣動(dòng)態(tài)修改：#pragma pack .注意:是pragma而不是progma.
五.針對(duì)字節(jié)對(duì)齊,我們?cè)诰幊讨腥绾慰紤]?
??? 如果在編程的時(shí)候要考慮節(jié)約空間的話,那么我們只需要假定結(jié)構(gòu)的首地址是0,然后各個(gè)變量按照上面的原則進(jìn)行排列即可,基本的原則就是把結(jié)構(gòu)中的變量按照類型大小從小到大聲明,盡量減少中間的填補(bǔ)空間.還有一種就是為了以空間換取時(shí)間的效率,我們顯示的進(jìn)行填補(bǔ)空間進(jìn)行對(duì)齊,比如:有一種使用空間換時(shí)間做法是顯式的插入reserved成員：
???????? struct A{
?????????? char a;
?????????? char reserved[3];//使用空間換時(shí)間
?????????? int b;
}
reserved成員對(duì)我們的程序沒有什么意義,它只是起到填補(bǔ)空間以達(dá)到字節(jié)對(duì)齊的目的,當(dāng)然即使不加這個(gè)成員通常編譯器也會(huì)給我們自動(dòng)填補(bǔ)對(duì)齊,我們自己加上它只是起到顯式的提醒作用.
六.字節(jié)對(duì)齊可能帶來的隱患:
??? 代碼中關(guān)于對(duì)齊的隱患，很多是隱式的。比如在強(qiáng)制類型轉(zhuǎn)換的時(shí)候。例如：
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;
p=&i;
*p=0x00;
p1=(unsigned short *)(p+1);
*p1=0x0000;
最后兩句代碼，從奇數(shù)邊界去訪問unsignedshort型變量，顯然不符合對(duì)齊的規(guī)定。
在x86上，類似的操作只會(huì)影響效率，但是在MIPS或者sparc上，可能就是一個(gè)error,因?yàn)樗鼈円蟊仨氉止?jié)對(duì)齊.
七.如何查找與字節(jié)對(duì)齊方面的問題:
如果出現(xiàn)對(duì)齊或者賦值問題首先查看
1. 編譯器的big little端設(shè)置
2. 看這種體系本身是否支持非對(duì)齊訪問
3. 如果支持看設(shè)置了對(duì)齊與否,如果沒有則看訪問時(shí)需要加某些特殊的修飾來標(biāo)志其特殊訪問操作。
?ARM下的對(duì)齊處理
from DUI0067D_ADS1_2_CompLib
3.13 type? qulifiers
有部分摘自ARM編譯器文檔對(duì)齊部分
對(duì)齊的使用:
1.__align(num)
?? 這個(gè)用于修改最高級(jí)別對(duì)象的字節(jié)邊界。在匯編中使用LDRD或者STRD時(shí)
?? 就要用到此命令__align(8)進(jìn)行修飾限制。來保證數(shù)據(jù)對(duì)象是相應(yīng)對(duì)齊。
?? 這個(gè)修飾對(duì)象的命令最大是8個(gè)字節(jié)限制,可以讓2字節(jié)的對(duì)象進(jìn)行4字節(jié)
?? 對(duì)齊,但是不能讓4字節(jié)的對(duì)象2字節(jié)對(duì)齊。
?? __align是存儲(chǔ)類修改,他只修飾最高級(jí)類型對(duì)象不能用于結(jié)構(gòu)或者函數(shù)對(duì)象。
?
2.__packed
? __packed是進(jìn)行一字節(jié)對(duì)齊
? 1.不能對(duì)packed的對(duì)象進(jìn)行對(duì)齊
? 2.所有對(duì)象的讀寫訪問都進(jìn)行非對(duì)齊訪問
? 3.float及包含float的結(jié)構(gòu)聯(lián)合及未用__packed的對(duì)象將不能字節(jié)對(duì)齊
? 4.__packed對(duì)局部整形變量無影響
? 5.強(qiáng)制由unpacked對(duì)象向packed對(duì)象轉(zhuǎn)化是未定義,整形指針可以合法定
? 義為packed。
???? __packed int* p;? //__packed int 則沒有意義
? 6.對(duì)齊或非對(duì)齊讀寫訪問帶來問題
? __packed struct STRUCT_TEST
?{
? char a;
? int b;
? char c;
?}? ;??? //定義如下結(jié)構(gòu)此時(shí)b的起始地址一定是不對(duì)齊的
???????? //在棧中訪問b可能有問題,因?yàn)闂Ｉ蠑?shù)據(jù)肯定是對(duì)齊訪問[from CL]
//將下面變量定義成全局靜態(tài)不在棧上
static char* p;
static struct STRUCT_TEST a;
void Main()
{
?__packed int* q;? //此時(shí)定義成__packed來修飾當(dāng)前q指向?yàn)榉菍?duì)齊的數(shù)據(jù)地址下面的訪問則可以
?p = (char*)&a;?????????
?q = (int*)(p+1);?????
?
?*q = 0x87654321;
/*??
得到賦值的匯編指令很清楚
ldr????? r5,0x20001590 ; = #0x12345678
[0xe1a00005]?? mov????? r0,r5
[0xeb0000b0]?? bl?????? __rt_uwrite4? //在此處調(diào)用一個(gè)寫4byte的操作函數(shù)
?
[0xe5c10000]?? strb???? r0,[r1,#0]?? //函數(shù)進(jìn)行4次strb操作然后返回保證了數(shù)據(jù)正確的訪問
[0xe1a02420]?? mov????? r2,r0,lsr #8
[0xe5c12001]?? strb???? r2,[r1,#1]
[0xe1a02820]?? mov????? r2,r0,lsr #16
[0xe5c12002]?? strb???? r2,[r1,#2]
[0xe1a02c20]?? mov????? r2,r0,lsr #24
[0xe5c12003]?? strb???? r2,[r1,#3]
[0xe1a0f00e]?? mov????? pc,r14
*/
/*
如果q沒有加__packed修飾則匯編出來指令是這樣直接會(huì)導(dǎo)致奇地址處訪問失敗
[0xe59f2018]?? ldr????? r2,0x20001594 ; = #0x87654321
[0xe5812000]?? str????? r2,[r1,#0]
*/
//這樣可以很清楚的看到非對(duì)齊訪問是如何產(chǎn)生錯(cuò)誤的
//以及如何消除非對(duì)齊訪問帶來問題
//也可以看到非對(duì)齊訪問和對(duì)齊訪問的指令差異導(dǎo)致效率問題
}?
?
sizeof進(jìn)行結(jié)構(gòu)體大小的判斷
typedef struct
{
????int a;
????char b;
}A_t;
typedef struct
{
????int a;
????char b;
????char c;
}B_t;
typedef struct
{
????char a;
????int b;
????char c;
}C_t;
void main()
{
????char*a=0;
????cout<<sizeof(a)<<endl;//4
????cout<<sizeof(*a)<<endl;//1--這個(gè)能理解
???????? cout<<sizeof(A_t)<<endl;//8
???????? cout<<sizeof(B_t)<<endl;//8
????cout<<sizeof(C_t)<<endl;//12
}
為什么是這樣的結(jié)果啊？
2. 語法：
sizeof有三種語法形式，如下：
1) sizeof( object ); // sizeof( 對(duì)象 );
2) sizeof( type_name ); // sizeof( 類型 );
3) sizeof object; // sizeof 對(duì)象;
5. 指針變量的sizeof
既然是來存放地址的，那么它當(dāng)然等于計(jì)算機(jī)內(nèi)部地址總線的寬度。所以在32位計(jì)算機(jī)中，一
個(gè)指針變量的返回值必定是4（以字節(jié)為單位），可以預(yù)計(jì)，在將來的64位系統(tǒng)
中指針變量的sizeof結(jié)果為8。
char* pc = "abc";
int* pi;
string* ps;
char** ppc = &pc;
void (*pf)();// 函數(shù)指針
sizeof( pc ); // 結(jié)果為4
sizeof( pi ); // 結(jié)果為4
sizeof( ps ); // 結(jié)果為4
sizeof( ppc ); // 結(jié)果為4
sizeof( pf );// 結(jié)果為4
指針變量的sizeof值與指針?biāo)傅膶?duì)象沒有任何關(guān)系，正是由于所有的指針變量所占內(nèi)存
大小相等，所以MFC消息處理函數(shù)使用兩個(gè)參數(shù)WPARAM、LPARAM就能傳遞各種復(fù)雜的消息結(jié)
構(gòu)（使用指向結(jié)構(gòu)體的指針）。
6. 數(shù)組的sizeof
數(shù)組的sizeof值等于數(shù)組所占用的內(nèi)存字節(jié)數(shù)，如：
char a1[] = "abc";
int a2[3];
sizeof( a1 ); // 結(jié)果為4，字符串末尾還存在一個(gè)NULL終止符
sizeof( a2 ); // 結(jié)果為3*4=12（依賴于int）
一些朋友剛開始時(shí)把sizeof當(dāng)作了求數(shù)組元素的個(gè)數(shù)，現(xiàn)在，你應(yīng)該知道這是不對(duì)的，那
么應(yīng)該怎么求數(shù)組元素的個(gè)數(shù)呢？Easy，通常有下面兩種寫法：
int c1 = sizeof( a1 ) / sizeof( char ); // 總長(zhǎng)度/單個(gè)元素的長(zhǎng)度
int c2 = sizeof( a1 ) / sizeof( a1[0] ); // 總長(zhǎng)度/第一個(gè)元素的長(zhǎng)度
寫到這里，提一問，下面的c3，c4值應(yīng)該是多少呢？
void foo3(char a3[3])
{
int c3 = sizeof( a3 ); // c3 ==
}
void foo4(char a4[])
{
int c4 = sizeof( a4 ); // c4 ==
}
也許當(dāng)你試圖回答c4的值時(shí)已經(jīng)意識(shí)到c3答錯(cuò)了，是的，c3!=3。這里函數(shù)參數(shù)a3已不再是
數(shù)組類型，而是蛻變成指針，相當(dāng)于char* a3，為什么？仔細(xì)想想就不難明白，我們調(diào)用
函數(shù)foo1時(shí)，程序會(huì)在棧上分配一個(gè)大小為3的數(shù)組嗎？不會(huì)！數(shù)組是“傳址”的，調(diào)用者
只需將實(shí)參的地址傳遞過去，所以a3自然為指針類型（char*），c3的值也就為4。
7. 結(jié)構(gòu)體的sizeof
這是初學(xué)者問得最多的一個(gè)問題，所以這里有必要多費(fèi)點(diǎn)筆墨。讓我們先看一個(gè)結(jié)構(gòu)體：
struct S1
{
char c;
int i;
};
問sizeof(s1)等于多少？聰明的你開始思考了，char占1個(gè)字節(jié)，int占4個(gè)字節(jié)，那么加起
來就應(yīng)該是5。是這樣嗎？你在你機(jī)器上試過了嗎？也許你是對(duì)的，但很可能你是錯(cuò)的！V
C6中按默認(rèn)設(shè)置得到的結(jié)果為8。
Why？為什么受傷的總是我？
請(qǐng)不要沮喪，我們來好好琢磨一下sizeof的定義——sizeof的結(jié)果等于對(duì)象或者類型所占
的內(nèi)存字節(jié)數(shù)，好吧，那就讓我們來看看S1的內(nèi)存分配情況：
S1 s1 = {??a , 0xFFFFFFFF };
定義上面的變量后，加上斷點(diǎn)，運(yùn)行程序，觀察s1所在的內(nèi)存，你發(fā)現(xiàn)了什么？
以我的VC6.0為例，s1的地址為0x0012FF78，其數(shù)據(jù)內(nèi)容如下：
0012FF78: 61 CC CC CC FF FF FF FF
發(fā)現(xiàn)了什么？怎么中間夾雜了3個(gè)字節(jié)的CC？看看MSDN上的說明：
When applied to a structure type or variable, sizeof returns the actual size,
which may include padding bytes inserted for alignment.
原來如此，這就是傳說中的字節(jié)對(duì)齊啊！一個(gè)重要的話題出現(xiàn)了。
為什么需要字節(jié)對(duì)齊？計(jì)算機(jī)組成原理教導(dǎo)我們這樣有助于加快計(jì)算機(jī)的取數(shù)速度，否則
就得多花指令周期了。為此，編譯器默認(rèn)會(huì)對(duì)結(jié)構(gòu)體進(jìn)行處理（實(shí)際上其它地方的數(shù)據(jù)變
量也是如此），讓寬度為2的基本數(shù)據(jù)類型（short等）都位于能被2整除的地址上，讓寬度
為4的基本數(shù)據(jù)類型（int等）都位于能被4整除的地址上，以此類推。這樣，兩個(gè)數(shù)中間就
可能需要加入填充字節(jié)，所以整個(gè)結(jié)構(gòu)體的sizeof值就增長(zhǎng)了。
讓我們交換一下S1中char與int的位置：
struct S2
{
int i;
char c;
};
看看sizeof(S2)的結(jié)果為多少，怎么還是8？再看看內(nèi)存，原來成員c后面仍然有3個(gè)填充字
節(jié)，這又是為什么啊？別著急，下面總結(jié)規(guī)律。
字節(jié)對(duì)齊的細(xì)節(jié)和編譯器實(shí)現(xiàn)相關(guān)，但一般而言，滿足三個(gè)準(zhǔn)則：
1) 結(jié)構(gòu)體變量的首地址能夠被其最寬基本類型成員的大小所整除；
2) 結(jié)構(gòu)體每個(gè)成員相對(duì)于結(jié)構(gòu)體首地址的偏移量（offset）都是成員大小的整數(shù)倍，如有
需要編譯器會(huì)在成員之間加上填充字節(jié)（internal adding）；
3) 結(jié)構(gòu)體的總大小為結(jié)構(gòu)體最寬基本類型成員大小的整數(shù)倍，如有需要編譯器會(huì)在最末一
個(gè)成員之后加上填充字節(jié)（trailing padding）。
對(duì)于上面的準(zhǔn)則，有幾點(diǎn)需要說明：
1) 前面不是說結(jié)構(gòu)體成員的地址是其大小的整數(shù)倍，怎么又說到偏移量了呢？因?yàn)橛辛说?/p>
1點(diǎn)存在，所以我們就可以只考慮成員的偏移量，這樣思考起來簡(jiǎn)單。想想為什么。
結(jié)構(gòu)體某個(gè)成員相對(duì)于結(jié)構(gòu)體首地址的偏移量可以通過宏offsetof()來獲得，這個(gè)宏也在
stddef.h中定義，如下：
#define offsetof(s,m) (size_t)&(((s *)0)->m)
例如，想要獲得S2中c的偏移量，方法為
size_t pos = offsetof(S2, c);// pos等于4
2) 基本類型是指前面提到的像char、short、int、float、double這樣的內(nèi)置數(shù)據(jù)類型，
這里所說的“數(shù)據(jù)寬度”就是指其sizeof的大小。由于結(jié)構(gòu)體的成員可以是復(fù)合類型，比
如另外一個(gè)結(jié)構(gòu)體，所以在尋找最寬基本類型成員時(shí)，應(yīng)當(dāng)包括復(fù)合類型成員的子成員，
而不是把復(fù)合成員看成是一個(gè)整體。但在確定復(fù)合類型成員的偏移位置時(shí)則是將復(fù)合類型
作為整體看待。
這里敘述起來有點(diǎn)拗口，思考起來也有點(diǎn)撓頭，還是讓我們看看例子吧（具體數(shù)值仍以VC
6為例，以后不再說明）：
struct S3
{
char c1;
S1 s;
char c2
};
S1的最寬簡(jiǎn)單成員的類型為int，S3在考慮最寬簡(jiǎn)單類型成員時(shí)是將S1“打散”看的，所以
S3的最寬簡(jiǎn)單類型為int，這樣，通過S3定義的變量，其存儲(chǔ)空間首地址需要被4整除，整
個(gè)sizeof(S3)的值也應(yīng)該被4整除。
c1的偏移量為0，s的偏移量呢？這時(shí)s是一個(gè)整體，它作為結(jié)構(gòu)體變量也滿足前面三個(gè)準(zhǔn)則
，所以其大小為8，偏移量為4，c1與s之間便需要3個(gè)填充字節(jié)，而c2與s之間就不需要了，
所以c2的偏移量為12，算上c2的大小為13，13是不能被4整除的，這樣末尾還得補(bǔ)上3個(gè)填
充字節(jié)。最后得到sizeof(S3)的值為16。
通過上面的敘述，我們可以得到一個(gè)公式：
結(jié)構(gòu)體的大小等于最后一個(gè)成員的偏移量加上其大小再加上末尾的填充字節(jié)數(shù)目，即：
sizeof( struct ) = offsetof( last item ) + sizeof( last item ) + sizeof( trail
ing padding )
到這里，朋友們應(yīng)該對(duì)結(jié)構(gòu)體的sizeof有了一個(gè)全新的認(rèn)識(shí)，但不要高興得太早，有一個(gè)
影響sizeof的重要參量還未被提及，那便是編譯器的pack指令。它是用來調(diào)整結(jié)構(gòu)體對(duì)齊
方式的，不同編譯器名稱和用法略有不同，VC6中通過#pragma pack實(shí)現(xiàn)，也可以直接修改
/Zp編譯開關(guān)。#pragma pack的基本用法為：#pragma pack( n )，n為字節(jié)對(duì)齊數(shù)，其取值
為1、2、4、8、16，默認(rèn)是8，如果這個(gè)值比結(jié)構(gòu)體成員的sizeof值小，那么該成員的偏移
量應(yīng)該以此值為準(zhǔn)，即是說，結(jié)構(gòu)體成員的偏移量應(yīng)該取二者的最小值，公式如下：
offsetof( item ) = min( n, sizeof( item ) )
再看示例：
#pragma pack(push) // 將當(dāng)前pack設(shè)置壓棧保存
#pragma pack(2)// 必須在結(jié)構(gòu)體定義之前使用
struct S1
{
char c;
int i;
};
struct S3
{
char c1;
S1 s;
char c2
};
#pragma pack(pop) // 恢復(fù)先前的pack設(shè)置
計(jì)算sizeof(S1)時(shí)，min(2, sizeof(i))的值為2，所以i的偏移量為2，加上sizeof(i)等于
6，能夠被2整除，所以整個(gè)S1的大小為6。
同樣，對(duì)于sizeof(S3)，s的偏移量為2，c2的偏移量為8，加上sizeof(c2)等于9，不能被
2整除，添加一個(gè)填充字節(jié)，所以sizeof(S3)等于10。
現(xiàn)在，朋友們可以輕松的出一口氣了，
還有一點(diǎn)要注意，“空結(jié)構(gòu)體”（不含數(shù)據(jù)成員）的大小不為0，而是1。試想一個(gè)“不占
空間”的變量如何被取地址、兩個(gè)不同的“空結(jié)構(gòu)體”變量又如何得以區(qū)分呢？于是，“
空結(jié)構(gòu)體”變量也得被存儲(chǔ)，這樣編譯器也就只能為其分配一個(gè)字節(jié)的空間用于占位了。
如下：
struct S5 { };
sizeof( S5 ); // 結(jié)果為1
8. 含位域結(jié)構(gòu)體的sizeof
前面已經(jīng)說過，位域成員不能單獨(dú)被取sizeof值，我們這里要討論的是含有位域的結(jié)構(gòu)體
的sizeof，只是考慮到其特殊性而將其專門列了出來。
C99規(guī)定int、unsigned int和bool可以作為位域類型，但編譯器幾乎都對(duì)此作了擴(kuò)展，允
許其它類型類型的存在。
使用位域的主要目的是壓縮存儲(chǔ)，其大致規(guī)則為：
1) 如果相鄰位域字段的類型相同，且其位寬之和小于類型的sizeof大小，則后面的字段將
緊鄰前一個(gè)字段存儲(chǔ)，直到不能容納為止；
2) 如果相鄰位域字段的類型相同，但其位寬之和大于類型的sizeof大小，則后面的字段將
從新的存儲(chǔ)單元開始，其偏移量為其類型大小的整數(shù)倍；
3) 如果相鄰的位域字段的類型不同，則各編譯器的具體實(shí)現(xiàn)有差異，VC6采取不壓縮方式
，Dev-C++采取壓縮方式；
4) 如果位域字段之間穿插著非位域字段，則不進(jìn)行壓縮；
5) 整個(gè)結(jié)構(gòu)體的總大小為最寬基本類型成員大小的整數(shù)倍。
還是讓我們來看看例子。
示例1：
struct BF1
{
char f1 : 3;
char f2 : 4;
char f3 : 5;
};
其內(nèi)存布局為：
|_f1__|__f2__|_|____f3___|____|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
0 3?? 7 8?? 1316
位域類型為char，第1個(gè)字節(jié)僅能容納下f1和f2，所以f2被壓縮到第1個(gè)字節(jié)中，而f3只能
從下一個(gè)字節(jié)開始。因此sizeof(BF1)的結(jié)果為2。
示例2：
struct BF2
{
char f1 : 3;
short f2 : 4;
char f3 : 5;
};
由于相鄰位域類型不同，在VC6中其sizeof為6，在Dev-C++中為2。
示例3：
struct BF3
{
char f1 : 3;
char f2;
char f3 : 5;
};
非位域字段穿插在其中，不會(huì)產(chǎn)生壓縮，在VC6和Dev-C++中得到的大小均為3。
9. 聯(lián)合體的sizeof
結(jié)構(gòu)體在內(nèi)存組織上是順序式的，聯(lián)合體則是重疊式，各成員共享一段內(nèi)存，所以整個(gè)聯(lián)
合體的sizeof也就是每個(gè)成員sizeof的最大值。結(jié)構(gòu)體的成員也可以是復(fù)合類型，這里，
復(fù)合類型成員是被作為整體考慮的。
所以，下面例子中，U的sizeof值等于sizeof(s)。
union U
{
int i;
char c;
S1 s;
};
?
詳解結(jié)構(gòu)體、類等內(nèi)存字節(jié)對(duì)齊
?
http://www.2cto.com/kf/201109/105769.html
?
先說個(gè)題外話：早些年我學(xué)C程序設(shè)計(jì)時(shí)，寫過一段解釋硬盤MBR分區(qū)表的代碼，對(duì)著磁盤編輯器怎么看，怎么對(duì)，可一執(zhí)行，結(jié)果就錯(cuò)了。當(dāng)時(shí)調(diào)試也不太會(huì)，又根本沒聽過結(jié)構(gòu)體對(duì)齊這一說，所以，問題解決不了，好幾天都十分糾結(jié)。后來萬般無奈請(qǐng)教一個(gè)朋友，才獲悉可能是結(jié)構(gòu)體對(duì)齊的事，一查、一改，果真 如此。
????問題是解決了，可網(wǎng)上的資料多數(shù)只提到內(nèi)存對(duì)齊是如何做的，卻鮮有提及為什么這樣做(即使提，也相當(dāng)簡(jiǎn)單)。筆者是個(gè)超級(jí)健忘者，很難機(jī)械式的記住這些破規(guī)則，于是仔細(xì)想了想，總算明白了原因，這樣，這些對(duì)齊的規(guī)則也就不會(huì)再輕易忘記了。????
??? 不光結(jié)構(gòu)體存在內(nèi)存對(duì)齊一說，類(對(duì)象)也如此，甚至于所有變量在內(nèi)存中的存儲(chǔ)也有對(duì)齊一說(只是這些對(duì)程序員是透明的，不需要關(guān)心)。實(shí)際上，這種對(duì)齊 是為了在空間與復(fù)雜度上達(dá)到平衡的一種技術(shù)手段，簡(jiǎn)單的講，是為了在可接受的空間浪費(fèi)的前提下，盡可能的提高對(duì)相同運(yùn)算過程的最少(快)處理。先舉個(gè)例 子：
????假設(shè)機(jī)器字長(zhǎng)是32位的(即4字節(jié)，下面示例均按此字長(zhǎng))，也就是說處理任何內(nèi)存中的數(shù)據(jù)，其實(shí)都是按32位的單位進(jìn)行的。現(xiàn)在有2個(gè)變量：???
char A;
int B;
???? 假設(shè)這2個(gè)變量是從內(nèi)存地址0開始分配的，如果不考慮對(duì)齊，應(yīng)該是這樣存儲(chǔ)的(見下圖,以intel上的little endian為例，為了形象，每16個(gè)字節(jié)分做一行，后同)：
????因?yàn)橛?jì)算機(jī)的字長(zhǎng)是4字節(jié)的，所以在處理變量A與B時(shí)的過程可能大致為：
??? A:將0x00-0x03共32位讀入寄存器，再通過左移24位再右移24位運(yùn)算得到a的值(或與0x000000FF做與運(yùn)算)
??? B:將0x00-0x03這32位讀入寄存器，通過位運(yùn)算得到低24位的值；再將0x04-0x07這32位讀入寄存器，通過位運(yùn)算得到高8位的值；再與最先得到的24位做位運(yùn)算，才可得到整個(gè)32位的值。
????上面敘述可知，對(duì)a的處理是最簡(jiǎn)處理，可對(duì)b的處理，本身是個(gè)32位數(shù)，處理的時(shí)候卻得折成2部分，之后再合并，效率上就有些低了。
????想解決這個(gè)問題，就需要付出幾個(gè)字節(jié)浪費(fèi)的代價(jià)，改為下圖的分配方式：
??? 按上面的分配方式，A的處理過程不變；B卻簡(jiǎn)單得多了：只需將0x04-0x07這32位讀入寄存器就OK了。
????我們可以具體談結(jié)構(gòu)體或類成員的對(duì)齊了：
????結(jié)構(gòu)體在編譯成機(jī)器代碼后，其實(shí)就沒有本身的集合概念了，而類，實(shí)際上是個(gè)加強(qiáng)版的結(jié)構(gòu)體，類的對(duì)象在實(shí)例化時(shí)，內(nèi)存中申請(qǐng)的就是一些變量的空間集合(類 似于結(jié)構(gòu)體，同時(shí)也不包含函數(shù)指針)。這些集合中的每個(gè)變量，在使用中，都需要涉及上述的加工原則，自然也就需要在效率與空間之間做出權(quán)衡。
????為了便捷加工連續(xù)多個(gè)相同類型原始變量，同時(shí)簡(jiǎn)化原始變量尋址，再匯總上述最少處理原則，通常可以將原始變量的長(zhǎng)度做為針對(duì)此變量的分配單位，比如內(nèi)存可用64個(gè)單元，如果某原始變量長(zhǎng)度為8字節(jié)，即使機(jī)器字長(zhǎng)為4字節(jié)，分配的時(shí)候也以8字節(jié)對(duì)齊(看似IO次數(shù)是相同的)，這樣，尋址、分配時(shí)，均可以按每 8字節(jié)為單位進(jìn)行，簡(jiǎn)化了操作，也可以更高效。
????系統(tǒng)默認(rèn)的對(duì)齊規(guī)則，追求的至少兩點(diǎn)：1、變量的最高效加工 2、達(dá)到目的1的最少空間
????舉個(gè)例子，一個(gè)結(jié)構(gòu)體如下：
?
//by?www.datahf.net?zhangyu
typedef struct T
{
??? char c; //本身長(zhǎng)度1字節(jié)
??? __int64 d;? //本身長(zhǎng)度8字節(jié)
??? int e;? //本身長(zhǎng)度4字節(jié)
??? short f;? //本身長(zhǎng)度2字節(jié)
??? char g;? //本身長(zhǎng)度1字節(jié)
??? short h;? //本身長(zhǎng)度2字節(jié)
};
????假設(shè)定義了一個(gè)結(jié)構(gòu)體變量C，在內(nèi)存中分配到了0x00的位置，顯然：
????對(duì)于成員C.c? 無論如何，也是一次寄存器讀入，所以先占一個(gè)字節(jié)。
????對(duì)于成員C.d? 是個(gè)64位的變量，如果緊跟著C.c存儲(chǔ)，則讀入寄存器至少需要3次，為了實(shí)現(xiàn)最少的2次讀入，至少需要以4字節(jié)對(duì)齊；同時(shí)對(duì)于8字節(jié)的原始變量，為了在尋址單位上統(tǒng)一，則需要按8字節(jié)對(duì)齊，所以，應(yīng)該分配到0x08-0xF的位置。
????對(duì)于成員C.e? 是個(gè)32位的變量，自然只需滿足分配起始為整數(shù)個(gè)32位即可，所以分配至0x10-0x13。
????對(duì)于成員C.f? 是個(gè)16位的變量，直接分配在0x14-0x16上，這樣，反正只需一次讀入寄存器后加工，邊界也與16位對(duì)齊。
????對(duì)于成員C.g? 是個(gè)8位的變量，本身也得一次讀入寄存器后加工，同時(shí)對(duì)于1個(gè)字節(jié)的變量，存儲(chǔ)在任何字節(jié)開始都是對(duì)齊，所以，分配到0x17的位置。
????對(duì)于成員C.h? 是個(gè)16位的變量，為了保證與16位邊界對(duì)齊，所以，分配到0x18-0x1A的位置。
????分配圖如下(還不正確，耐心讀下去)：
??? 結(jié)構(gòu)體C的占用空間到h結(jié)束就可以了嗎?我們找個(gè)示例：如果定義一個(gè)結(jié)構(gòu)體數(shù)組 CA[2]，按變量分配的原則，這2個(gè)結(jié)構(gòu)體應(yīng)該是在內(nèi)存中連續(xù)存儲(chǔ)的，分配應(yīng)該如下圖：
?
??? 分析一下上圖，明顯可知，CA[1]的很多成員都不再對(duì)齊了，究其原因，是結(jié)構(gòu)體的開始邊界不對(duì)齊。
????那結(jié)構(gòu)體的開始偏移滿足什么條件才可以使其成員全部對(duì)齊呢。想一想就明白了：很簡(jiǎn)單，保證結(jié)構(gòu)體長(zhǎng)度是原始成員最長(zhǎng)分配的整數(shù)倍即可。
????上述結(jié)構(gòu)體應(yīng)該按最長(zhǎng)的.d成員對(duì)齊，即與8字節(jié)對(duì)齊，這樣正確的分配圖如下：
??? 當(dāng)然結(jié)構(gòu)體T的長(zhǎng)度:sizeof(T)==0x20;
???? 再舉個(gè)例子，看看在默認(rèn)對(duì)齊規(guī)則下，各結(jié)構(gòu)體成員的對(duì)齊規(guī)則：
?
//by?www.datahf.net?zhangyu
typedef struct A
{
??? char c;? //1個(gè)字節(jié)
??? int d;? //4個(gè)字節(jié)，要與4字節(jié)對(duì)齊，所以分配至第4個(gè)字節(jié)處
??? short e;? //2個(gè)字節(jié)， 上述兩個(gè)成員過后，本身就是與2對(duì)齊的，所以之前無填充
?}; //整個(gè)結(jié)構(gòu)體，最長(zhǎng)的成員為4個(gè)字節(jié)，需要總長(zhǎng)度與4字節(jié)對(duì)齊，所以，?sizeof(A)==12
typedef struct B
{
??? char c;? //1個(gè)字節(jié)
??? __int64 d;? //8個(gè)字節(jié)，位置要與8字節(jié)對(duì)齊，所以分配到第8個(gè)字節(jié)處
??? int e;? //4個(gè)字節(jié)，成員d結(jié)束于15字節(jié)，緊跟的16字節(jié)對(duì)齊于4字節(jié)，所以分配到16-19
??? short f;? //2個(gè)字節(jié)，成員e結(jié)束于19字節(jié)，緊跟的20字節(jié)對(duì)齊于2字節(jié)，所以分配到20-21
??? A g;? //結(jié)構(gòu)體長(zhǎng)為12字節(jié)，最長(zhǎng)成員為4字節(jié)，需按4字節(jié)對(duì)齊，所以前面跳過2個(gè)字節(jié),
//到24-35字節(jié)處
??? char h;?? //1個(gè)字節(jié)，分配到36字節(jié)處
??? int i;?? //4個(gè)字節(jié)，要對(duì)齊4字節(jié)，跳過3字節(jié)，分配到40-43 字節(jié)
}; //整個(gè)結(jié)構(gòu)體的最大分配成員為8字節(jié)，所以結(jié)構(gòu)體后面加5字節(jié)填充，被到48字節(jié)。故：
//sizeof(B)==48;
????具體的分配圖如下：
?
?上述全部測(cè)試代碼如下：
?
//by?www.datahf.net?zhangyu
#include "stdio.h"
typedef struct A
{
??? char c;
??? int d;
??? short e;
?
};
typedef struct B
{
??? char c;
??? __int64 d;
??? int e;
??? short f;
??? A g;
??? char h;
??? int i;
};
typedef struct C
{
??? char c;
??? __int64 d;
??? int e;
??? short f;
??? char g;
??? short h;
};
typedef struct D
{
??? char a;
??? short b;
??? char c;
};
int main()
{
?
??? B *b=new B;
??? void *s[32];
??? s[0]=b;
??? s[1]=&b->c;
??? s[2]=&b->d;
??? s[3]=&b->e;
??? s[4]=&b->f;
??? s[5]=&b->g;
??? s[6]=&b->h;
??? s[7]=&b->g.c;
??? s[8]=&b->g.d;
??? s[9]=&b->g.e;
??? s[10]=&b->i;
??? b->c= 0x11;
??? b->d= 0x2222222222222222;
??? b->e= 0x33333333;
??? b->f=0x4444;
??? b->g.c=0x50;
??? b->g.d=0x51515151;
??? b->g.e=0x5252;
??? b->h=0x66;
??? int i1=sizeof(A);
??? int i2=sizeof(B);
??? int i3=sizeof(C);
??? int i4=sizeof(D);
??? printf("i1:%d\ni2:%d\ni3:%d\ni4:%d\n",i1,i2,i3,i4);//12 48 32 6
}
運(yùn)行時(shí)的內(nèi)存情況如下圖：
?
最后，簡(jiǎn)單加工一下轉(zhuǎn)載過來的內(nèi)存對(duì)齊正式原則：
?
??先介紹四個(gè)概念：
1)數(shù)據(jù)類型自身的對(duì)齊值：基本數(shù)據(jù)類型的自身對(duì)齊值，等于sizeof(基本數(shù)據(jù)類型)。
2)指定對(duì)齊值：#pragma pack (value)時(shí)的指定對(duì)齊值value。
3)結(jié)構(gòu)體或者類的自身對(duì)齊值：其成員中自身對(duì)齊值最大的那個(gè)值。
4)數(shù)據(jù)成員、結(jié)構(gòu)體和類的有效對(duì)齊值：自身對(duì)齊值和指定對(duì)齊值中較小的那個(gè)值。
??有效對(duì)齊值N是最終用來決定數(shù)據(jù)存放地址方式的值，最重要。有效對(duì)齊N，就是表示“對(duì)齊在N上”，也就是說該數(shù)據(jù)的"存放起始地址%N=0".而數(shù)據(jù)結(jié)構(gòu) 中的數(shù)據(jù)變量都是按定義的先后順序來排放的。第一個(gè)數(shù)據(jù)變量的起始地址就是 數(shù)據(jù)結(jié)構(gòu)的起始地址。結(jié)構(gòu)體的成員變量要對(duì)齊排放，結(jié)構(gòu)體本身也要根據(jù)自身的有效對(duì)齊值圓整(就是結(jié)構(gòu)體成員變量占用總長(zhǎng)度需要是對(duì)結(jié)構(gòu)體有效對(duì)齊值的整 數(shù)倍)
?
#pragma pack (value)來告訴編譯器，使用我們指定的對(duì)齊值來取代缺省的。
如#pragma pack (1)? /*指定按2字節(jié)對(duì)齊*/
#pragma pack () /*取消指定對(duì)齊，恢復(fù)缺省對(duì)齊*/
?
?
作者“張宇(數(shù)據(jù)恢復(fù))”
?
?
[StructLayout(LayoutKind.Explicit)]
????public?struct?pp
????{
????????[FieldOffset(4)]
????????public?tt?ts;?-------這個(gè)大小是56
????????[FieldOffset(1)]
????????public?char?errorcode;-----這個(gè)應(yīng)該是1
????????
????}
using?System.Runtime.InteropServices;
[StructLayout(LayoutKind.Explicit)]
struct?abc
{
?????[FieldOffset(0)]?
?????//字段.......
?????[FieldOffset(2)]
?????//字段..........
?????[FieldOffset(4)]?
?????//字段...........
}
C#中struct的內(nèi)存對(duì)齊
http://qingchina.bokee.com/3399821.html
author: 李艷慶 QQ: 375369930
date: 2005年11月3日
??? 很少有人談起struct的內(nèi)存對(duì)齊問題, 就是在很多C#書中, 也很少提及. 但在實(shí)際應(yīng)用中, 如果不注意內(nèi)存對(duì)齊, struct比較大的話, 則會(huì)浪費(fèi)一定的內(nèi)存.
??? 先從一個(gè)實(shí)例看起.
?public unsafe struct MyStruct1
?{
??byte b;
??string s;
??int i;
??char c;
?}
??? 在這個(gè)struct中, 各個(gè)成員的字節(jié)數(shù)為, b:1, s:4, i:4, c:1. s為指針, 所以為4個(gè)字節(jié). 把這些成員的字節(jié)數(shù)加起來應(yīng)該為10個(gè)字節(jié), 很多人都是這么理所當(dāng)然的認(rèn)為.但實(shí)際上呢, 卻并非如此. 可以做一個(gè)測(cè)試.
?public class test
?{
??
??public static void Main()
??{
???MyValue mv = new MyValue();
???int size = System.Runtime.InteropServices.Marshal.SizeOf(mv);
???Console.WriteLine(size.ToString());
??}
??
?}
??? 結(jié)果顯示為16個(gè)字節(jié), 與所想的有一定差距. 為什么會(huì)出現(xiàn)這種情況呢, 這就涉及到了內(nèi)存對(duì)齊的問題struct member alignment.
??? 在編譯器中使用內(nèi)存對(duì)齊, 是為了提高程序的性能. 訪問未對(duì)齊的內(nèi)存, 處理器需要做兩次的內(nèi)存訪問, 但是, 對(duì)齊的內(nèi)存, 僅需一次. 因?yàn)榫幾g器將struct與自然邊界對(duì)象. 自然邊界為偶數(shù)地址, 可以被4或8整除. 一個(gè)struct的成員字節(jié)跨越了自然邊界數(shù), 認(rèn)為是未對(duì)齊, 如果沒有跨越, 可以訪問一次就能讀取.
??? 我們?cè)賮矸治錾厦娴膕truct. struct在分配內(nèi)存的時(shí)候, 各個(gè)成員的地址是相鄰的. C#中alignment的字節(jié)數(shù)為4個(gè)字節(jié). 因此, 它將4個(gè)字節(jié)作為一個(gè)分配單元. 如果相鄰的幾個(gè)成員字節(jié)數(shù)相加不超過一個(gè)分配單元, 則這幾個(gè)成員都會(huì)在一個(gè)分配單元中. 上面的struct中, b為1個(gè)字節(jié), s為4個(gè)字節(jié), 相加后超過了一個(gè)分配單元的大小, 因此它們被分配到兩個(gè)單元中, 每個(gè)所占空間為4個(gè)字節(jié). 成員i和c的情況亦是如此. 因此, 上面的struct被分配了4個(gè)單元, 所占內(nèi)存就為16個(gè)字節(jié), 而不是簡(jiǎn)單相加所得到的10個(gè)字節(jié).
??? 現(xiàn)在我們把上面的struct做一個(gè)調(diào)整, 將byte類型和char類型相鄰.?
?public unsafe struct MyStruct2
?{
??byte b;
??char c;
??string s;
??int i;
?}
??? 現(xiàn)在再來測(cè)試一下它的內(nèi)存大小, 結(jié)果為12. 它變小了, 少了4個(gè)字節(jié). 按照上面所講的原理, b和c相加, 沒有超過4個(gè)字節(jié), 因此它們被分配到一個(gè)單元中, 總得分配單元為3個(gè), 因此結(jié)果變?yōu)?2個(gè)字節(jié).
??? 明白了這個(gè)道理, 以后在設(shè)計(jì)struct時(shí), 就要struct的成員類型和位置多做一些思考了.
?
.NET Compact Framework結(jié)構(gòu)體的對(duì)齊問題
http://www.cnblogs.com/procoder/archive/2010/08/30/NET-Compact-Framework-aligment.html
使用.NET Compact Framework進(jìn)行P/Invoke或者需要解析異構(gòu)系統(tǒng)的數(shù)據(jù)時(shí)，需要準(zhǔn)備結(jié)構(gòu)體。如下：
?
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)] internal struct TestStruct {[MarshalAs(UnmanagedType.R8)]public double f1; }?
在.NET Framework StructLayoutAttribute包含了一個(gè)Pack屬性，可以指定對(duì)齊，可是在.NET Compact Framework去掉了這個(gè)屬性，所有沒有辦法知道對(duì)齊方式的，在ARM平臺(tái)下，默認(rèn)的對(duì)齊為4.另外一個(gè)可能的解決方案是使用 TypeAttributes.ExplicitLayout，入下圖，在.NET Framework，下面的結(jié)構(gòu)體的長(zhǎng)度是10，可是在.NET Compact Framework長(zhǎng)度是12，為什么呢？
[StructLayout(LayoutKind.Explicit, CharSet = CharSet.Auto)] internal struct TestStruct {[FieldOffset(0)]public byte b1;[FieldOffset(1)]public byte b1;[FieldOffset(2)]public double f1; }
看源碼能找到原因，下面是.NET Compact Framework 2.0 StructLayoutAttribute的源代碼
[AttributeUsage(AttributeTargets.Struct | AttributeTargets.Class, Inherited = false)] public sealed class StructLayoutAttribute : Attribute {// Fieldspublic CharSet CharSet;public int Size;// Methodspublic StructLayoutAttribute(LayoutKind layoutKind){} }
下面是.NET Framework 4.0 StructLayoutAttribute的源碼
[AttributeUsage(AttributeTargets.Struct | AttributeTargets.Class, Inherited = false), ComVisible(true)] public sealed class StructLayoutAttribute : Attribute {// Fieldsinternal LayoutKind _val;public CharSet CharSet;private const int DEFAULT_PACKING_SIZE = 8;public int Pack;public int Size;// Methods[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]public StructLayoutAttribute(short layoutKind){this._val = (LayoutKind)layoutKind;}[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]public StructLayoutAttribute(LayoutKind layoutKind){this._val = layoutKind;}[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]internal StructLayoutAttribute(LayoutKind layoutKind, int pack, int size, CharSet charSet){this._val = layoutKind;this.Pack = pack;this.Size = size;this.CharSet = charSet;}[SecurityCritical]internal static Attribute GetCustomAttribute(RuntimeType type){if (!IsDefined(type)){return null;}int packSize = 0;int classSize = 0;LayoutKind auto = LayoutKind.Auto;switch ((type.Attributes & TypeAttributes.LayoutMask)){case TypeAttributes.AutoLayout:auto = LayoutKind.Auto;break;case TypeAttributes.SequentialLayout:auto = LayoutKind.Sequential;break;case TypeAttributes.ExplicitLayout:auto = LayoutKind.Explicit;break;}CharSet none = CharSet.None;TypeAttributes attributes2 = type.Attributes & TypeAttributes.CustomFormatClass;if (attributes2 == TypeAttributes.AutoLayout){none = CharSet.Ansi;}else if (attributes2 == TypeAttributes.UnicodeClass){none = CharSet.Unicode;}else if (attributes2 == TypeAttributes.AutoClass){none = CharSet.Auto;}type.GetRuntimeModule().MetadataImport.GetClassLayout(type.MetadataToken, out packSize, out classSize);if (packSize == 0){packSize = 8;}return new StructLayoutAttribute(auto, packSize, classSize, none);}internal static bool IsDefined(RuntimeType type){return ((!type.IsInterface && !type.HasElementType) && !type.IsGenericParameter);}// Propertiespublic LayoutKind Value{[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]get{return this._val;}} }在.NET Compact Framework完全沒有實(shí)現(xiàn)StructLayoutAttribute ，所有不管使用LayoutKind.Sequential還是LayoutKind.Explicit默認(rèn)還是使用Sequential。所以如果在.NET Compact Framework解析異構(gòu)系統(tǒng)的結(jié)構(gòu)體，只能使用byte[]一點(diǎn)點(diǎn)手工解析了。換句話說就是把int，float等數(shù)據(jù)類型轉(zhuǎn)換成byte的數(shù)組，然后放到相應(yīng)的位置上。
總結(jié)
以上是生活随笔為你收集整理的更改结构体的内存字节对齐方式--经典的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 结构体对齐
- 下一篇： 关于释放内存的那点事