为什么sizeof 运算符返回的结构大小大于结构成员的总大小？
【问题讨论】：
标签： c++ c struct sizeof c++-faq
这是因为添加了填充以满足对齐约束。 Data structure alignment 影响程序的性能和正确性：
SIGBUS）。这是一个使用 x86 处理器的典型设置的示例（全部使用 32 位和 64 位模式）：
struct X
{
short s; /* 2 bytes */
/* 2 padding bytes */
int i; /* 4 bytes */
char c; /* 1 byte */
/* 3 padding bytes */
};
struct Y
{
int i; /* 4 bytes */
char c; /* 1 byte */
/* 1 padding byte */
short s; /* 2 bytes */
};
struct Z
{
int i; /* 4 bytes */
short s; /* 2 bytes */
char c; /* 1 byte */
/* 1 padding byte */
};
const int sizeX = sizeof(struct X); /* = 12 */
const int sizeY = sizeof(struct Y); /* = 8 */
const int sizeZ = sizeof(struct Z); /* = 8 */
可以通过按对齐方式对成员进行排序来最小化结构的大小（在基本类型中按大小排序就足够了）（如上例中的结构Z）。
重要提示：C 和 C++ 标准都声明结构对齐是实现定义的。因此，每个编译器可能会选择不同的数据对齐方式，从而导致不同且不兼容的数据布局。因此，在处理将由不同编译器使用的库时，了解编译器如何对齐数据非常重要。一些编译器具有命令行设置和/或特殊的#pragma 语句来更改结构对齐设置。
【讨论】：
X 中，short 之后有 2 个字节的填充，以确保 4 字节 int 从 4 字节边界开始。在Y 中，char 之后有 1 个字节填充，以确保 2 字节 short 以 2 字节边界开始。由于编译器无法知道内存中的结构之后可能是什么（并且可能是许多不同的东西），它会为最坏的情况做准备并插入足够的填充以使结构成为 4 字节的倍数。 X 需要 3 个字节才能达到 12，Y 只需 1 即可达到 8。
打包和字节对齐，如 C 常见问题解答here 中所述：
是为了对齐。许多处理器无法访问 2 和 4 字节 数量（例如整数和长整数），如果它们被塞进 各种方式。
假设你有这个结构：
struct { char a[3]; short int b; long int c; char d[3]; };现在，你可能认为应该可以打包这个 结构到内存中是这样的：
+-------+-------+-------+-------+ | a | b | +-------+-------+-------+-------+ | b | c | +-------+-------+-------+-------+ | c | d | +-------+-------+-------+-------+但是，如果编译器安排在处理器上要容易得多 它是这样的：
+-------+-------+-------+ | a | +-------+-------+-------+ | b | +-------+-------+-------+-------+ | c | +-------+-------+-------+-------+ | d | +-------+-------+-------+在打包版本中，请注意它至少有点难 你和我看看 b 和 c 字段是如何环绕的？简而言之， 处理器也很难。因此，大多数编译器会填充 结构（好像带有额外的不可见字段）如下：
+-------+-------+-------+-------+ | a | pad1 | +-------+-------+-------+-------+ | b | pad2 | +-------+-------+-------+-------+ | c | +-------+-------+-------+-------+ | d | pad3 | +-------+-------+-------+-------+
【讨论】：
s 的这种类型的结构变量，那么&s.a == &s 和&s.d == &s + 12（给定答案中显示的对齐方式）。仅当数组具有可变大小时才存储指针（例如，a 被声明为 char a[] 而不是 char a[3]），但是元素必须存储在其他地方。
如果您希望结构在 GCC 中具有一定的大小，例如使用 __attribute__((packed))。
在 Windows 上，当使用带有 /Zp option 的 cl.exe 编译器时，您可以将对齐设置为一个字节。
通常 CPU 更容易访问 4（或 8）的倍数的数据，这取决于平台和编译器。
所以基本上是对齐的问题。
你需要有充分的理由来改变它。
【讨论】：
#pragma pack(1) - MSVC、gcc 和 clang 都支持它，这使您的代码更具可移植性
这可能是由于字节对齐和填充导致结构在您的平台上出现偶数个字节（或字）。例如在 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
",sizeof(struct oneInt));
printf("twoInts=%zu
",sizeof(struct twoInts));
printf("someBits=%zu
",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
【讨论】：
:2 和:6 实际上指定了 2 位和 6 位，在这种情况下不是完整的 32 位整数。 someBits.x，只有 2 位，只能存储 4 个可能的值：00、01、10 和 11（1、2、3 和 4）。这有意义吗？这是一篇关于该功能的文章：geeksforgeeks.org/bit-fields-c
也可以看看：
对于 Microsoft Visual C：
http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx
和 GCC 声称与微软的编译器兼容。：
https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Structure_002dPacking-Pragmas.html
除了前面的答案，请注意无论包装，C++ 中没有成员顺序保证.编译器可以（并且肯定会）将虚拟表指针和基本结构的成员添加到结构中。甚至虚拟表的存在也没有被标准保证（没有指定虚拟机制的实现），因此可以得出结论，这种保证是不可能的。
我很确定会员订单是在 C 中保证，但是在编写跨平台或跨编译器程序时，我不会指望它。
【讨论】：
由于所谓的包装，结构的大小大于其各部分的总和。一个特定的处理器有一个可以使用的首选数据大小。大多数现代处理器的首选大小，如果是 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 处。 data.c 的 4 个字节分别位于 0x405、0x406、0x407、0x408。在 32 位机器上，系统会在一个内存周期内读取 data.c，但只会获得 4 个字节中的 3 个（第 4 个字节在下一个边界上）。因此，系统必须进行第二次内存访问才能获得第 4 个字节，
现在，如果编译器不将 data.c 放在地址 0x405 上，而是将结构填充 3 个字节并将 data.c 放在地址 0x408 上，那么系统只需 1 个周期即可读取数据，从而缩短了对该数据元素的访问时间50%。填充将内存效率换成处理效率。鉴于计算机可以拥有大量内存（数 GB），编译器认为交换（速度超过大小）是合理的。
不幸的是，当您尝试通过网络发送结构或什至将二进制数据写入二进制文件时，这个问题就会成为一个杀手。在结构或类的元素之间插入的填充可能会破坏发送到文件或网络的数据。为了编写可移植的代码（将用于几个不同的编译器），您可能必须分别访问结构的每个元素以确保正确的“打包”。
另一方面，不同的编译器具有不同的管理数据结构打包的能力。例如，在 Visual C/C++ 中，编译器支持 #pragma pack 命令。这将允许您调整数据打包和对齐。
例如：
#pragma pack 1
struct MyStruct
{
int a;
char b;
int c;
short d;
} myData;
I = sizeof(myData);
我现在应该有 11 的长度。没有编译指示，我可以是 11 到 14 之间的任何值（对于某些系统，多达 32 个），这取决于编译器的默认打包。
【讨论】：
#pragma pack。如果成员是按照默认对齐方式分配的，我通常会说结构是不是打包。
C99 N1256标准草案
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
6.5.3.4 sizeof 运算符：
3 当应用于具有结构或联合类型的操作数时， 结果是此类对象中的总字节数， 包括内部和尾随填充。
6.7.2.1 结构和联合说明符：
13 ...可能有未命名的 在结构对象内填充，但不在其开头。
和：
15 在结构或联合的末尾可能有未命名的填充。
新的 C99 flexible array member feature (
struct S {int is[];};) 也可能影响填充：16 作为一种特殊情况，具有多个命名成员的结构的最后一个元素可以 数组类型不完整；这称为灵活数组成员。在大多数情况下， 灵活的数组成员被忽略。特别是，结构的大小就像 省略了灵活的数组成员，除了它可能有更多的尾随填充 遗漏将意味着。
附件 J 可移植性问题重申：
以下是未指定的：...
- 在结构或联合中存储值时填充字节的值 (6.2.6.1)
C++11 N3337 标准草案
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
5.3.3 大小：
2 应用时 对于一个类，结果是该类的对象中的字节数，包括所需的任何填充 将该类型的对象放入数组中。
9.2 班级成员：
一个指向标准布局结构对象的指针，使用 reinterpret_cast 适当转换，指向它的 初始成员（或者如果该成员是位字段，则指向它所在的单元），反之亦然。 [ 笔记： 因此，标准布局结构对象中可能存在未命名的填充，但不是在其开头， 必要时达到适当的对齐。 ——尾注]
我只知道足够的 C++ 来理解注释:-)
【讨论】：
如果您已隐式或显式设置结构的对齐方式，则可以这样做。对齐 4 的结构将始终是 4 字节的倍数，即使其成员的大小不是 4 字节的倍数。
此外，可以在 x86 下使用 32 位整数编译一个库，如果您手动执行此操作，您可能会在 64 位进程上比较其组件会给您带来不同的结果。
【讨论】：
C 语言让编译器对内存中结构元素的位置有一些自由：
C语言为结构中元素布局的程序员提供了一些保证：
与元素对齐有关的问题：
对齐的工作原理：
p.s 更多详细信息可在此处获得：“Samuel P.Harbison, Guy L.Steele C A Reference, (5.6.2 - 5.6.7)”
【讨论】：
这个想法是出于速度和缓存考虑，操作数应该从与其自然大小对齐的地址中读取。为了实现这一点，编译器填充结构成员，以便后续成员或以下结构将对齐。
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;博士：对齐很重要。
【讨论】：
除了其他答案之外，结构可以（但通常没有）具有虚函数，在这种情况下，结构的大小还将包括 vtbl 的空间。
【讨论】：
在有关内存对齐和结构填充/打包的其他解释清楚的答案中，我通过仔细阅读在问题本身中发现了一些东西。
"为什么
sizeof的结构不等于每个成员的sizeof之和？""为什么
sizeof运算符返回的结构大小大于结构成员的总大小“？这两个问题都暗示了一些明显的错误。至少在一个通用的、非示例的焦点视图中，这里就是这种情况。
sizeof操作数应用于结构对象的结果能够等于分别应用于每个成员的sizeof的总和。它没有必须更大/不同。如果没有填充的原因，则不会填充内存。
大多数实现，如果结构只包含相同类型的成员：
struct foo { int a; int b; int c; } bar;假设
sizeof(int) == 4，结构bar的大小将等于所有成员大小的总和sizeof(bar) == 12。这里没有填充。例如这里也是如此：
struct foo { short int a; short int b; int c; } bar;假设
sizeof(short int) == 2和sizeof(int) == 4。a和b的分配字节总和等于最大成员c的分配字节，因此一切都完美对齐。因此，sizeof(bar) == 8。这也是关于结构填充的第二个最受欢迎的问题的对象，这里：
【讨论】：
上面给出了很多信息（解释）。
而且，我只想分享一些方法来解决这个问题。
您可以通过添加编译指示包来避免它
#pragma pack(push, 1)
// your structure
#pragma pack(pop)
【讨论】：