为什么C中struct的大小不等于所有变量大小的总和;

Question

  

可能重复：
  Why isn't sizeof for a struct equal to the sum of sizeof of each member?

这是我的结构，它的大小是40，但所有变量的大小是34。 如何消除此结构的额外空间？

typedef struct
{
USHORT SequenceNumber;
USHORT LinkCount; 
USHORT AttributeOffset;
USHORT Flags;
ULONG BytesInUse;
ULONG BytesAllocated;
ULONGLONG BaseFileRecord;
USHORT NextAttributeNumber;
USHORT Padding;
ULONG MFTRecordNumber;
USHORT UpdateSeqNum;
} FILE_RECORD_HEADER, *PFILE_RECORD_HEADER;

Answer 1

这是因为编译器可以自由插入填充以满足对齐要求。你有几个选择。

第一个本质上是不可移植的，但许多实现提供了类似的东西：

#pragma pack

将尝试尽可能紧密地打包结构。请注意，这可能会降低代码速度，具体取决于架构

另一种方法是将所有最对齐的元素放在前面，例如：

typedef struct {
    ULONGLONG BaseFileRecord;              // 0x00
    ULONG BytesInUse;                      // 0x08
    ULONG BytesAllocated;                  // 0x0c
    ULONG MFTRecordNumber;                 // 0x10
    USHORT NextAttributeNumber;            // 0x14
    USHORT SequenceNumber;                 // 0x16
    USHORT LinkCount;                      // 0x18
    USHORT AttributeOffset;                // 0x1a
    USHORT Flags;                          // 0x1c
    USHORT Padding;                        // 0x1e
    USHORT UpdateSeqNum;                   // 0x20
} FILE_RECORD_HEADER, *PFILE_RECORD_HEADER;

评论中可能存在偏移，假设ULONGLONG为8个字节，ULONG为4，USHORT为2.这不一定会删除所有填充，但会使其更容易让编译器最小化它。

Answer 2

由于填充。结构的大小取决于平台和编译器。你为什么在乎？您是否将结构视为二进制数据？

Answer 3

对齐+填充。

有两种方法可以解决这个问题：

1. 通过以最大到最小的顺序排列变量来减少填充。
2. 在编译器中使用非标准的packed属性扩展名（__attribute__((packed))用于GCC）。请注意，读取struct成员的访问时间将会减少，代码大小将会增加（尽管不会像在无法访问未对齐的单词的平台上那样糟糕，例如ARM）。

Answer 4

是的，你应该看看：

Why isn't sizeof for a struct equal to the sum of sizeof of each member?

简而言之，它与编译器在结构中插入额外的空间以使结构的成员更好地对齐。