_alignof是编译期常量，返回类型的自然对齐字节数（如_alignof(int)通常为4），仅依赖类型定义而非实际地址；它不保证变量实际对齐，运行时需用uintptr_t转址后模运算或位运算验证。
如何用 _alignof 判断类型对齐要求
_alignof 是编译期常量表达式，返回类型在内存中自然对齐所需的字节数（即最小对齐边界）。它不看变量实际地址，只看类型定义本身。比如 _alignof(int) 通常是 4，_alignof(double) 在多数 x64 平台是 8，而 _alignof(std::max_align_t) 给出当前平台“最严格”的基本对齐值。
注意：它和 alignof（C++11 标准关键字）行为一致，但 _alignof 在旧编译器（如 VS2013）或某些嵌入式工具链中更可用；若项目要求 C++11+，优先用 alignof 避免兼容性歧义。
常见误用：
- 把 _alignof 当作运行时函数调用（它不是函数，不能传变量名，只能传类型）
- 混淆 _alignof(T) 和 sizeof(T)：前者是地址约束，后者是存储大小，二者无必然关系（例如空 struct 的 sizeof 可能为 1，但 _alignof 仍为 1 或更高）
如何用指针模运算判断某地址是否满足对齐
运行时验证一个指针是否按指定字节数对齐，本质是检查其数值能否被对齐值整除。由于内存地址是整数，直接对指针做模运算是最直白的做法——但必须先转成整型。
正确写法示例：
立即学习“C++免费学习笔记（深入）”；
void* ptr = aligned_alloc(16, 32); // 假设分配成功 uintptr_t addr = reinterpret_cast<uintptr_t>(ptr); bool is_16_aligned = (addr % 16 == 0); // ✅ 安全、可读、无副作用
容易踩的坑：
- 用 int 或 long 强转指针：在 LP64（如 Linux x64）下 long 虽为 64 位，但语义不明确；应始终用 uintptr_t（定义在 <cstdint>），它是专为存放指针值设计的无符号整型
- 对未对齐地址做模 0 操作（比如误把对齐值写成 0）：会导致运行时崩溃，建议对齐值校验（>0）
- 忘记指针可能为 nullptr：nullptr 转 uintptr_t 是 0，0 % N 在 N > 0 时为 0，逻辑上算“对齐”，但业务中通常需单独判空
为什么不能只靠 _alignof 判断变量实际地址对齐
_alignof(T) 只保证该类型变量「可能」被分配在满足对齐要求的位置，但不保证一定如此——实际对齐取决于分配方式和上下文。
典型反例：
- 普通栈变量：编译器通常按最大成员对齐，但若结构体嵌套或手动 #pragma pack，实际偏移可能破坏自然对齐
- malloc 返回地址：只保证 std::max_align_t 对齐（通常是 16），无法满足 _alignof(__m256)（32）或 _alignof(__m512)（64）等 SIMD 类型要求
- 数组内元素：首元素对齐不等于后续元素对齐。例如 char arr[100] 中，&arr[16] 是否 16 对齐，取决于 arr 起始地址，而非 char 的 _alignof(char)（=1）
所以，_alignof 是设计依据，不是运行时断言依据；真正要确认某个具体地址是否对齐，必须结合指针转整型 + 模运算（或位运算）实测。
性能与可移植性：模运算 vs 位运算判断对齐
模运算（%）直观易懂，但编译器对 2 的幂次对齐值（如 4/8/16/32）通常会自动优化为位运算。不过显式用位运算更可靠，也避免除零风险：
bool is_power_of_two_aligned(uintptr_t addr, size_t align) {
return (align & (align - 1)) == 0 ? (addr & (align - 1)) == 0 : (addr % align == 0);
}
说明：
- 只有当 align 是 2 的幂时，(addr & (align - 1)) == 0 才等价于 addr % align == 0
- 大多数对齐需求（SSE/AVX 缓存行/页对齐）都满足 2 的幂，此时位运算更快且无分支
- 若对齐值来自配置或运行时输入（如用户指定 12 字节对齐），则必须用模运算，并确保 align > 0
跨平台提醒：Windows 上 _aligned_malloc 和 Linux 上 aligned_alloc 行为略有差异（如对齐值最小限制、失败返回值），判断前务必确认分配函数已成功返回非空指针。
