结构的尺寸大于其部件的总和，这是因为所谓的填充。一个特定的处理器有一个首选的数据大小。大多数现代处理器的首选大小为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），这取决于编译器的默认打包。

这是因为添加了填充以满足对齐约束。数据结构对齐会影响程序的性能和正确性：

未对齐的访问可能是一个硬错误（通常是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语句来更改结构对齐设置。

结构的尺寸大于其部件的总和，这是因为所谓的填充。一个特定的处理器有一个首选的数据大小。大多数现代处理器的首选大小为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），这取决于编译器的默认打包。

如果隐式或显式设置了结构的对齐方式，则可以这样做。对齐为4的结构将始终是4字节的倍数，即使其成员的大小不是4字节的倍。

此外，一个库可以在x86下用32位int编译，并且您可以在64位进程上比较它的组件。如果您手动执行此操作，则会得到不同的结果。

除了其他答案，结构可以（但通常不）具有虚拟函数，在这种情况下，结构的大小还将包括vtbl的空间。

这可能是由于字节对齐和填充，使得结构在您的平台上达到偶数字节（或单词）。例如，在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