alignof：C++里那个总被忽略的“内存尺子”

写C++时，你有没有遇到过这样的场景：结构体明明只存了几个int和char，sizeof却返回24而不是12？或者把自定义类型传给SIMD函数，程序在某台机器上突然崩溃——调试半天发现是地址没对齐？这时候，alignof就是你该摸出来的那把“内存尺子”。

它不分配内存，不构造对象，甚至不生成任何运行时代码。它只是在编译期安静地告诉你：这个类型，CPU要求它站在哪条“安全线”上。

alignof(T) 返回的是类型 T 的对齐要求（单位字节），本质是 std::alignment_of_v<T> 的简写。它查的不是你“想怎么放”，而是硬件和ABI共同签发的“强制站位令”。

比如 alignof(int) 通常是4，alignof(double) 在x64上通常是8——这不是C++凭空定的，而是x86-64 ABI规定double必须落在8字节边界，否则某些指令（如movapd）直接抛SIGBUS。你硬要把它塞进奇数地址？CPU会用段错误教你尊重物理规律。

真正容易踩坑的，是自定义类型。看这段代码：

struct A {
    char c;
    int i;
};

直觉上，c占1字节，i紧挨着占4字节，总共5字节。但sizeof(A)很可能是8，而alignof(A)也是4。为什么？因为结构体的对齐要求，等于其所有非静态成员中最大的对齐值（这里int拉高到4），且整个结构体大小必须是该对齐值的整数倍——这是为了保证数组中每个元素都能满足对齐。

但注意：alignof只看成员，不看填充字节。即使你加了char padding[3]手动对齐，alignof(A)依然由int决定，不会变成1或8。它反映的是“最严苛的那个成员”提的要求，不是你手写的布局。

更隐蔽的情况出现在继承和空基类优化（EBO）中。考虑：

struct Empty {};
struct B : Empty {
    double d;
};

alignof(B) 是8，不是1。尽管Empty本身对齐要求为1，但B里出现了double，整个类型的对齐就被拉升到8。alignof永远以“实际参与内存布局的最强约束者”为准——它不认“空”，只认“有实际存储语义的成员”。

这引出一个实用技巧：当你需要确保某块内存可安全用于特定类型时，别只检查sizeof，先查alignof。例如用malloc分配缓冲区存放std::max_align_t（通常为16）对齐的类型：

void* buf = malloc(1024);
// 错！malloc只保证max_align_t对齐（通常是16），但若你要存AVX512向量（需64字节对齐）？
if (reinterpret_cast<uintptr_t>(buf) % alignof(__m512) != 0) {
    // 必须对齐到64字节——得用aligned_alloc或自己调整指针
}

C++17起，aligned_alloc成了标准方案，但它要求对齐值是2的幂且不小于alignof(max_align_t)。这时alignof就是你判断“能不能用”的第一道闸门。

还有个常被忽视的点：alignof对引用类型返回被引用类型的对齐值。alignof(int&) 等于 alignof(int)，不是1。引用不是独立对象，它不改变底层对齐契约。

模板元编程里，alignof更是关键拼图。比如实现一个通用内存池，你需要根据类型动态选择对齐策略：

template<typename T>
class Pool {
    static constexpr size_t alignment = alignof(T);
    static constexpr size_t block_size = (sizeof(T) + alignment - 1) & ~(alignment - 1);
    // 确保每个T实例都严格对齐
};

这里alignof不是装饰，是计算block_size的基石。漏掉它，池子里的对象可能集体“站歪”，触发未定义行为。

最后提醒一句：alignof查的是声明类型，不是运行时对象的实际地址。同一个int变量，无论你把它放在栈、堆还是全局区，alignof(int)永远是4。它回答的是“这类东西原则上该怎么摆”，而不是“此刻它恰好在哪”。

所以，下次看到结构体大小异常、memcpy后数据错乱、或SIMD指令崩掉，别急着翻编译器文档——先掏出alignof，量一量你的类型到底被硬件划了哪条线。它不炫技，不造对象，就安安静静站在编译期，告诉你：内存世界里，有些规矩，连C++都得守。