13、编译器行为分析：GCC与MSVC的对齐差异、__attribute__((packed))的使用

说到内存对齐，很多初学者觉得这是个「玄学」问题——明明结构体里就几个字段，编译器非要塞一堆填充字节进去。更让人头疼的是，换个编译器，同样的代码，结构体大小居然不一样了。

嗯，今天我们就来聊聊这个。我会结合自己在实际项目中踩过的坑，把GCC和MSVC在对齐策略上的差异讲清楚，顺便把__attribute__((packed))这个「大杀器」怎么用、什么时候用、什么时候千万别用，一并说透。

13.1 为什么编译器要对齐？

先问一个问题：为什么编译器要「自作主张」在结构体里塞填充字节？

说白了，是为了CPU访问内存的效率。大多数CPU读取内存时，是按「字」来读的——比如32位CPU一次读4字节，64位CPU一次读8字节。如果数据没有对齐到自然边界，CPU就得读两次，再把数据拼起来。一次对齐访问和两次非对齐访问，性能差距可能高达2~3倍。

所以，编译器默认会帮你做对齐优化。但问题是——不同编译器的对齐规则，并不完全一样。

13.2 GCC的对齐策略

GCC默认的对齐规则，我总结为一句口诀：每个成员的偏移量，必须是其自身大小的整数倍；整个结构体的大小，必须是最大成员大小的整数倍。

举个例子：

struct Example {
    char a;    // 1字节
    int b;     // 4字节
    short c;   // 2字节
};

在GCC下，这个结构体的大小是多少？

• a占偏移0，没问题。
• b需要4字节对齐，所以从偏移4开始，前面填充3字节。
• c需要2字节对齐，偏移8正好是2的倍数，直接放。
• 结构体总大小：10字节。但最大成员是int（4字节），所以需要对齐到4的倍数，最终大小是12字节。

我在项目中遇到过这种情况：一个结构体里字段顺序没排好，结果白白多了几十字节的填充。对于嵌入式设备来说，这可能是致命的——内存就那么点，能省则省。

13.3 MSVC的对齐策略

MSVC的规则和GCC大体相似，但有一个关键区别：MSVC默认使用8字节对齐（在64位平台上）。这意味着，即使结构体里最大成员是4字节，MSVC也可能按8字节来对齐整个结构体。

还是刚才那个例子：

struct Example {
    char a;
    int b;
    short c;
};

在MSVC下，a、b、c的偏移和GCC一样。但最后一步——整个结构体的大小，MSVC会按8字节对齐，所以最终大小是16字节，而不是12字节。

为什么会这样？因为MSVC的默认对齐值（/Zp8）是8。你可以通过#pragma pack来修改这个值。

特性	GCC	MSVC
默认对齐值	最大成员大小	8字节（64位）
结构体尾部对齐	按最大成员对齐	按默认对齐值对齐
控制方式	__attribute__((aligned))	#pragma pack
紧凑模式	__attribute__((packed))	#pragma pack(1)

13.4 __attribute__((packed)) 的使用

好了，现在进入今天的重头戏——__attribute__((packed))。这个属性是GCC提供的，用来告诉编译器：别给我加填充字节，所有成员紧挨着放。

用法很简单：

struct __attribute__((packed)) PackedExample {
    char a;
    int b;
    short c;
};

加了packed之后，这个结构体的大小就是1+4+2=7字节，没有任何填充。偏移量分别是0、1、5。

听起来很美好，对吧？但我要提醒你：packed是一把双刃剑。

我曾经在一个ARM嵌入式项目里，用packed压缩了一个网络协议结构体。结果程序跑起来时不时就挂掉，查了两天才发现是packed导致int字段没有4字节对齐，CPU直接报了异常。从那以后，我对packed的使用就格外谨慎了。

13.5 跨编译器兼容性处理

如果你写的代码需要在GCC和MSVC之间移植，怎么办？

我的建议是：不要直接依赖编译器的默认行为，而是显式控制对齐。

对于GCC，用__attribute__((packed))和__attribute__((aligned(n)))。

对于MSVC，用#pragma pack(push, n)和#pragma pack(pop)。

为了统一，可以封装成宏：

#ifdef __GNUC__
#define PACKED_STRUCT __attribute__((packed))
#elif defined(_MSC_VER)
#define PACKED_STRUCT __pragma(pack(push, 1))
#define PACKED_END __pragma(pack(pop))
#endif

这样，在定义结构体时，只需要用PACKED_STRUCT和PACKED_END包裹即可，编译器差异被隐藏了。

13.6 知识结构图

下面这张图，帮你理清本章的核心逻辑：

13.7 避坑指南

最后，分享几个我亲身踩过的坑：

• 不要对包含浮点数的结构体用packed——浮点运算单元（FPU）对对齐要求极高，非对齐浮点访问在ARM上直接崩。
• 网络协议结构体一定要用packed——否则不同机器解析出来的字段偏移不一样，数据全乱套。
• 文件头结构体建议用packed——文件格式是固定的，不能因为编译器不同就改变布局。
• 性能敏感的结构体不要用packed——非对齐访问的代价，在高频访问场景下会被放大。

我曾经接手过一个项目，前任工程师把所有结构体都加了packed，理由是「省内存」。结果整个系统跑起来比预期慢了30%。去掉packed之后，性能立马恢复正常。所以，packed这东西，用之前一定要想清楚：你到底是要省内存，还是要保性能？

好了，关于GCC和MSVC的对齐差异，以及__attribute__((packed))的使用，今天就聊到这里。记住一句话：对齐是编译器的善意，packed是不得已的选择。

---

公众号:蓝海资料掘金营，微信deep3321