c++ 17规范弃用了construct对象的destroy和std::allocator成员。工作组在“弃用std::allocator的冗余成员”标题下提供了弃用其他成员函数here的理由。
但是，他们没有具体提及为什么不赞成使用这两个成员，或者关于替换该功能的建议是什么。我假设其含义是改为使用std::allocator_traits::construct。
关于this comment about construct ，在某些情况下是否实际上仍然有必要实现std::allocator_traits::construct，我有些困惑
对于自定义分配器(例如，使用memalign进行页面对齐的内存)，回退到位置new总是会产生正确的行为吗？
最佳答案
allocator requirements table表示construct(c, args)(如果提供)必须“在C处构造c类型的对象”。
它完全没有说1)将哪些参数传递给C的构造函数，或2)如何将这些参数传递。这是分配器的选择，实际上，标准中的两个分配器在将参数传递给C的构造函数之前确实弄乱了参数: std::scoped_allocator_adaptor 和 std::pmr::polymorphic_allocator 。特别是在构造std::pair时，它们传递给pair的构造函数的参数甚至可能与收到的参数不相似。
也不要求完全转发。如果效率不高，则符合C++ 03风格的construct(T*, const T&)。
不推荐使用std::allocator的construct和destroy，因为它们没有用:没有好的C++ 11和更高版本的代码应该直接调用它们，并且它们在默认值之上没有添加任何内容。
处理内存对齐应该是allocate的任务，而不是construct的任务。