sizeof與struct——求結構體大小的計算方法

sizeof淺析（一）——求結構體大小 這篇文章講了sizeof求結構體大小的計算方法，並給出可以套用的準則：

一、儲存變數時地址要求對齊，編譯器在編譯程式時會遵循兩條原則：

（1）結構體變數中成員的偏移量必須是成員大小的整數倍（0被認為是任何數的整數倍）
（2）結構體大小必須是所有成員大小的整數倍，也即所有成員大小的公倍數。

二、 對於巢狀的結構體，需要將其展開。對結構體求sizeof時，上述兩種原則變為：

（1）展開後的結構體的第一個成員的偏移量應當是被展開的結構體中最大的成員的整數倍。
（2）結構體大小必須是所有成員大小的整數倍，這裡所有成員計算的是展開後的成員，而不是將巢狀的結構體當做一個整體。

為什麼？

但是編譯器為什麼要這麼做，以下是我的理解。

為什麼要對齊？

因為在32位作業系統（雖然64位作業系統，但是為了保證相容性，程式設計仍然主要考量32位）中，資料匯流排是32位，地址匯流排是32位。
地址匯流排是32位，意味著定址空間是按4遞增的；資料匯流排32位意味著一次可讀寫4byte。
考慮這樣一個結構體

struct stu1  
{   
   char c1;   
   int i;  
   char c2;  
}  

不對齊就意味著，當我們執行stu1.i 時，需要讀取記憶體兩次。而對齊後，就只需要讀取一次，眾所周知，I/O操作是很耗時的，編譯器做出對齊的選擇也就好理解。

為什麼不完全按照4位元組對齊的？

既然對齊可以避免上述的問題，為什麼不將所有儲存小於4byte的資料型別（char, short等）統統按4byte對齊呢？
考慮這樣一個結構體

struct stu2  
{   
   char c;   
   short s;
   int i; 
   double d; 
}

為什麼編譯器採用B方案，而不採用A方案？
還是因為32資料線一次讀取4個位元組，
採用方案A，讀取stu2.c，或者stu2.s，要一次讀取4個byte，再捨棄無關記憶體的資料。
採用方案B，讀取stu2.c，或者stu2.s，也是要一次讀取4個byte，再捨棄無關記憶體中的資料。
同樣的I/O操作，相比之下，明顯方案B更節省記憶體。

補充： 如上圖中，所示8位元組的資料型別，比如double, long long,必須要讀取兩次記憶體。

明白這兩點，再回看上面結構體大小的計算方法，就簡單多了，也不用死記爛背了。
另外，寫程式碼時也知道怎樣節省記憶體了（雖然大多數時間不用考慮這點）。