23

在我看来,当移动构造函数为 noexcept(false) 时,标准库必须调用复制构造函数而不是移动构造函数似乎是一致的。

现在我不明白为什么会这样。而且更多的 Visual Studio VC v140 和 gcc v 4.9.2 似乎以不同的方式做到了这一点。

我不明白为什么 noexcept 这是例如向量的问题。我的意思是如果 T 没有,vector::resize() 应该如何提供强大的异常保证。正如我所看到的,向量的异常级别将取决于 T。无论使用复制还是移动。我理解 noexcept 只是对编译器进行异常处理优化的一个眨眼。

这个小程序在使用 gcc 编译时调用复制构造函数,在使用 Visual Studio 编译时调用移动构造函数。

include <iostream>
#include <vector>

struct foo {
  foo() {}
  //    foo( const foo & ) noexcept { std::cout << "copy\n"; }
  //    foo( foo && ) noexcept { std::cout << "move\n"; }
  foo( const foo & )  { std::cout << "copy\n"; }
  foo( foo && )  { std::cout << "move\n"; }

  ~foo() noexcept {}
};

int main() {
    std::vector< foo > v;
    for ( int i = 0; i < 3; ++i ) v.emplace_back();
}
4

2 回答 2

44

这是一个多方面的问题,所以在我讨论各个方面时请耐心等待。

标准库期望所有用户类型始终提供基本的异常保证。该保证表明,当抛出异常时,所涉及的对象仍处于有效(如果未知)状态,没有资源泄漏,没有违反基本语言不变量,并且没有发生远距离的诡异动作(最后一个不是正式定义的一部分,但它实际上是一个隐含的假设)。

考虑类 Foo 的复制构造函数:

Foo(const Foo& o);

如果这个构造函数抛出,基本的异常保证会给你以下知识:

  • 没有创建新对象。如果构造函数抛出,则不会创建对象。
  • o没有被修改。它在这里唯一的参与是通过一个 const 引用,所以它不能被修改。其他情况属于“远处的幽灵行动”标题,或者可能是“基本语言不变”。
  • 没有资源泄露,整个程序仍然连贯。

在移动构造函数中:

Foo(Foo&& o);

基本保证提供的保证较少。o可以修改,因为它是通过非常量引用涉及的,所以它可以处于任何状态。

接下来看vector::resize。它的实现通常会遵循相同的方案:

void vector<T, A>::resize(std::size_t newSize) {
  if (newSize == size()) return;
  if (newSize < size()) makeSmaller(newSize);
  else if (newSize <= capacity()) makeBiggerSimple(newSize);
  else makeBiggerComplicated(newSize);
}
void vector<T, A>::makeBiggerComplicated(std::size_t newSize) {
  auto newMemory = allocateNewMemory(newSize);
  constructAdditionalElements(newMemory, size(), newSize);
  transferExistingElements(newMemory);
  replaceInternalBuffer(newMemory, newSize);
}

这里的关键功能是transferExistingElements。如果我们只使用复制,它有一个简单的保证:它不能修改源缓冲区。因此,如果在任何时候操作抛出,我们可以销毁新创建的对象(请记住,标准库绝对不能使用抛出析构函数),丢弃新缓冲区,然后重新抛出。矢量看起来好像从未被修改过。这意味着我们有强保证,即使元素的复制构造函数只提供弱保证。

但是如果我们使用移动来代替,这是行不通的。一旦一个对象被移出,任何后续异常都意味着源缓冲区已更改。而且因为我们不能保证向后移动的物体也不会抛出,我们甚至无法恢复。因此,为了保持强保证,我们必须要求移动操作不抛出任何异常。如果我们有这个,我们很好。这就是我们拥有move_if_noexcept.

至于 MSVC 和 GCC 之间的区别:MSVC 仅支持noexcept14 版,并且由于仍在开发中,我怀疑标准库尚未更新以利用它。

于 2015-02-20T11:21:17.970 回答
20

核心问题是不可能通过抛出移动构造函数提供强大的异常安全性。想象一下,如果在向量调整大小中,将元素移动到新缓冲区的中途,移动构造函数会抛出。你怎么可能恢复以前的状态?您不能再次使用移动构造函数,因为那可能会继续抛出。

复制工作是为了强大的异常安全保证,不管它是抛出性质,因为原始状态没有损坏,所以如果你不能构建整个新状态,你可以清理部分构建的状态然后你就完成了,因为旧的状态还在这里等着你。移动构造器不提供这个安全网。

基本上不可能通过抛出动作提供强异常安全的 resize() ,但使用抛出副本很容易。这个基本事实在标准库中无处不在。

GCC 和 VS 对此的处理方式不同,因为它们处于不同的一致性阶段。VS 已经noexcept成为他们实现的最后一个特性之一,因此它们的行为介于 C++03 的行为和 C++11/14 的行为之间。特别是,由于他们无法判断您的移动构造函数是否实际noexcept存在,因此他们基本上只需要猜测。从记忆中,他们简单地假设这是noexcept因为抛出移动构造函数并不常见,并且无法移动将是一个关键问题。

于 2015-02-20T11:20:19.557 回答