truct rf {
unsigned short rh_zero;
float rh_sps;
}ss;
int s;
s=sizeof(ss);
s等于多少.
顶客chengdz于Wed Sep 26 19:48:59 2007顶帖一次
16+32 =48
顶客yiling于Thu Sep 27 15:24:00 2007顶帖一次
这是一个关于内存对齐的问题.
理论上说是2+4=6;
受编译器设置情况.
也可能是8,或26,或....
顶客yiling于Sat Sep 29 20:37:22 2007顶帖一次
#pragma pack(16)
class dd{
int a;
virtual ~dd(){}
double c;
virtual out(){}
};
#pragma pack()
内存中形式如下:
vptr:4字节
int:4字节
double 8字节,它们之间刚好不用填充数据,在结尾也不用填,所以
是16,可以执行结果是24!
它为什么不是16而是24呢?
如果我将#pragma pack(16)
改正为#pragma pack(8),那么,它的大小会是16,但是事实上还是24,为什么呢?
#pragma pack(n)
这个n的值可以为1, 2, 4, 8, 16，pack的原则是尽量使其在内存中和机器的自然字长相同
，你的机器自然字长可能是2字也就是4字节，所以当n > 4时，字节数小于4的类型会被自
动填充为4字节，大于4字节的才根据n的指定来填充，所以你那个类的内存排列方式应该是
这样：
vptr: 4, int 4, double 16;
我考虑过是否是编译器优化的结果，但我看了下发现我的编译器优化是被关掉的，而且st
ruct和clas的对齐方式是默认default，所以得出以上结论，仅供参考!
受你问题的启发，这几研究了下计算机组成原理，其中看了一本书叫Write Great Code V
ol1——Understanding The Machine，在内存结构那章有这么一段：
Figure 7-8 also suggests that compilers pack the fields into adjacent memory l
ocations with no gaps between the fields. While this is true for many language
s, this certainly isn t the most common memory organization for a record. For
performance reasons, most compilers will actually align the fields of a record
on appropriate memory boundaries. The exact details vary by language, compile
r implementation, and CPU, but a typical compiler will place fields at an offs
et within the record s storage area that is natural for that particular fiel
d s data type. On the 80x86, for example, compilers that follow the Intel ABI
(application binary interface) will allocate one-byte objects at any offset wi
thin the record, words only at even offsets, and double-word or larger objects
on double-word boundaries. Although not all 80x86 compilers support the Intel
ABI, most do, which allows records to be shared among functions and procedure
s written in different languages on the 80x86. Other CPU manufacturers provide their own ABI for their processors and programs that adhere to
an ABI can share binary data at run time with other programs that adhere to t
he same ABI.
说的是关于结构体中数据的对齐方式因语言、编译器和CPU而异，但是通常的做法就是把数
据成员放置在与该成员的类型较为符合（也称自然放置）的地方。
因为Intel的 Pentium 系列处理器属于x86家族，x86家族中：
8088, 8086, 80186, 80188 只有20条数据总线，寻址能力为1M
80286, 80386sx 有24条数据总线 可寻址16M
80386dx 有32条数据总线 可寻址4GB
80486, Pentium 也是32条 寻址4GB
Pentium Pro, II, III, IV 有36条数据总线 可寻址64GB
P4应该属于Prntium Pro，有36条数据总线，我的也是P42.4G，但x86家族的通用整型寄存
器是32位的，也就是在每个CPU时钟周期中最多这能处理32位数据。
一般所说的32，64位CPU都指的是其数据总线数量，而不是CPU寄存器所以P4是属于32位的
处理器(以后买CPU要看寄存器大小不要被表面的32, 64云云，给蒙啦...)
所以Pentium Pro多出来的那4条总线P用没有！
因为有32条能用到的数据总线，所以每个cpu指令可操作的对象最大可能就为32bit，即8个
位，x86家族采用2个memory bank表示一个字，所以32位数据总线可由4个bank来表示，所
以其内部内存模型为：
QW: quad-word
.^
.|
.|
QWX2: XX XX XX XX // 从左往右依次是bank 1, 2, 3, 4
QWX1: XX XX XX XX // 8位 X表数据未知
QWX0: XX XX XX XX // 8位 bank中的每个X表示一个位
.|
.|地址由下往上增
.
// 右边的数字每一个表示一个位
而x86CPU对打包数据体(结构，联合，这里联合被排除)中的数据类型的排列方式是遵循以
下原则的：
1、Compiler will allocate one-byte objects at any offset within the record.
编译器将在结构基地址的任意偏移量处分配1字节（这就是为什么创建一个空类也占1字节
的原因）。
2、Words only at even offsets。
字只处在偏移量为偶数的地方。
3、Double-word or larger objects on double-word boundaries.
双字或更大的数据体只处在双字的边缘上。
以上是我看到的一点心得，应该是Intel处理器和大部分编译器的默认处理方式，给你分享
下。
另外我又试验了以后发现竟然是VC的问题，我在除VC外的其他几个编译器上试验的结果都
是16位，对齐原则和我跟你说的一样，VC为什么是24呢？因为它编译器里的默认对齐方式
是8字节，请看以下结果：
#include <iostream>
using namespace std;
//#pragma pack()
class dd{
public:
int a;
double c;
virtual ~dd(){}
}a, b;
int main()
{
cout << &a << endl;
cout << &a.a << endl;
cout << &a.c << endl;
cout << &b;
}
运行结果是
0041E008 // vptr
0041E010 // int
0041E018 // double
0041E020
内存模型可能就是这样：
X: 填充字节
.^
.|
.|
QWX2: HH HH HH HH // double
QWX1: XX XX BB BB // int
QWX0: XX XX AA AA // vptr
.|
.|地址由下往上增
.|
所以是3*8 = 24字节
可见编译器把vptr也分配为了8字节，可能有4字节的填充，原因我想很简单，就是VC迎合
32位寄存器的CPU的结果，因为这样就可以每次读取的最大32位数据都可以在一个32位的通
用整型寄存器中来执行操作，只需要一个指令就可以把数据分离出来，而如果是以4字节对
齐的话，就需要2个指令，先把寄存器中的高16位（由于intel是反着存的）读入16位通用
整型寄存器（AX，BX，CX，DX），再把数据提取出来。
这样的结果是增加了程序执行的内存开销，但提高了执行速度，典型的牺牲空间换取时间
的做法（貌似现在都以时间为优先考虑，计算机的RAM是越来越大，就连cache都有好几级
大到数M了-_-~）。
但在其他的编译器上产生的结果就是16，总之#pragma 宏的实现本来就是最不可靠的，因
为很大程度上它的实现是取决与编译器和CPU，所以遇到这样的问题还是要结合多方面考虑
，另外多吸收一些计算机结构的底层知识也能帮助自己的理解（说“帮助”有点牵强，因
为了解了底层实现那还有什么高级“花招”能忽悠得了我的^_^）。
PS: 多谢你的这个问题啊呵呵，我这段时间读了3本计算机结构的书，对底层有了一定了解
，今后打算把Intel的3本Developer manual也搞定，哈哈过瘾！！
在最近的项目中，我们涉及到了“内存对齐”技术。对于大部分程序员来说，“内存对齐
”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的“管辖范围”。编译器
为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活，太
强大，它允许你干预“内存对齐”。如果你想了解更加底层的秘密，“内存对齐”对你就
不应该再透明了。
一、内存对齐的原因
大部分的参考资料都是如是说的：
1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬
件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。
2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问
未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。
二、对齐规则
每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过
预编译命令#pragma pack(n)，n=1,2,4,8,16来改变这一系数，其中的n就是你要指定的“
对齐系数”。
规则：
1、数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在
offset为0的地方，以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员
自身长度中，比较小的那个进行。
2、结构(或联合)的整体对齐规则：在数据成员完成各自对齐之后，结构(或联合)本身也要
进行对齐，对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中，比
较小的那个进行。
3、结合1、2颗推断：当#pragma pack的n值等于或超过所有数据成员长度的时候，这个n值
的大小将不产生任何效果。
三、试验
我们通过一系列例子的详细说明来证明这个规则吧!
我试验用的编译器包括GCC 3.4.2和VC6.0的C编译器，平台为Windows XP + Sp2。
我们将用典型的struct对齐来说明。首先我们定义一个struct：
#pragma pack(n) /* n = 1, 2, 4, 8, 16 */
struct test_t {
int a;
char b;
short c;
char d;
};
#pragma pack(n)
首先我们首先确认在试验平台上的各个类型的size，经验证两个编译器的输出均为：
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
我们的试验过程如下：通过#pragma pack(n)改变“对齐系数”，然后察看sizeof(struct
test_t)的值。
1、1字节对齐(#pragma pack(1))
输出结果：sizeof(struct test_t) = 8 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(1)
struct test_t {
int a; /* 长度4 < 1 按1对齐；起始offset=0 0%1=0；存放位置区间[0,3] */
char b; /* 长度1 = 1 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
short c; /* 长度2 > 1 按1对齐；起始offset=5 5%1=0；存放位置区间[5,6] */
char d; /* 长度1 = 1 按1对齐；起始offset=7 7%1=0；存放位置区间[7] */
};
#pragma pack()
成员总大小=8
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 1) = 1
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 8 /* 8%1=0 */ [注1]
2、2字节对齐(#pragma pack(2))
输出结果：sizeof(struct test_t) = 10 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(2)
struct test_t {
int a; /* 长度4 > 2 按2对齐；起始offset=0 0%2=0；存放位置区间[0,3] */
char b; /* 长度1 < 2 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
short c; /* 长度2 = 2 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
char d; /* 长度1 < 2 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 2) = 2
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 10 /* 10%2=0 */
3、4字节对齐(#pragma pack(4))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(4)
struct test_t {
int a; /* 长度4 = 4 按4对齐；起始offset=0 0%4=0；存放位置区间[0,3] */
char b; /* 长度1 < 4 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
short c; /* 长度2 < 4 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
char d; /* 长度1 < 4 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 4) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */
4、8字节对齐(#pragma pack(8))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(8)
struct test_t {
int a; /* 长度4 < 8 按4对齐；起始offset=0 0%4=0；存放位置区间[0,3] */
char b; /* 长度1 < 8 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
short c; /* 长度2 < 8 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
char d; /* 长度1 < 8 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 8) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */
5、16字节对齐(#pragma pack(16))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(16)
struct test_t {
int a; /* 长度4 < 16 按4对齐；起始offset=0 0%4=0；存放位置区间[0,3] */
char b; /* 长度1 < 16 按1对齐；起始offset=4 4%1=0；存放位置区间[4] */
short c; /* 长度2 < 16 按2对齐；起始offset=6 6%2=0；存放位置区间[6,7] */
char d; /* 长度1 < 16 按1对齐；起始offset=8 8%1=0；存放位置区间[8] */
};
#pragma pack()
成员总大小=9
2) 整体对齐
整体对齐系数 = min((max(int,short,char), 16) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */
四、结论
8字节和16字节对齐试验证明了“规则”的第3点：“当#pragma pack的n值等于或超过所有
数据成员长度的时候，这个n值的大小将不产生任何效果”。另外内存对齐是个很复杂的东
西，上面所说的在有些时候也可能不正确。呵呵^_^
[注1]
什么是“圆整”？
举例说明：如上面的8字节对齐中的“整体对齐”，整体大小=9 按 4 圆整 = 12
圆整的过程：从9开始每次加一，看是否能被4整除，这里9，10，11均不能被4整除，到12
时可以，则圆整结束。
|
稀饭顶客综合社区
