13

我有一个带有已删除移动构造函数的类，当我尝试在 MSVC（v.15.8.7 Visual C++ 2017）中调用 std::vector::push_back() 时，我收到一条错误消息，提示我正在尝试访问已删除的移动构造函数。但是，如果我定义了移动构造函数，则代码会编译，但永远不会调用移动构造函数。两个版本都可以在 gcc (v. 5.4) 上按预期编译和运行。

这是一个简化的示例：

#include <iostream>
#include <vector>

struct A
{
public:
    A() { std::cout << "ctor-dflt" << std::endl; }
    A(const A&) { std::cout << "ctor-copy" << std::endl; }
    A& operator=(const A&) { std::cout << "asgn-copy" << std::endl; return *this; }
    A(A&&) = delete;
    A& operator=(A&& other) = delete;
    ~A() { std::cout << "dtor" << std::endl; }
};


int main()
{
    std::vector<A> v{};
    A a;
    v.push_back(a);
}

在 Visual Studio 上编译时会出现以下错误：

error C2280: 'A::A(A &&)': attempting to reference a deleted function

但是，如果我定义移动构造函数而不是删除它

 A(A&&) { std::cout << "ctor-move" << std::endl; }

一切都编译并运行，输出如下：

ctor-dflt
ctor-copy
dtor
dtor

正如预期的那样。不调用移动构造函数。（实时代码：https ://rextester.com/XWWA51341 ）

此外，这两个版本都在 gcc 上运行良好。（实时代码：https ://rextester.com/FMQERO10656 ）

所以我的问题是，为什么对不可移动对象的 std::vector::push_back() 调用不能在 MSVC 中编译，即使显然从未调用过移动构造函数？

4

2 回答 2

6

这是未定义的行为，因此 gcc 和 MSVC 都是正确的。

我最近在推特上发布了关于使用 std::vector::emplace_back 的类似案例，该案例的类型具有已删除的移动构造函数，就像这个一样，它是未定义的行为。所以这里所有的编译器都是正确的，未定义的行为不需要诊断，尽管实现可以自由地这样做。

我们可以从[container.requirements.general] 表 88开始，它告诉我们push_back需要TCopyInsertable ：

要求：T 应可 CopyInsertable 到 x

我们可以看到CopyInsertable需要MoveInsertable [container.requirements#general]p15：

T is CopyInsertable into X 意味着，除了 T 是 MoveInsertable into X...

在这种情况下A不是MoveInsertable。

我们可以通过在[res.on.required]p1处查看这是未定义的行为：

违反函数的 Requires: 段落中指定的先决条件会导致未定义的行为，除非函数的 Throws: 段落指定在违反先决条件时引发异常。

[res.on.required]属于Library-wide requirements。

在这种情况下，我们没有 throws 段落，因此我们有未定义的行为，这不需要诊断，正如我们从其定义中看到的那样：

本国际标准没有要求的行为......

请注意，这与需要诊断的格式错误非常不同，我在此处的答案中解释了所有细节。

于 2018-10-23T15:56:57.890 回答
4

std::vector<T>::push_back()需要T满足MoveInsertable概念（实际上涉及分配器Alloc）。这是因为push_back在向量上可能需要增长向量，移动（或复制）已经在其中的所有元素。

如果您将 move c'tor 声明T为已删除，则至少对于默认分配器 ( std::allocator<T>)，T不再是MoveInsertable。请注意，这与未声明移动构造函数的情况不同，例如，因为只能隐式生成一个复制 c'tor，或者因为只声明了一个复制 c'tor，在这种情况下，类型仍然是MoveInsertable，但实际上调用了 copy c'tor（这有点违反直觉 TBH）。

从未实际调用 move c'tor 的原因是您只插入一个元素，因此在运行时不需要移动现有元素。重要的是，您对自身的论点push_back是一个左值，因此在任何情况下都被复制而不是移动。

更新：我不得不更仔细地查看这个（感谢评论中的反馈）。拒绝代码的 MSVC 版本实际上这样做是正确的（显然，2015 年和 2018 年之前都这样做，但 2017 年接受代码）。既然你打电话push_back(const T&)，T就必须是CopyInsertable。但是，CopyInsertable被定义为MoveInsertable的严格子集。由于您的类型不是MoveInsertable，因此根据定义，它也不是CopyInsertable（请注意，如上所述，类型可能同时满足这两个概念，即使它只是可复制的，只要未明确删除 move c'tor ） .

当然，这引发了更多问题：(A) 为什么 GCC、Clang 和某些版本的 MSVC 无论如何都接受代码，以及 (B) 他们这样做是否违反了标准？

至于 (A)，除了与标准库开发人员交谈或查看源代码外，没有其他方法可以知道……我的快速猜测是，如果您只关心制作合法程序，则根本没有必要执行此检查工作。push_back根据标准，在 a （或 a等）期间重新定位现有元素reserve可以通过以下三种方式中的任何一种发生：

  • 如果std::is_nothrow_move_constructible_v<T>，则元素不会被移动（并且该操作是异常安全的）。
  • 否则，如果T是CopyInsertable，则复制元素（并且该操作是高度异常安全的）。
  • 否则，元素将被移动（并且未指定在 move c'tor 中引发的异常的影响）。

由于您的类型不是 nothrow move c'tible，而是有一个复制 c'tor，因此可以选择第二个选项。这是宽松的，因为没有检查MoveInsertable。这可能是实施疏忽，或者我可能被故意忽略。（如果类型不是MoveInsertable，那么整个调用是格式错误的，因此这个缺失的检查不会影响格式正确的程序。）

至于 (B)，IMO 接受代码的实现违反了标准，因为它们没有发出诊断信息。这是因为除非标准中另有说明，否则需要实现来为格式错误的程序（这包括使用实现提供的语言扩展的程序）发出诊断信息，这两种情况都不是。

于 2018-10-23T09:41:58.337 回答