内存对齐是为了提升c++pu访问效率，通过填充字节使结构体成员位于合适地址。1. cpu按块读取数据，若未对齐可能引发多次访问或异常；2. 编译器默认按成员大小对齐，结构体总大小为最大成员对齐值的倍数；3. #pragma pack可改变对齐方式，实现紧凑布局但可能影响性能；4. c++11的alignas提供更标准、细粒度的对齐控制，主要用于增强对齐以满足高性能需求。
当我们谈论结构体成员的内存对齐时，其实就是在说编译器为了性能优化，在内存中如何巧妙地安排数据。它不是简单地把成员一个接一个地堆叠起来，而是会根据类型大小和系统架构，在成员之间插入一些“空隙”，也就是填充字节，确保每个成员都能在CPU最舒服的位置上被访问。这通常意味着结构体的实际大小会比你预期的——也就是所有成员大小简单相加——要大一些。而
#pragma pack
和
alignas
就是我们用来干预这种“巧妙安排”的利器，前者是编译器特定的指令，后者则是C++标准提供的更现代、更具可移植性的控制方式。
内存对齐这事儿，说白了，就是为了让CPU能更高效地从内存里取数据。你想想，CPU从内存里读数据，它可不是一个字节一个字节地读，而是按“块”来的，比如4字节、8字节，甚至更大，像缓存行通常是64字节。如果一个数据项，比如一个
int
（4字节），恰好跨越了CPU的读取边界，那CPU就得进行两次甚至多次内存访问才能把它完整地读出来，这效率自然就下来了。所以，编译器为了避免这种情况，默认就会让每个数据成员都“安分守己”地呆在它自己的对齐边界上。比如说，一个
int
类型的数据，它通常会被对齐到4字节的地址上（即地址能被4整除），一个
double
（8字节）就会被对齐到8字节的地址上。结构体整体的大小也会是其最大成员对齐值的倍数，这样当你创建数组时，每个结构体实例也都能正确对齐。这个过程，就是通过在成员之间插入一些无用的“填充字节”（padding bytes）来完成的。
理解内存对齐的底层原理与默认行为
所以，这背后到底有什么考量呢？本质上，CPU与内存的交互效率是核心。现代CPU通常采用总线宽度和缓存线（cache line）的概念来存取数据。如果一个变量没有对齐到其“自然”边界，比如一个4字节的整数却从一个奇数地址开始存放，那么CPU可能需要两次内存访问才能把它完整地加载到寄存器中。更糟糕的是，在某些RISC架构的处理器上，这种未对齐访问甚至可能直接导致硬件异常或性能严重下降。
默认情况下，编译器会遵循一个相对简单的规则：每个成员变量的偏移量（offset）必须是其自身大小的倍数（或者说是其自身类型对齐值与结构体当前最大对齐值中的较小者）。同时，整个结构体的总大小必须是其最大成员对齐值的倍数。
我们来看个例子，假设在64位系统上：
struct MyStruct { char a; // 1 byte int b; // 4 bytes char c; // 1 byte double d; // 8 bytes};
如果没有对齐，你可能会觉得它就是1+4+1+8 = 14字节。但实际情况是：
a
(1字节) 放在偏移量0。
b
(4字节) 需要4字节对齐。
a
后面只剩1字节，不够，所以会填充3个字节。
b
从偏移量4开始。
c
(1字节) 放在偏移量8。
d
(8字节) 需要8字节对齐。
c
后面只剩1字节，不够，所以会填充7个字节。
d
从偏移量16开始。整个结构体需要8字节对齐（因为
double
是8字节），当前总大小是16 + 8 = 24字节，这已经是8的倍数，所以不需要在末尾再填充。
所以，
sizeof(MyStruct)
最终很可能是24字节。你看，虽然只有14字节的有效数据，但为了性能，白白多占了10字节的内存。
精准控制内存布局：#pragma pack 的实战应用
有时候，这种默认的对齐行为并不总是我们想要的。比如，你可能在和一些外部的二进制数据格式打交道，这些数据格式可能要求严格的“紧凑”布局，不含任何填充；或者你正在开发嵌入式系统，内存资源极其宝贵，需要尽可能地减少结构体大小。这时候，
#pragma pack
就派上用场了。
#pragma pack
是一个编译器特定的指令（这意味着它的行为可能在不同编译器之间略有差异，但主流编译器如GCC、MSVC都支持），它允许你改变默认的结构体成员对齐方式。它的基本用法是这样的：
#pragma pack(push, 1) // 将当前对齐设置压栈，并设置新的对齐字节数为1struct PackedStruct { char a; // 1 byte int b; // 4 bytes char c; // 1 byte double d; // 8 bytes};#pragma pack(pop) // 恢复之前保存的对齐设置
在这里，
#pragma pack(1)
意味着所有成员都将以1字节的边界对齐，或者以其自身大小的最小值对齐。如果自身大小小于1字节（这不可能），就按1字节。这意味着，编译器将不会插入任何填充字节，除非成员本身的大小超过了打包值。在
PackedStruct
的例子中，所有成员都将紧密排列：
a
(1字节) 偏移量0
b
(4字节) 偏移量1
c
(1字节) 偏移量5
d
(8字节) 偏移量6
所以，
sizeof(PackedStruct)
将会是1 + 4 + 1 + 8 = 14字节。
你也可以设置其他对齐值，比如
#pragma pack(4)
，这意味着成员将按照4字节或其自身大小的最小值进行对齐。
#pragma pack(push, 4)struct Aligned4Struct { char a; // 1 byte int b; // 4 bytes char c; // 1 byte double d; // 8 bytes};#pragma pack(pop)
在这个例子中：
a
(1字节) 偏移量0。
b
(4字节) 需要4字节对齐。
a
后面填充3字节。
b
从偏移量4开始。
c
(1字节) 偏移量8。
d
(8字节) 需要4字节对齐（因为
#pragma pack(4)
），但
double
自身需要8字节对齐，取两者最小值，这里是4。所以
d
从偏移量12开始（
c
后面填充3字节）。整个结构体需要4字节对齐，总大小是12 + 8 = 20字节。20是4的倍数。
#pragma pack
虽然强大，但使用时得小心。强制减少对齐可能导致CPU访问未对齐数据，这在某些处理器上会显著降低性能，甚至引发总线错误。所以，除非你明确知道自己在做什么，并且有充分的理由，否则不建议随意使用它来破坏默认的对齐规则。它更多地是用来解决特定兼容性问题的。
C++11
alignas
alignas
关键字：更细粒度的对齐控制
进入C++11时代，我们有了更标准、更灵活的对齐控制方式——
alignas
关键字。相较于
#pragma pack
这种“一刀切”的编译器指令，
alignas
允许你对单个变量、类型（包括结构体、类、联合体）或者结构体内的特定成员进行对齐控制。它的可移植性更好，因为它属于C++标准的一部分。
alignas
的语法很简单：
alignas(expression)
，其中
expression
必须是一个表示对齐边界的常量表达式，而且这个值必须是2的幂（比如1、2、4、8、16、32等）。
你可以这样使用它：
struct alignas(16) MyAlignedData { // 整个结构体都要求16字节对齐 int id; char name[12]; float value;};// 也可以对单个变量进行对齐alignas(32) char largeBuffer[1024];struct MixedAlignment { char status; alignas(8) long long timestamp; // 仅此成员要求8字节对齐 int counter;};
alignas
和
#pragma pack
的主要区别在于：
作用范围：
#pragma pack
是全局性的，影响其作用域内定义的所有结构体；而
alignas
是局部的，只影响它所修饰的那个变量或类型。控制方向：
#pragma pack
主要是用来 减少 对齐要求（比如从默认的8字节对齐减少到1字节对齐），以达到紧凑布局的目的。而
alignas
则主要用于 增加 对齐要求，比如当你需要某个数据结构满足更高的对齐标准时（例如，某些SIMD指令集如SSE/AVX需要16字节或32字节对齐的数据才能发挥最佳性能）。当然，
alignas
也可以用来“减少”对齐，但通常不是它的主要用途，而且实际效果会受到编译器默认对齐规则的限制。如果
alignas
指定的值小于类型默认对齐值，编译器可能会忽略或发出警告。可移植性：
alignas
是C++标准的一部分，这意味着你的代码在不同编译器和平台上会有更一致的行为。
使用
alignas
时，你通常是想确保某个数据块能够被CPU以最高效的方式访问，或者满足某些硬件/库的特定对齐需求。比如，如果你在处理大量图像数据，并且想利用SIMD指令进行并行计算，那么将图像行或像素块对齐到16字节或32字节是非常常见的做法。
虽然
alignas
提供了精细的控制，但也要注意不要过度对齐。不必要的对齐会浪费内存，因为编译器可能需要插入更多的填充字节。选择合适的对齐值，平衡性能和内存使用，才是关键。在实际项目中，除非有明确的性能瓶颈或外部接口要求，否则通常让编译器处理默认对齐就已经足够了。
以上就是结构体成员如何内存对齐 详解#pragma pack与alignas用法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1469834.html
微信扫一扫 
支付宝扫一扫 
