在std :: allocator中的直接vs统一初始化 [英] Direct vs uniform initialization in std::allocator

问题描述

这个问题已经提交给Usenet，在这里它更合适，但是这是一个更大，更可靠的论坛。

std :: allocator :: construct 定义为将其参数参数
pack转发给对象构造

如果使用大括号，也称为统一初始化，我们可以从函数初始化
聚合数据类型，例如 std :: make_shared 和
container :: emplace 。另外，可以将初始化器列表的内容
放入这样的函数的参数列表中，
解决 initializer_list 类型的问题

此备选方案是否被考虑并被拒绝？在未来的标准中切换
是太晚了吗？这似乎是一个突破性的变化，但
不是一个特别令人发指的变化。

解决方案

什么SC考虑，但请记住统一初始化在通用上下文中不真正工作（禁止值构造*）。考虑这个尝试：

 模板< typename T，typename ... Args> 
 T 
 make（Args& ... args）
 {
 return T {std :: forward< Args>（args）...} 
} 
  

您将获得：

  assert（make< std :: vector< int>>（10,0）.size（）== 2）; 
 assert（std :: vector< int>（10，0）.size（）== 10）; 
  

这不会编译：

  make< std :: vector< int *>>（10u，0） 
  

，但这样做：

  std :: vector< int *>（10u，0）; 
 

如果完美转发和初始化列表之间的特定交互导致这种情况很快就被正式化，我可以看到SC不想从头重新启动。

（*）： T {} 即使在通用上下文中也很好。

_{This question has also been submitted to Usenet, where it is more appropriate, but this is a larger and more reliable forum.}

std::allocator::construct is defined to forward its argument parameter pack to object construction using parentheses, a.k.a. direct-initialization.

If it used braces, a.k.a. uniform initialization, we could initialize aggregate data types from functions such as std::make_shared and container::emplace. Also, it would be acceptable to put the contents of an initializer list into the argument list of such a function, solving the problem of initializer_list type deduction under forwarding.

Was this alternative considered and rejected? Is it too late to switch in a future standard? It seems this would be a breaking change, but not a particularly heinous one.

解决方案

I don't know what the SC considered, but keep in mind that uniform initialization doesn't really 'work' in generic contexts (barring value construction*). Consider this attempt:

template<typename T, typename... Args>
T
make(Args&&... args)
{
    return T { std::forward<Args>(args)... };
}

You get:

assert( make<std::vector<int>>(10, 0).size() == 2 );
assert( std::vector<int>(10, 0).size() == 10 );

and this doesn't compile:

make<std::vector<int*>>(10u, 0);

whereas this does:

std::vector<int*>(10u, 0);

If the particular interaction between perfect forwarding and initializer lists that causes this was formalized soon enough I could see the SC not wanting to restart from scratch.

(*): T {} is fine even in generic contexts.

这篇关于在std :: allocator中的直接vs统一初始化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！