为什么sizeof运算符返回的结构大小大于结构成员的总大小?
当前回答
这可能是由于字节对齐和填充,使得结构在您的平台上达到偶数字节(或单词)。例如,在Linux上的C中,以下3种结构:
#include "stdio.h"
struct oneInt {
int x;
};
struct twoInts {
int x;
int y;
};
struct someBits {
int x:2;
int y:6;
};
int main (int argc, char** argv) {
printf("oneInt=%zu\n",sizeof(struct oneInt));
printf("twoInts=%zu\n",sizeof(struct twoInts));
printf("someBits=%zu\n",sizeof(struct someBits));
return 0;
}
成员的大小(以字节为单位)分别为4字节(32位)、8字节(2x 32位)和1字节(2+6位)。上面的程序(在使用gcc的Linux上)将大小打印为4、8和4,其中最后一个结构填充为一个单词(在我的32位平台上为4 x 8位字节)。
oneInt=4
twoInts=8
someBits=4
其他回答
这可能是由于字节对齐和填充,使得结构在您的平台上达到偶数字节(或单词)。例如,在Linux上的C中,以下3种结构:
#include "stdio.h"
struct oneInt {
int x;
};
struct twoInts {
int x;
int y;
};
struct someBits {
int x:2;
int y:6;
};
int main (int argc, char** argv) {
printf("oneInt=%zu\n",sizeof(struct oneInt));
printf("twoInts=%zu\n",sizeof(struct twoInts));
printf("someBits=%zu\n",sizeof(struct someBits));
return 0;
}
成员的大小(以字节为单位)分别为4字节(32位)、8字节(2x 32位)和1字节(2+6位)。上面的程序(在使用gcc的Linux上)将大小打印为4、8和4,其中最后一个结构填充为一个单词(在我的32位平台上为4 x 8位字节)。
oneInt=4
twoInts=8
someBits=4
除了其他答案,结构可以(但通常不)具有虚拟函数,在这种情况下,结构的大小还将包括vtbl的空间。
在关于内存对齐和结构填充/打包的其他解释得很好的答案中,我通过仔细阅读问题本身发现了一些东西。
“为什么结构的sizeof不等于每个成员的sizeof之和?”“为什么sizeof运算符返回的结构大小大于结构成员的总大小”?
这两个问题都表明了一些明显的错误。至少在一般的、非示例性的视图中是这样的。
应用于结构对象的sizeof操作数的结果可以等于分别应用于每个成员的sizeof之和。它不一定要更大/不同。
如果没有填充的原因,则不会填充内存。
如果结构仅包含相同类型的成员,则大多数实现为:
struct foo {
int a;
int b;
int c;
} bar;
假设sizeof(int)==4,结构杆的尺寸将等于所有构件的尺寸总和,sizeof(bar)==12。这里没有填充。
同样的例子如下:
struct foo {
short int a;
short int b;
int c;
} bar;
假设sizeof(short int)==2,sizeof(int)==4。为a和b分配的字节之和等于为c分配的字节,c是最大的成员,因此所有内容都完全对齐。因此,sizeof(bar)==8。
这也是关于结构填充的第二个最受欢迎的问题的对象,这里:
C结构中的内存对齐
其思想是,出于速度和缓存的考虑,操作数应从与其自然大小对齐的地址中读取。为了实现这一点,编译器填充结构成员,以便对齐以下成员或以下结构。
struct pixel {
unsigned char red; // 0
unsigned char green; // 1
unsigned int alpha; // 4 (gotta skip to an aligned offset)
unsigned char blue; // 8 (then skip 9 10 11)
};
// next offset: 12
x86体系结构始终能够获取未对齐的地址。然而,它速度较慢,当未对齐与两个不同的缓存线重叠时,当对齐的访问只会逐出一个缓存线时,它会逐出两个缓存线。
有些架构实际上必须捕获未对齐的读写,而早期版本的ARM架构(演变成当今所有移动CPU的架构)。。。事实上,他们只是返回了这些错误的数据。(他们忽略了低位。)
最后,请注意缓存线可以任意大,编译器不会试图猜测这些缓存线,也不会做出空间与速度的权衡。相反,对齐决策是ABI的一部分,表示最终将均匀填充缓存行的最小对齐。
TL;DR:对齐很重要。
结构的尺寸大于其部件的总和,这是因为所谓的填充。一个特定的处理器有一个首选的数据大小。大多数现代处理器的首选大小为32位(4字节)。当数据位于这种边界上时,访问内存比跨越这种大小边界的东西更有效。
例如考虑简单的结构:
struct myStruct
{
int a;
char b;
int c;
} data;
如果机器是32位机器,并且数据在32位边界上对齐,我们会看到一个直接的问题(假设没有结构对齐)。在此示例中,让我们假设结构数据从地址1024开始(0x400-请注意,最低2位为零,因此数据与32位边界对齐)。对data.a的访问将正常工作,因为它从边界0x400开始。对data.b的访问也会很好,因为它位于地址0x404——另一个32位边界。但未对齐的结构将把data.c放在地址0x405。数据.c的4个字节位于0x405、0x406、0x407、0x408。在32位机器上,系统将在一个内存周期内读取data.c,但只能获得4个字节中的3个字节(第4个字节位于下一个边界)。因此,系统必须进行第二次内存访问以获得第四个字节,
现在,如果编译器不将data.c放在地址0x405,而是将结构填充3字节,并将data.c放到地址0x408,那么系统只需要1个周期就可以读取数据,从而将对该数据元素的访问时间减少50%。填充以内存效率换取处理效率。考虑到计算机可以拥有大量的内存(许多千兆字节),编译器认为这种交换(速度与大小)是合理的。
不幸的是,当您试图通过网络发送结构,甚至将二进制数据写入二进制文件时,这个问题就成了一个杀手。在结构或类的元素之间插入的填充会破坏发送到文件或网络的数据。为了编写可移植的代码(一个将被几个不同的编译器使用),您可能必须分别访问结构的每个元素,以确保正确的“打包”。
另一方面,不同的编译器有不同的能力来管理数据结构打包。例如,在Visual C/C++中,编译器支持#pragma pack命令。这将允许您调整数据打包和对齐。
例如:
#pragma pack 1
struct MyStruct
{
int a;
char b;
int c;
short d;
} myData;
I = sizeof(myData);
我现在的长度应该是11。如果没有pragma,我可以从11到14(对于某些系统,可以多达32),这取决于编译器的默认打包。