问题标签 [noexcept]

在具有标准容器成员的类上实现移动操作的惯用方式不能noexcept也因此不能通过诸如vector.push_back(). 还是我弄错了？

从

我们鼓励进行移动操作noexcept——因此在向量调整大小期间，库可以安全地将元素移动到重新分配的存储中。

到目前为止一切顺利，现在我elem的 s 可以更快地推回。

但是：如果我添加一个容器作为成员，我的班级仍然可以标记为 noexcept-move 吗？所有标准容器都没有它们的动作noexcept！

这也意味着，我们也不能依赖编译器生成的移动操作，对吧？下面的完整类也不会有noexcept-move-operations，因此不是“快”的，对吗？

也许vector<int>移动起来有点太简单了，但是呢vector<Elem>？

这将对所有以容器为成员的数据结构产生重大影响。

在 c++11中使用NON NOEXCEPT移动构造函数有什么实际理由吗？

因为，std::vector如果声明为 ，则使用移动构造函数noexcep，但我无法想象使用非 noexcept 移动构造函数有什么实际意义。

我从我的状态机中调用了很多外部函数——显式喜欢sendMessage(...)或隐式喜欢a!=b。到目前为止，我一直试图跟踪可以抛出的东西，但随着数量的增长，对更好方法的需求也在增加。错过一个异常并让它传播到状态机框架的代码中显然会造成很多混乱。

我看到了三个选项，但我希望有人能指出一个更好的选项：

1. try catch在每个onEntry和onExit处放置一个action。由于它们有很多而且它们很漂亮，这几乎会使代码长度增加一倍并降低可读性。

2. 做一大堆功能noexcept。如果函数在其他地方使用，或者它可以合法地抛出并且异常是唯一好的解决方案，这似乎是不可能的。

3. 修改我调用的大多数函数以使用 alexandrescuExpected<T>作为返回类型。请参阅：http ://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C

哪个选项最好？有没有更好的策略？

据我所知，SO 社区在声明一个函数是否noexcept能够实现有意义的编译器优化方面存在分歧，而这在其他情况下是不可能的。（我说的是编译器优化，而不是基于move_if_noexcept. 有了这个假设，声明函数noexcept有意义吗？假设这些函数实际上是内联的，这似乎要求编译器在调用站点的函数产生的代码周围生成等效的块，因为如果该区域出现异常，则必须调用。没有inlinenoexcepttryinlineterminatenoexcept，该try块似乎是不必要的。

我最初的兴趣是声明 Lambda 函数是否有意义noexcept，因为它们是隐式的inline，但后来我意识到任何inline函数都会出现同样的问题，而不仅仅是 Lambda。

In More Effective C++, Scott Meyers says

C++ specifies that an object thrown as an exception is copied.

I suppose then, that if the copy constructor throws an exception in turn, std::terminate is called, so this is a good reason for declaring all my exceptions' copy constructors noexcept (and also, I guess, to not throw objects which allocate memory from the heap, like std::string).

Yet I was surprised to see that the standard library implementation shipped with GCC 4.7.1 doesn’t define those copy constructor for std::bad_alloc and std::exception. Shouldn’t they define them noexcept?

在 C++11 和草案 C++14 中，解引用运算符 (operator*和operator->)shared_ptr都是noexcept. 但是对于unique_ptr,operator->是noexcept, 但operator*不是。为什么不是operator*for unique_ptr noexcept（或者，为什么是operator*for shared_ptr noexcept）？

最近我试图回答一个我认为是关于异常规范的简单问题。noexcept最终的结果是我发现我的基本理解noexcept是错误的。

在阅读当前的标准草案以纠正我的误解时，我发现自己问了一些关于这里noexcept没有回答的问题。

1. 应该noexcept被认为是一种安全保证，即调用时的函数不仅不会抛出而且不会破坏状态吗？
2. 假设 (1.) 是错误的：使用noexcept可移植的FailFast来终止应用程序而不进行清理以防止损坏保存状态是否正确？

对（2.）的澄清：目的只是为了防止析构函数从堆栈进一步向上调用，而noexcept不是防止在其中展开。这是基于这样的假设，即这是一个完美的 RAII 环境，并且堆栈上的析构函数可以将全局状态刷新到持久性，从而破坏它。

不执行展开的示例：

的工作示例noexcept

此代码在 clang(3.4) 下编译，但不在 gcc (4.7.1) 下编译。谁能告诉我我做错了什么？

编辑

gcc 错误信息是：

我在尝试保持原子时间点时遇到了这个问题，请参阅（如果默认构造函数可用，原子需要 noexcept 默认构造函数）： http ://cplusplus.github.io/LWG/lwg-active.html#2165

简单的问题是 std::atomic 或类似的将无法在当前 std 下编译。

考虑到 std::chrono::clock_type::now() 没有例外。时间点本身并非如此，这似乎很奇怪。

从N3797 开始，C++ 标准要求swap容器的函数不抛出任何异常，除非另有说明[container.requirements.general]（23.2.1§10）。

• 为什么swap指定不抛出的成员函数没有声明noexcept？

_{同样的问题也适用于专门的非成员swap重载。}