为什么 std::aligned_storage 在 C++23 中被弃用以及使用什么替代？

Question

我刚刚看到C ++ 23计划将两者都弃用 std :: aligned_storage 和std :: aligned_storage_t以及 std :: Aligned_union和std :: aligned_union_t 。

据我所知，在对齐存储中的新对象并不是特别constexpr友好，但这似乎不是完全抛出类型的好理由。这使我假设使用std :: aligned_storage和我不知道的朋友还有其他一些基本问题。那会是什么？

还有这些类型的拟议替代方案吗？

Answer 1

以下是 P1413R3：

背景

aligned_* 对代码库有害，不应使用。在高层次上：

• 使用 aligned_* 会调用未定义的行为（类型无法提供存储。）
• 这些保证不正确（标准只要求类型至少与请求的大小一样大，但没有设置大小上限。）
• 由于多种原因，API 是错误的（参见“关于 API”。）
• 由于 API 是错误的，所以几乎所有用法都涉及相同的重复准备工作（请参阅“现有用法”。）

---

关于 API

std::aligned_* 遭受许多糟糕的 API 设计决策的困扰。其中一些是共享的，一些是特定的。至于分享的内容，主要存在三个问题[为了简洁起见，这里仅包含一个问题]：

• 需要使用 reinterpret_cast 来访问该值

std::aligned_* 实例上没有 .data()，甚至没有 .data。
相反，API 要求您获取对象的地址，用它调用 reinterpret_cast(...)，然后
最后间接产生的指针给你一个T&。这不仅意味着它不能在 constexpr 中使用，而且
在运行时，很容易意外调用未定义的行为。 reinterpret_cast 是使用要求
API 的错误是不可接受的。

---

建议更换

aligned_* 最简单的替代实际上不是库功能。相反，用户应该使用正确对齐的
std::byte 数组，可能会调用 std::max(std::initializer_list) 。这些可以在
分别是 和 标头（本节末尾有示例）。
不幸的是，这种替代并不理想。要访问 aligned_* 的值，用户必须调用 reinterpret_cast
将字节读取为 T 实例的地址。使用字节数组作为替代并不能避免这个问题。也就是说，重要的是要认识到，在已经存在的地方继续使用reinterpret_cast并不比在以前不存在的地方新引入它那么糟糕。 ...

上述部分来自已接受的退休 aligned_* 提案，后面是许多示例，例如这两个替换建议：

// To replace std::aligned_storage
template <typename T>
class MyContainer {
private:
    //std::aligned_storage_t<sizeof(T), alignof(T)> t_buff;
    alignas(T) std::byte t_buff[sizeof(T)];
};

// To replace std::aligned_union
template <typename... Ts>
class MyContainer {
private:
    //std::aligned_union_t<0, Ts...> t_buff;
    alignas(Ts...) std::byte t_buff[std::max({sizeof(Ts)...})];
};