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