c语言 结构体的大小,为什么C语言中的结构体的size，并不等于它所有成员size之和？...

结构体在C语言程序开发中，是不可或缺的语法。不过，相信不少C语言初学者遇到过这样的问题：为什么结构体的 size 有时不等于它的所有成员的 size 之和呢？

为什么结构体的 size 有时不等于它的所

C语言结构体大小等于它的所有成员大小之和吗？

举例来说，假设有结构体，它的C语言代码如下，请看：

struct x{short s;int i;char c;};

我们继续编写C语言代码，依次输出成员 s，i，c 占用内存空间的大小，相关代码很简单，请看：

struct x t;printf("%lu %lu %lu\n", sizeof(t.s), sizeof(t.i), sizeof(c));

实际结果与我们的预期并不一致

编译并执行这段C语言代码，得到如下输出：

# gcc t.c# ./a.out 2 4 1

那么按理说，结构体 x 占用的内存空间应该等于 2+4+1=7 字节，但是似乎实际结果与我们的预期并不一致：

printf("%lu\n", sizeof(t));

上面这行C语言代码输出的结果是 12！这是怎么回事呢？

解析

程序输出的结果与我们的预期不一致，原因在于“对齐机制”。如果将结构体 x 看作是一个容器，鉴于成员 s，i，c 的长度参差不齐，C语言编译器不得不“填充”一些额外的空间，以满足“对齐机制”。

数据结构是否对齐不仅影响C语言程序的性能，有时甚至还会带来意想不到的错误，例如访问未对齐的数据，可能会导致硬件方面的问题 (SIGBUS，总线错误)，导致性能下架，以及破坏一些操作的原子性等并发安全保障。

所以，C语言编译器在处理结构体时，如果没有特别的指定，一般都会填充一些字节，以确保不违背对齐机制。以上面的结构体 x 为例，初学者可能会认为它的成员在内存中的布局如下：

初学者可能会认为它的成员在内存中的布

但是，如果编译器按照下面布局，处理器访问之将更加方便：

处理器访问之将更加方便

不过，这样排列结构体 x 的成员，会空出一些空间，对于处理器来说，小心的跳过这些空间还是有些麻烦，于是大多数C语言编译器都会像下面这样填充空穴：

大多数C语言编译器都会这样填充空穴

这样一来，整个结构体 x 占用内存的空间，其实就是成员 i 占用空间的 3 倍了，也即 12 字节。

事实上，我们可以通过排列结构体 x 成员的顺序，来优化其占用内存的大小，例如：

通过排列结构体 x 成员的顺序，来优化

小结

本节主要讨论了C语言中结构体大小并不一定等于它所有成员大小之和的原因，应该注意，结构对齐在C语言标准中是 implementation defined，不同的C语言编译器可能选择不同的数据对齐方式，从而导致不同和不兼容的数据布局。因此，在使用不同编译器开发C语言程序时，了解编译器是如何对齐数据是很重要的。

一些编译器可以指定结构对齐的方式，例如 #pragma 语句。

点个赞再走吧

欢迎在评论区一起讨论，质疑。文章都是手打原创，每天最浅显的介绍C语言、linux等嵌入式开发，喜欢我的文章就关注一波吧，可以看到最新更新和之前的文章哦(最近发现有些帐号搬运我的文章并且标上原创标签，有些可耻，请注明出处!!)。

举报/反馈