當在C中定義了一個結構類型時，它的大小是否等於各字段(field)大小之和？編譯器將如何在內存中放置這些字段？ANSI C對結構體的內存佈局有什麼要求？而我們的程序又能否依賴這種佈局？這些問題或許對不少朋友來說還有點模糊，那麼本文就試着探究它們背後的祕密。
首先，至少有一點可以肯定，那就是ANSI C保證結構體中各字段在內存中出現的位置是隨它們的聲明順序依次遞增的，並且第一個字段的首地址等於整個結構體實例的首地址。比如有這樣一個結構體：
struct vector{int x,y,z;} s;
int *p,*q,*r;
struct vector *ps;
p = &s.x;
q = &s.y;
r = &s.z;
ps = &s;
assert(p < q);
assert(p < r);
assert(q < r);
assert((int*)ps == p);
// 上述斷言一定不會失敗
這時，有朋友可能會問:"標準是否規定相鄰字段在內存中也相鄰?"。 唔，對不起，ANSI C沒有做出保證，你的程序在任何時候都不應該依賴這個假設。那這是否意味着我們永遠無法勾勒出一幅更清晰更精確的結構體內存佈局圖？哦，當然不是。不過先讓我們從這個問題中暫時抽身，關注一下另一個重要問題————內存對齊。
許多實際的計算機系統對基本類型數據在內存中存放的位置有限制，它們會要求這些數據的首地址的值是某個數k(通常它爲4或8)的倍數，這就是所謂的內存對齊，而這個k則被稱爲該數據類型的對齊模數(alignment modulus)。當一種類型S的對齊模數與另一種類型T的對齊模數的比值是大於1的整數，我們就稱類型S的對齊要求比T強(嚴格)，而稱T比S弱(寬鬆)。這種強制的要求一來簡化了處理器與內存之間傳輸系統的設計，二來可以提升讀取數據的速度。比如這麼一種處理器，它每次讀寫內存的時候都從某個8倍數的地址開始，一次讀出或寫入8個字節的數據，假如軟件能保證double類型的數據都從8倍數地址開始，那麼讀或寫一個double類型數據就只需要一次內存操作。否則，我們就可能需要兩次內存操作才能完成這個動作，因爲數據或許恰好橫跨在兩個符合對齊要求的8字節內存塊上。某些處理器在數據不滿足對齊要求的情況下可能會出錯，但是Intel的IA32架構的處理器則不管數據是否對齊都能正確工作。不過Intel奉勸大家，如果想提升性能，那麼所有的程序數據都應該儘可能地對齊。Win32平臺下的微軟C編譯器(cl.exe for 80x86)在默認情況下采用如下的對齊規則: 任何基本數據類型T的對齊模數就是T的大小，即sizeof(T)。比如對於double類型(8字節)，就要求該類型數據的地址總是8的倍數，而char類型數據(1字節)則可以從任何一個地址開始。Linux下的GCC奉行的是另外一套規則(在資料中查得，並未驗證，如錯誤請指正):任何2字節大小(包括單字節嗎?)的數據類型(比如short)的對齊模數是2，而其它所有超過2字節的數據類型(比如long,double)都以4爲對齊模數。
現在回到我們關心的struct上來。ANSI C規定一種結構類型的大小是它所有字段的大小以及字段之間或字段尾部的填充區大小之和。嗯？填充區？對，這就是爲了使結構體字段滿足內存對齊要求而額外分配給結構體的空間。那麼結構體本身有什麼對齊要求嗎？有的，ANSI C標準規定結構體類型的對齊要求不能比它所有字段中要求最嚴格的那個寬鬆，可以更嚴格(但此非強制要求，VC7.1就僅僅是讓它們一樣嚴格)。我們來看一個例子(以下所有試驗的環境是Intel Celeron 2.4G + WIN2000 PRO + vc7.1，內存對齊編譯選項是"默認"，即不指定/Zp與/pack選項):
typedef struct ms1
{
char a;
int b;
} MS1;
假設MS1按如下方式內存佈局(本文所有示意圖中的內存地址從左至右遞增):
_____________________________
| | |
| a | b |
| | |
+---------------------------+
Bytes: 1 4
因爲MS1中有最強對齊要求的是b字段(int)，所以根據編譯器的對齊規則以及ANSI C標準，MS1對象的首地址一定是4(int類型的對齊模數)的倍數。那麼上述內存佈局中的b字段能滿足int類型的對齊要求嗎？嗯，當然不能。如果你是編譯器，你會如何巧妙安排來滿足CPU的癖好呢？呵呵，經過1毫秒的艱苦思考，你一定得出瞭如下的方案：
_______________________________________
| |///////////| |
| a |//padding//| b |
| |///////////| |
+-------------------------------------+
Bytes: 1 3 4
這個方案在a與b之間多分配了3個填充(padding)字節，這樣當整個struct對象首地址滿足4字節的對齊要求時，b字段也一定能滿足int型的4字節對齊規定。那麼sizeof(MS1)顯然就應該是8，而b字段相對於結構體首地址的偏移就是4。非常好理解，對嗎？現在我們把MS1中的字段交換一下順序:
typedef struct ms2
{
int a;
char b;
} MS2;
或許你認爲MS2比MS1的情況要簡單，它的佈局應該就是
_______________________
| | |
| a | b |
| | |
+---------------------+
Bytes: 4 1
因爲MS2對象同樣要滿足4字節對齊規定，而此時a的地址與結構體的首地址相等，所以它一定也是4字節對齊。嗯，分析得有道理，可是卻不全面。讓我們來考慮一下定義一個MS2類型的數組會出現什麼問題。C標準保證，任何類型(包括自定義結構類型)的數組所佔空間的大小一定等於一個單獨的該類型數據的大小乘以數組元素的個數。換句話說，數組各元素之間不會有空隙。按照上面的方案，一個MS2數組array的佈局就是:
|<- array[1] ->|<- array[2] ->|<- array[3] .....
__________________________________________________________
| | | | |
| a | b | a | b |.............
| | | | |
+----------------------------------------------------------
Bytes: 4 1 4 1
當數組首地址是4字節對齊時，array[1].a也是4字節對齊，可是array[2].a呢？array[3].a ....呢？可見這種方案在定義結構體數組時無法讓數組中所有元素的字段都滿足對齊規定，必須修改成如下形式:
___________________________________
| | |///////////|
| a | b |//padding//|
| | |///////////|
+---------------------------------+
Bytes: 4 1 3
現在無論是定義一個單獨的MS2變量還是MS2數組，均能保證所有元素的所有字段都滿足對齊規定。那麼sizeof(MS2)仍然是8，而a的偏移爲0，b的偏移是4。
好的，現在你已經掌握了結構體內存佈局的基本準則，嘗試分析一個稍微複雜點的類型吧。
typedef struct ms3
{
char a;
short b;
double c;
} MS3;
我想你一定能得出如下正確的佈局圖:
padding
|
_____v_________________________________
| |/| |/////////| |
| a |/| b |/padding/| c |
| |/| |/////////| |
+-------------------------------------+
Bytes: 1 1 2 4 8
sizeof(short)等於2，b字段應從偶數地址開始，所以a的後面填充一個字節，而sizeof(double)等於8，c字段要從8倍數地址開始，前面的a、b字段加上填充字節已經有4 bytes，所以b後面再填充4個字節就可以保證c字段的對齊要求了。sizeof(MS3)等於16，b的偏移是2，c的偏移是8。接着看看結構體中字段還是結構類型的情況:
typedef struct ms4
{
char a;
MS3 b;
} MS4;
MS3中內存要求最嚴格的字段是c，那麼MS3類型數據的對齊模數就與double的一致(爲8)，a字段後面應填充7個字節，因此MS4的佈局應該是:
_______________________________________
| |///////////| |
| a |//padding//| b |
| |///////////| |
+-------------------------------------+
Bytes: 1 7 16
顯然，sizeof(MS4)等於24，b的偏移等於8。
在實際開發中，我們可以通過指定/Zp編譯選項來更改編譯器的對齊規則。比如指定/Zpn(VC7.1中n可以是1、2、4、8、16)就是告訴編譯器最大對齊模數是n。在這種情況下，所有小於等於n字節的基本數據類型的對齊規則與默認的一樣，但是大於n個字節的數據類型的對齊模數被限制爲n。事實上，VC7.1的默認對齊選項就相當於/Zp8。仔細看看MSDN對這個選項的描述，會發現它鄭重告誡了程序員不要在MIPS和Alpha平臺上用/Zp1和/Zp2選項，也不要在16位平臺上指定/Zp4和/Zp8(想想爲什麼？)。改變編譯器的對齊選項，對照程序運行結果重新分析上面4種結構體的內存佈局將是一個很好的複習。
到了這裏，我們可以回答本文提出的最後一個問題了。結構體的內存佈局依賴於CPU、操作系統、編譯器及編譯時的對齊選項，而你的程序可能需要運行在多種平臺上，你的源代碼可能要被不同的人用不同的編譯器編譯(試想你爲別人提供一個開放源碼的庫)，那麼除非絕對必需，否則你的程序永遠也不要依賴這些詭異的內存佈局。順便說一下，如果一個程序中的兩個模塊是用不同的對齊選項分別編譯的，那麼它很可能會產生一些非常微妙的錯誤。如果你的程序確實有很難理解的行爲，不防仔細檢查一下各個模塊的編譯選項。
看了以後，感覺挺好。同時，也分享一下……