17370845950

std::aligned_storage 是编译期生成的未初始化对齐缓冲区，专为 placement new 提供合规内存，不管理生命周期，C++23 已弃用，应改用 std::aligned_storage_t 或 alignas(std::byte)。

std::aligned_storage 本质是编译期对齐占位符

std::aligned_storage 不分配内存，也不管理对象生命周期，它只在编译期生成一个 足够大且满足指定对齐要求的未初始化字节缓冲区。它的底层用途非常具体：为 placement new 提供合规的原始内存地址 —— 即确保该地址能安全承载指定类型（如 std::string、std::vector）的对象实例。

常见错误现象：直接用 char buf[sizeof(T)] 做 placement new 目标，但 buf 的地址可能不满足 T 所需的对齐（例如 alignof(__m256) = 32），导致未定义行为（SIGBUS 或静默数据损坏）。

• 它不等价于 std::aligned_alloc（后者是运行时堆上对齐分配）
• 它不自动调用构造/析构；你必须显式用 new (ptr) T{...} 和 ptr->~T()
• C++23 起已弃用，推荐改用 std::aligned_storage_t 别名或更现代的 std::byte[N] + std::assume_aligned

典型使用场景：实现简易 variant 或对象池

当你需要在固定大小缓冲区中“复用内存”存放不同类型的对象（比如 int、std::string、MyHeavyStruct），又不想依赖堆分配时，std::aligned_storage 是构建这种 union-like 存储的基础。

关键点在于：必须按所有可能类型的 最大对齐 和 最大尺寸 来配置 std::aligned_storage：

struct MyVariant {
    // 支持 int（align=4）、std::string（align=8）、MyVec（align=32）
    using storage_t = std::aligned_storage_t;
    alignas(alignof(std::string)) char data[sizeof(std::string)];

    template 
    void emplace(T&& t) {
        new (data) std::remove_reference_t(std::forward(t));
    }
};

注意：alignas 修饰 data 是冗余的（std::aligned_storage_t 已保证），但显式写出可增强可读性；真正不可省的是对齐值必须 ≥ 所有候选类型的 alignof。

为什么不能只靠 sizeof + alignof 手算？

手动计算看似可行，但容易忽略 ABI 细节：

• 某些平台（如 ARM64）对 long double 或向量类型要求严格对齐，而 sizeof(T) 可能掩盖 padding 分布
• 编译器可能因结构体内嵌或 ABI 要求，在 struct 末尾插入额外 padding，使实际所需缓冲区 > sizeof(T)
• std::aligned_storage 内部会做保守对齐扩展（例如：请求 16 字节对齐 + 20 字节大小，可能返回 32 字节缓冲并确保起始地址 %32 == 0）

所以即使你知道 T 的 sizeof 和 alignof，仍应优先用 std::aligned_storage_t —— 它封装了编译器对齐策略，比手写 alignas(N) char buf[M] 更可靠。

替代方案与迁移建议

C++17 起，std::aligned_storage 已被标记为 deprecated；C++23 正式移除。

• 用 std::aligned_storage_t（它是 std::aligned_storage::type 的别名，更简洁）
• 对简单 case，直接用 alignas(A) std::byte buf[N]，再配合 std::launder 和 std::assume_aligned
• 若需动态对齐（如运行时才知道对齐值），必须用 std::aligned_alloc / _aligned_malloc 等系统 API

真正容易被忽略的是：无论用哪种方式，只要做了 placement new，就必须严格配对调用析构函数 —— 编译器不会帮你做，漏掉就会导致资源泄漏（如 std::string 内部堆内存未释放）。