那会儿我们写 C，也写一点 C with classes。项目不大，胆子不小，总觉得内存嘛，不就是一排字节，指针嘛，不就是一把钥匙。直到有一天，线上啪一下，不是逻辑错，是进程没了，还特别挑人：你电脑上跑得好好的，换一台机器就崩。你甚至会怀疑人生：“我这代码，怎么还带地域歧视的？”
那次线上啪一下：小协议把我送进排查地狱
我当时在写一个小项目，自己定了个二进制协议。格式很简单：一个字节 tag，后面跟一个 int。为了省空间，我用了 #pragma pack 把结构体挤紧，你可以先把它理解成一句“拜托编译器别给我留空隙”。它不是 C++ 标准的一部分，所以天然带点“平台味”。
```c++
pragma pack(push, 1)
struct Msg {
unsigned char tag;
int value;
};
pragma pack(pop)
看起来没毛病，结构体更紧凑了，你还挺开心。然后读包的时候我又更省事了一步，直接把网络包当成 `Msg*`，省掉了解析。
```c++
const unsigned char* buf = get_packet();
auto m = reinterpret_cast<const Msg*>(buf);
return m->value;
在我电脑上它能跑，在线上某些机器上它会崩，报错有时还很朴素：bus error。你可以把 bus error 理解成硬件在跟你说：这个内存访问姿势不对，我不服务。它通常不是“代码算错了”，更像是你访问了一个 CPU 不接受的地址对齐方式。
对齐是啥：别让 int 站在歪地砖上
先把“对齐”掰碎。你可以把内存当成一排地砖，有些类型喜欢站在“整块砖”的边界上。int 经常就是这种，比如 4 字节对齐，你可以粗暴理解成：地址最好能被 4 整除。
为什么要这样？因为有些 CPU 读内存很讲规矩，你让它从一个“歪位置”搬 4 字节，它就直接拒绝。这事最阴的是，不是所有机器都拒绝，于是你会得到那句经典评价：“在我这儿没问题。”
这规矩是谁定的：硬件 + ABI + 编译器
你可能会问：“凭什么 int 就要 4 字节对齐？”答案通常不是 C++ 标准，而是硬件和 ABI。ABI 你可以先把它理解成平台的一套约定，包括：函数参数怎么传，结构体怎么布局。编译器得按 ABI 说话，否则你链接别人的库就会鸡同鸭讲。
一句话成段：对齐很多时候不是“你想不想”，是“你得跟大家一样”。
结构体为啥不“贴着放”：填充字节（padding）
你刚学 C 的时候，会很自然地以为结构体就是字段一个挨一个。但现实是：编译器经常会偷偷塞一些“空洞”，它们叫填充字节，目的只有一个：让后面的字段站得更齐。
举个最常见的例子。
```c++
struct A {
char c;
int i;
};
很多平台上，`int` 喜欢 4 字节对齐。于是 `c` 后面会被塞几个字节，让 `i` 站到更规矩的位置。你看到的 `sizeof(A)` 往往会比 `sizeof(char) + sizeof(int)` 大。
再来个对比例子。
```c++
struct B {
int i;
char c;
};
把 int 放前面，很多时候空洞会少一点。这也是老程序员常说的那句：“字段顺序也会影响结构体大小。”
如果你想更直观一点，可以看“成员偏移”。
```c++
std::cout << offsetof(A, c) << "\n";
std::cout << offsetof(A, i) << "\n";
`offsetof(A, i)` 告诉你：`i` 从结构体开头往后数多少字节，中间那段空出来的，就是 padding。这里用到 `offsetof`，一般会 `#include <cstddef>`。
这不是编译器闲得慌，这是它在替硬件擦屁股。
### `#pragma pack` 到底干了啥：它改“队形”，不改“规矩”
`#pragma pack(1)` 这类东西，干的事很简单，它在说：空洞少塞点。它解决的是“布局长什么样”，它没解决的是“硬件到底接不接受这种访问”，这俩不是一回事。
于是你会得到一个更紧凑的布局，也更容易得到一个“成员不对齐”的布局。
```c++
#pragma pack(push, 1)
struct Packed {
char c;
int i;
};
#pragma pack(pop)
很多人第一次踩坑，就是在这里。他以为“结构体更紧凑”只影响 sizeof，但它还会影响你后面所有“按类型读取”的代码。
一句话成段：紧凑，不等于安全。
当年我们怎么踩坑：把字节硬当成结构体
再回头看那句强转。reinterpret_cast 你可以理解成一句：“你别问，我很确定。” 编译器会信你，然后它会生成一条“按 int 的方式去读”的指令。它不会帮你检查地址是不是站齐了，因为你刚才已经拍胸脯了。
如果地址没对齐，某些机器就啪一下。这类问题还有个更正式的名字：未定义行为，意思是标准没承诺你会得到什么结果，你不能指望它在所有平台都表现一致。
还有个更隐蔽的问题：那块内存里根本没有对象
对齐只是第一层，第二层更像 C++ 的脾气。你把 buf 强转成 Msg*，你以为你得到了一个 Msg。但很多时候，你手上只有一段字节，它还没被“当成一个对象”构造出来。
这句话听起来有点绕，你可以先记一句粗暴结论：字节是字节，对象是对象。
如果你现在有点懵，可以先用一个反例把感觉抓住。
```c++
struct Bad {
std::string s;
};
如果结构体里有 `std::string` 这种东西，你就别想着用 `memcpy` 把一段字节“变成它”，因为 `std::string` 里面不只是字节，它还有自己的内部[指针](https://yunpan.plus/f/25-1)、长度、资源，这些东西需要构造和析构。这里一般会 `#include <string>`。
所以对协议/文件这种“外部来的字节”，更稳的做法是按字段把值拷出来，别整段硬当结构体。
### 未定义行为为啥这么可怕：它不是“报错”，是“没承诺”
很多新手会把“未定义行为”理解成运行时报个错，但它更像一份合同。合同里写着：这块不包，你出了事别来找我。
于是它可能表现成：今天没事，明天优化开高一点就炸。它也可能表现成：你以为读到的是 `value`，其实读到的是一段乱七八糟的东西。还有一种更坑的：你开了优化，编译器开始“相信你写的类型规则”，它做的重排和缓存，可能让你调试都调不明白。
### 当年大家怎么从坑里爬出来：靠规矩，靠绕开
第一种修法很土：别把字节直接当成结构体，把值拷出来。按字节拷贝，至少不会触发“未对齐的 int 读取”。
```c++
int v;
std::memcpy(&v, buf + 1, sizeof(v));
return v;
这段代码要用 std::memcpy 的话，一般会 #include <cstring>。memcpy 看着慢，但它的语义很清楚：按字节拷贝，CPU 不需要做“未对齐的 int 读取”。而且它还有一个隐含好处：它不要求 buf 的地址对齐，只要 buf 这块内存能读到就行。
如果你想把这个例子写完整一点，大概会长这样：
```c++
unsigned char tag = buf[0];
int value;
std::memcpy(&value, buf + 1, sizeof(value));
这三行就够了，你已经绕开了“对象没构造”和“未对齐读取”这两条雷。
第二种修法更像“方言”：你去找编译器的私货。有人用 `#pragma pack`，有人用 `__attribute__((aligned(16)))`，有人用 `__declspec(align(16))`。
能用，但你会开始维护一堆平台分支。对齐这事就变成了口音，同一句话，不同编译器说出来不一样。
### 方言时代都怎么做：GCC / MSVC 的私房菜
在标准关键字出现之前，各家都有自己的写法。概念很像，但拼写完全不统一。GCC/Clang 这边，你经常会看到这种：
```c++
struct __attribute__((aligned(16))) X {
int v;
};
意思是：让 X 按 16 字节对齐。看着就像后来的 alignas(16)。MSVC 这边又是另一套：
```c++
__declspec(align(16)) struct X {
int v;
};
能用，但你一旦跨平台，就得写一堆宏。你甚至会看到有人写出“宏的宏”，专门用来包这些方言。这类宏的共同结局是：你的代码开始“长得像跨平台”，但你心里明白，它其实是在缝补生态。
### C11 也补了一刀：_Alignas / _Alignof
C 这边其实也没闲着，C11 加了 `_Alignas` 和 `_Alignof`。
```c
_Alignas(16) unsigned char buf[64];
size_t a = _Alignof(int);
它们和 C++11 的 alignas/alignof 是一类东西，只是 C 语言更喜欢下划线这种“别碰我”的关键字风格。这也解释了一个现象：很多人第一次看到 C++11 的 alignas/alignof 会觉得眼熟，因为它们不是从天上掉下来的。有意思的是，它们解决的是同一个坑，只是 C 和 C++ 用了不同的语法外衣。
动态内存也有对齐：POSIX / Windows 的老办法
alignas 解决的是“变量/对象怎么摆”，但你要是想在运行时申请一块“指定对齐”的内存呢？当年大家更多靠库函数。POSIX 有 posix_memalign，Windows 有 _aligned_malloc。
它们的共同点是：你拿到的是一块对齐好的内存。缺点也很现实：接口不统一，释放方式还可能不一样。所以你会发现，对齐这件事在很长时间里，都处在“大家都需要，但谁也没统一”的状态，直到 C11 / C++11 把它收编。
你以为你没碰过对齐：其实 new 一直在替你干活
很多读者第一次看到对齐，会紧张，觉得是不是每个指针都得算一遍余数。倒也不至于，你平时写的这类代码：
```c++
auto p = new int(42);
`new int` 返回的地址，编译器会保证它满足 `int` 的对齐要求，你不用操心。同理，很多平台上的 `malloc` 也会保证返回的地址至少能满足“常见类型”的对齐。
### 什么时候会破功：你开始自己管一堆原始字节
真正容易出事的是这种：
```c++
unsigned char buf[64]{};
auto p = reinterpret_cast<int*>(buf + 1);
你绕开了 new，你绕开了 malloc，你相当于在说：我自己来。然后对齐就开始向你收债。你想让它稳一点，最直接的办法还是 alignas。
```c++
alignas(int) unsigned char buf[64]{};
auto p = reinterpret_cast<int*>(buf);
这样至少把“地砖”铺正了。有时候你不是想对齐某个具体类型，你只是想要一个“通用缓冲区”，大概意思是：放个 `int`、`double` 都别炸。
```c++
alignas(std::max_align_t) unsigned char buf[64]{};
std::max_align_t 你可以先理解成这个平台上“最挑位置的那种基础类型”的对齐。这里一般会 #include <cstddef>。
标准库里其实也有旧工具：std::aligned_storage
在你还没想写对象池之前，标准库其实给过一套“安全的字节盒子”。
```c++
using Storage = std::aligned_storage_t<sizeof(int), alignof(int)>;
Storage s;
这玩意儿你可以先理解成一块大小够、对齐也够的内存。这里用到 `std::aligned_storage_t`，一般会 `#include <type_traits>`。它不是让你去炫技，它是在提醒你：标准库很早就意识到“原始字节很危险”。
### 你真要在一块 buffer 里摆对象：std::align 更像正道
写对象池也好，做协议解析也好，你经常会遇到这种需求：我有一大块字节，我要从里面切出一块给 `S`。
```c++
unsigned char buf[64]{};
void* p = buf;
std::size_t space = sizeof(buf);
auto aligned = std::align(alignof(int), sizeof(int), p, space);
std::align 会帮你把 p 往后挪，挪到一个满足对齐的位置，挪不出来就返回空指针，你就别硬上了。这里一般会 #include <memory>。
C++11：终于能把规矩问清楚（alignof）
后来 C++11 给了一个很朴素的工具：alignof(T)。它回答的是一个很具体的问题：类型 T 这种家伙，最少要按多少字节对齐。这是编译期常量，白话点说就是：编译的时候就能算出来，不用把程序跑起来。你可以拿它做断言，让规矩变成代码的一部分。
你也可以用它做“自检”，比如你拿到一个地址，想知道它对不对齐。
```c++
unsigned char buf[64]{};
auto addr = reinterpret_cast<std::uintptr_t>(buf + 1);
auto bad = (addr % alignof(int)) != 0;
这里用到 `std::uintptr_t`，一般会 `#include <cstdint>`。这里的 `%` 你可以理解成：看看它是不是站在正确的地砖边界。`bad` 为真，就别再用“按 int 读取”的方式去碰它了。
再来一个更直观的例子，你可以直接把“对齐要求”打印出来看看。
```c++
std::cout << alignof(char) << "\n";
std::cout << alignof(int) << "\n";
std::cout << alignof(double) << "\n";
这里用到 std::cout，一般会 #include <iostream>。具体数字会因平台而异，但你通常会看到：越“宽”的类型，越挑位置。
你也可以用它给自己写个“护栏”，比如你想要求一个类型必须按 16 字节对齐。
```c++
struct alignas(16) Vec4 {
float v[4];
};
static_assert(alignof(Vec4) == 16, "");
这段代码的意思很直白，如果某天有人改了 `Vec4`，导致它不再 16 字节对齐，编译期就会把他拦下来。
```c++
struct S {
char c;
int i;
};
static_assert(alignof(S) >= alignof(int), "");
这行断言的价值不在“聪明”，它在替你把规矩写死，以后谁改结构体，谁就得面对它。
C++11：也终于能把要求说出口（alignas）
另一个工具是 alignas，它让你能写出一句：这块内存，你给我站齐点。你不用再写编译器私货，也不用靠同事口口相传。但也别把它想得太神，你日常写的大多数变量，其实天生就“站齐”了。真正容易出事的是：你自己在管一堆原始字节。
这也是为什么很多人学对齐，不是从“性能优化”学会的，是从“线上事故”学会的。
alignas 不只可以用在类型上，也可以用在变量上。
```c++
alignas(16) unsigned char buf[64]{};
它的意思是：这块 `buf` 从一开始就站在 16 字节边界上，你后面用它切片、摆数据，会省很多心。
比如你写了个小对象池，用一块字节数组当内存。
```c++
struct S { int x; };
unsigned char pool[64]{};
auto p = reinterpret_cast<S*>(pool + 1);
这段强转只是为了复现“站不齐会出事”，真写对象池时，你通常会更谨慎地构造对象。这里 pool + 1 基本就是在故意找事，它很可能把 S 放到一个不对齐的位置，然后你又会得到“某些机器啪一下”。
你可以先把“地砖”铺正。
```c++
struct S { int x; };
alignas(S) unsigned char pool[64]{};
auto p = reinterpret_cast<S*>(pool);
`alignas(S)` 的意思是：按 `S` 需要的对齐来对齐这块数组，这不是让你更快，它先让你更不容易死。
还有一种很常见的用法，你想要的是“给某个变量留个独立的位置”，别跟别人挤。
```c++
struct alignas(64) Counter {
std::uint64_t v;
};
这里用到 std::uint64_t，一般会 #include <cstdint>。这里的 64，你可以先理解成“给它一个更大的格子”，别跟别的东西挤在同一小段内存里。这类写法通常和性能有关，但更现实的收益是：行为更可控。
横向对比：你到底该用哪一类“对齐工具”
如果你现在脑子里全是工具名，很正常。你可以先按场景来分：
- 第一类：你在定义类型/变量的布局，这就是
alignas 的地盘。
- 第二类：你在写代码自检，或者在做编译期约束，这就是
alignof 的地盘。
- 第三类：你在运行时申请一块对齐内存，那就去看
posix_memalign 这类库函数，或者更高版本标准里的 aligned_alloc。
一句话成段：别把它们混成一个按钮。
小心点：alignas 不是许愿池
alignas 只能指定“合理”的对齐值，你不能用它把对齐降到低于类型本身的要求。你说“我就要 int 按 1 字节对齐”，编译器大概率会拒绝你。
你也别乱写一个奇怪的数字，比如这样：
```c++
alignas(3) int x;
很多编译器会直接报错，因为对齐值通常要求是 2 的幂，这是为了让硬件和 ABI 好实现。这不是它小气，是它在替你挡灾。
### 最后一个洞见：对齐不是优化，是契约
对齐这事，最阴的是反馈机制。你写错了，它不一定立刻报错，它会等你换机器、换编译器，或者线上某个输入“刚好踩中”，然后啪一下。
一句话成段：把规矩写进代码里，别写进传说里。
发表于 3 天前
|
查看: 12|
回复: 0
