为什么在c ++ 17中不推荐使用std :: allocator的Construct和destroy函数? [英] Why are are std::allocator's construct and destroy functions deprecated in c++17?

问题描述

c ++ 17规范弃用了std::allocator对象的construct和destroy成员.工作组在此处，在弃用std :: allocator的冗余成员"标题下.

The c++17 specification deprecates the construct and destroy members of the std::allocator object. The working group provided rationale for deprecating other member functions here, under the heading "Deprecate the redundant members of std::allocator".

但是，他们没有具体提及为什么不赞成使用这两个成员，或者关于替换该功能的建议是什么.我假设其含义是使用std::allocator_traits::construct代替.

However they don't mention specifically why those two members are deprecated or what the recommendation is for replacing that functionality. I'm assuming the implication is to use std::allocator_traits::construct instead.

由于

由于此函数提供了自动回退到新放置的功能，因此自C ++ 11起，成员函数Construct()是可选的分配器要求.

Because this function provides the automatic fall back to placement new, the member function construct() is an optional Allocator requirement since C++11.

对于自定义分配器(例如，对于使用memalign进行页面对齐的内存)，将退回到位置new总是会产生正确的行为吗?

For custom allocators (e.g. for page-aligned memory using memalign), will falling back to placement new always produce the correct behavior?

推荐答案

分配器要求表说，construct(c, args)(如果提供)必须在c处构造C类型的对象".

The allocator requirements table says that construct(c, args), if provided, must "construct an object of type C at c".

它完全没有说1)要将什么参数传递给C的构造函数，或2)如何将这些参数传递给.那是分配器的选择，实际上，标准中的两个分配器在将参数传递给C的构造函数之前确实弄乱了参数: std::pmr::polymorphic_allocator .特别是在构造std::pair时，它们传递给pair的构造函数的参数甚至可能与接收到的参数不相似.

It says absolutely nothing about 1) what arguments are to be passed to C's constructor or 2) how these arguments are to be passed. That's the allocator's choice, and in fact two allocators in the standard do mess with the arguments before passing them to C's constructor: std::scoped_allocator_adaptor and std::pmr::polymorphic_allocator. When constructing a std::pair, in particular, the arguments they pass to pair's constructor may not even resemble the ones they received.

也不需要完全转发；如果效率不高，则使用C ++ 03样式的construct(T*, const T&).

There's no requirement to perfectly forward, either; a C++03-style construct(T*, const T&) is conforming if inefficient.

std::allocator的construct和destroy，因为它们无用:没有好的C ++ 11和更高版本的代码应该直接调用它们，并且它们在默认值之上没有添加任何内容.

std::allocator's construct and destroy are deprecated because they are useless: no good C++11 and later code should ever call them directly, and they add nothing over the default.

处理内存对齐应该是allocate的任务，而不是construct.

Handling memory alignment should be the task of allocate, not construct.

这篇关于为什么在c ++ 17中不推荐使用std :: allocator的Construct和destroy函数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！