sizeof与结构体

不是这里错了，是内存对齐的问题。

看看这篇文章：

有的时候，在脑海中停顿了很久的“显而易见”的东西，其实根本上就是错误的。就拿下面的问题来看：

struct T
{
char ch;
int i ;
};
使用sizeof(T)，将得到什么样的答案呢？要是以前，想都不用想，在32位机中，int是4个字节，char是1个字节，所以T一共是5个字节。实践出真知，在VC6中测试了下，答案确实8个字节。哎，反正受伤的总是我，我已经有点麻木了，还是老老实实的接受吧！为什么答案和自己想象的有出入呢？这里将引入内存对齐这个概念。

许多实际的计算机系统对基本类型数据在内存中存放的位置有限制，它们会要求这些数据的首地址的值是某个数k(通常它为4或8)的倍数，这就是所谓的内存对齐，而这个k则被称为该数据类型的对齐模数(alignment modulus)。当一种类型S的对齐模数与另一种类型T的对齐模数的比值是大于1的整数，我们就称类型S的对齐要求比T强(严格)，而称T比S弱(宽松)。这种强制的要求一来简化了处理器与内存之间传输系统的设计，二来可以提升读取数据的速度。比如这么一种处理器，它每次读写内存的时候都从某个8倍数的地址开始，一次读出或写入8个字节的数据，假如软件能保证double类型的数据都从8倍数地址开始，那么读或写一个double类型数据就只需要一次内存操作。否则，我们就可能需要两次内存操作才能完成这个动作，因为数据或许恰好横跨在两个符合对齐要求的8字节内存块上。某些处理器在数据不满足对齐要求的情况下可能会出错，但是Intel的IA32架构的处理器则不管数据是否对齐都能正确工作。不过Intel奉劝大家，如果想提升性能，那么所有的程序数据都应该尽可能地对齐。

ANSI C标准中并没有规定，相邻声明的变量在内存中一定要相邻。为了程序的高效性，内存对齐问题由编译器自行灵活处理，这样导致相邻的变量之间可能会有一些填充字节。对于基本数据类型(int char)，他们占用的内存空间在一个确定硬件系统下有个确定的值，所以，接下来我们只是考虑结构体成员内存分配情况。

Win32平台下的微软C