为什么结构的大小应该反映它的对齐方式？

Question

根据Wikipedia：

最后一个成员被填充所需的字节数，因此结构的总大小应该是任何结构成员的最大对齐方式的倍数

在我的理解中，它的意思如下：

struct A {
  char *p;     // 8 bytes
  char c;      // 1 byte
};
struct B {
  struct A a;  // 16 bytes
  char d;      // 1 bytes
};

struct A 的大小为 16 字节，struct B 的大小为 24 字节。

常见的解释是A 的数组应该在数组的地址加上索引乘以A 的大小来访问其元素。

但我不明白为什么会这样。为什么我们不能说 A 的大小为 9 和 B 的大小为 10（均 8 字节对齐），并在索引数组时使用特殊的“数组存储”大小？

当然，我们仍然会以与它们的对齐方式兼容的方式将这些类型存储在数组中（使用 16 个字节来存储每个 B 元素）。然后，我们只需考虑它们的对齐方式来计算元素地址，而不是单独考虑它们的大小（编译器可以静态地做到这一点）。

例如，我们可以在 B 的 1Kb 字节数组中存储 64 个对象，而不仅仅是 42 个。

Answer 1

在 C 的每个翻译单元中，sizeof(T) 是相同的，与 T 的上下文无关。您的提议将为sizeof(T) 引入至少两个值：一个用于T 的数组，另一个用于T 的单个对象。这基本上将上下文相关性引入了sizeof 运算符。它与 C 处理指针、数组和对象地址的方式不兼容。

考虑以下几点：

void zero_A(struct A *a) { memset(a,0,sizeof(*a)); }

/* ... */
struct A single;
struct A several[3];
struct B b;

b.d = 3;
zero_A(&b.a);
zero_A(&single);
zero_A(several+1);

根据您的建议，zero_A 必须知道它传递的指针是指向数组上下文中的struct A（其中sizeof(*a) == 16）还是指向数组上下文之外的struct A（其中sizeof(*a) == 9） .标准 C 不支持这一点。如果编译器猜错了，或者信息丢失了（例如：在通过volatile struct A * 的往返行程中），那么zero_A(&single) 将调用未定义的行为（通过写入超过single 的边界），并且zero_A(&b.a)将覆盖 b.d 并调用未定义的行为。

将结构紧密打包到数组中是一个相对不常见的要求，并且将上下文依赖添加到 sizeof 会给语言、它的库和 ABI 带来很多复杂性。有时您需要这样做，而 C 为您提供了所需的工具：memcpy 和联合。