关于结构体的字节对齐是什么，就不赘述，再此附上一篇文章，介绍字节对齐：http://www.linuxsong.org/2010/09/c-byte-alignment/

这里的结构体字节对齐的数据类型都是基本数据类型，如果结构体的定义中含有结构体成员呢？

网上有很多人写博客谈到这个问题，都认为该结构体成员应该被看做一个整体，按照整体的字节数来进行字节对齐，选择首地址。但是经过测试，这种说法是不对的。

 struct s1{

    char c1;

    char c2;

    char c3;

    char c4;

 };

 struct s2{

     char a;

     struct s1 s;

 };

对于上述代码，显然sizeof(struct s1) = 4。如果将struct s1看做整体，来进行字节对齐的话，sizeof(struct s2)应该是等于8。但是该段代码在gcc和VS2010下测试的结果都是5。

所以,s2的内存布局如下

s2 : char | char char char char |

s的首地址并非为4，而是char类型长度的整数倍

同样，对于结构体：

 struct S1

 {

     char a;

     short b;

 };

 struct S2

 {

     char a;

     struct S1 s;

 };

上述代码中，sizeof(struct S1) = 4，而sizeof(struct S2) = 6。

S2的内存布局是：

S2 : char **** | char **** short short

s的首地址并非为4，而是short类型长度的整数倍，结构体S2的长度并非结构体S1长度的整数倍，而是short类型长度的整数倍

相对的，我们可以看一下结构体：

struct S

{

    char a;

    char b;

    short c;

};

sizeof(S) = 4。

其内存布局为：

S : char char short short

对比S2和S，我们看到，S2中的s结构体成员确实是仍按它作为S1结构体的整体（占用4个字节）来布局的。

那么我们可以得出这情形下的字节对齐问题的结论：

1）结构体中的结构体成员，是按照原结构体的内存布局在新结构体中进行布局的；

2）结构体中的结构体成员，其内存首地址为该成员中最长数据类型的整数倍；

3）结构体的整体长度与其中的结构体成员无关，而是整个结构体（包括结构体成员内部）中的最长数据类型的整数倍。

得出结论后，我们回到处理器本身，来探讨一下编译器之所以这么处理的原因。

从CPU结构角度看内存对齐有一篇比较易懂的文章：

http://hi.baidu.com/maikeai/item/4976f24cc0f905d3c1a592a0

从该文章中，我们可以知道，之所以需要内存对齐，是CPU为了读取数据时减少读取存储器的次数，提高效率。

对于32位的CPU，一次最多读入双字的32位数据，而对于超过32位的数据，在32位的计算机上，就必须多次读取存储器，这与是否字节对齐无关。

我们可以看到，字节对齐，其实实质上是在拿存储器的空间，换CPU的时间。

所以，对于C语言内置的数据类型，可以很好地通过内存对齐来节省时间，同时其浪费的存储器空间也是可控的。

但是，对于结构体成员来说，因为它的长度是不可控的，所以如果强行按整体内存对齐，首先可能因为长度过长，即使内存对齐需要的存储器读取次数也很多，导致优化的时间不明显，另外，也可能导致浪费的存储器空间太大。所以，最简单的平衡空间和时间的方法，就是按照该结构体成员中最长数据类型来进行字节对齐，这样最有可能减少存储器读取次数，也使浪费的存储器空间可控。

完