为什么emplace_back()不使用统一初始化?

HC4*_*ica 61 c++ vector uniform-initialization c++11

以下代码:

#include <vector>

struct S
{
    int x, y;
};

int main()
{
    std::vector<S> v;
    v.emplace_back(0, 0);
}
Run Code Online (Sandbox Code Playgroud)

使用GCC编译时出现以下错误:

In file included from c++/4.7.0/i686-pc-linux-gnu/bits/c++allocator.h:34:0,
                 from c++/4.7.0/bits/allocator.h:48,
                 from c++/4.7.0/vector:62,
                 from test.cpp:1:
c++/4.7.0/ext/new_allocator.h: In instantiation of 'void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = S; _Args = {int, int}; _Tp = S]':
c++/4.7.0/bits/alloc_traits.h:265:4:   required from 'static typename std::enable_if<std::allocator_traits<_Alloc>::__construct_helper<_Tp, _Args>::value, void>::type std::allocator_traits<_Alloc>::_S_construct(_Alloc&, _Tp*, _Args&& ...) [with _Tp = S; _Args = {int, int}; _Alloc = std::allocator<S>; typename std::enable_if<std::allocator_traits<_Alloc>::__construct_helper<_Tp, _Args>::value, void>::type = void]'
c++/4.7.0/bits/alloc_traits.h:402:4:   required from 'static void std::allocator_traits<_Alloc>::construct(_Alloc&, _Tp*, _Args&& ...) [with _Tp = S; _Args = {int, int}; _Alloc = std::allocator<S>]'
c++/4.7.0/bits/vector.tcc:97:6:   required from 'void std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {int, int}; _Tp = S; _Alloc = std::allocator<S>]'
test.cpp:11:24:   required from here
c++/4.7.0/ext/new_allocator.h:110:4: error: new initializer expression list treated as compound expression [-fpermissive]
c++/4.7.0/ext/new_allocator.h:110:4: error: no matching function for call to 'S::S(int)'
c++/4.7.0/ext/new_allocator.h:110:4: note: candidates are:
test.cpp:3:8: note: S::S()
test.cpp:3:8: note:   candidate expects 0 arguments, 1 provided
test.cpp:3:8: note: constexpr S::S(const S&)
test.cpp:3:8: note:   no known conversion for argument 1 from 'int' to 'const S&'
test.cpp:3:8: note: constexpr S::S(S&&)
test.cpp:3:8: note:   no known conversion for argument 1 from 'int' to 'S&&'
Run Code Online (Sandbox Code Playgroud)

建议vector使用常规()构造函数语法从参数构造元素emplace_back().为什么不vector使用{}统一初始化语法来制作像上面那样的例子?

在我看来,通过使用{}它没有什么可失去的(当有一个时它会调用构造函数,但是当没有一个时它仍然可以工作),并且它将更多地符合C++ 11的精神{}- 之后所有,统一初始化的全部意义在于它统一使用 - 即无处不在 - 来初始化对象.

Pot*_*ter 52

伟大的思想相似; v).我提交了一份缺陷报告,并建议对此主题的标准进行更改.

http://cplusplus.github.com/LWG/lwg-active.html#2089

此外,Luc Danton帮助我理解了难度:std :: allocator中的直接与统一初始化.

当EmplaceConstructible(23.2.1 [container.requirements.general]/13)要求用于初始化对象时,会发生直接初始化.初始化聚合或使用带有emplace的std :: initializer_list构造函数需要命名初始化类型并移动临时类型.这是使用直接初始化而不是列表初始化(有时称为"统一初始化")语法的std :: allocator :: construct的结果.

改变std :: allocator :: construct以使用列表初始化会优先考虑std :: initializer_list构造函数重载,以非直观和不可修复的方式破坏有效代码 - emplace_back无法访问构造函数被std :: initializer_list抢占而基本上没有重新实现push_back.

std::vector<std::vector<int>> v;
v.emplace_back(3, 4); // v[0] == {4, 4, 4}, not {3, 4} as in list-initialization
Run Code Online (Sandbox Code Playgroud)

建议的折衷方案是使用带有std :: is_constructible的SFINAE,它测试直接初始化是否形成良好.如果is_constructible为false,则选择使用列表初始化的备用std :: allocator :: construct重载.由于列表初始化始终依赖于直接初始化,因此用户将看到诊断消息,就像始终使用列表初始化(统一初始化)一样,因为直接初始化过载不会失败.

我可以看到两个角落案例,揭示了这个方案中的空白.当用于std :: initializer_list的参数满足构造函数时会出现这种情况,例如在上面的示例中尝试插入值{3,4}.解决方法是显式指定std :: initializer_list类型,如v.emplace_back(std :: initializer_list(3,4)).由于这与语义匹配,好像推断了std :: initializer_list,因此这里似乎没有真正的问题.

另一种情况是,用于聚合初始化的参数满足构造函数.由于聚合不能具有用户定义的构造函数,因此这要求聚合的第一个非静态数据成员可以从聚合类型隐式转换,并且初始化列表具有一个元素.解决方法是为第二个成员提供初始化程序.通过从可转换为聚合类型的类型转换,就不可能就地只构建一个只有一个非静态数据成员的聚合.这似乎是一个可以接受的小洞.

  • @ JohannesSchaub-litb:恕我直言,这更像是`std :: initializer_list`应该是什么.但是对`std :: allocator`的简单修改应该可以解决问题. (4认同)
  • 人们可以发明一种语言支持类型来完美地转发语法括号初始列表.然后可以说emplace_back({a,b,...}) (2认同)
  • @ JohannesSchaub-litb进驻的力量在于创造不是MoveConstructible的对象.为什么能够放置容器很重要?同样,请记住`initializer_list`也不可移动,并且总是进行复制. (2认同)
  • 如果这适用于聚合,那就太好了。谢谢你的努力。作为更新,以下是自上述评论以来发生的事情:_[2015-02 Cologne] 转到 EWG,Ville 撰写论文。[**2015-09**, Telecom] **Ville: [N4462](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4462.html)** 审查在莱内萨。**EWG 讨论将在科纳继续**。[**2016-08** Chicago] 参见 N4462 Lenexa 的注释说 **Marshall &amp; Jonathan 自愿就此写一篇论文**_ (2认同)
  • 进一步更新:**[P0960](http://wg21.link/p0960)**现已包含在 C++20 工作草案中! (2认同)