问题标签 [noexcept]

在实现非抛出交换习语时，我应该使用throw()?

特别是我担心将throw()规范放在std::swap.

奖励问题：
使用 C++0x 的noexcept关键字时答案是否不同？

在浏览C++0x 工作草案的最后一次编辑时，我发现了很多

• 删除关键字noexcept
• 添加文本抛出：在同一个地方没有任何东西

反之亦然。只是一些例子：

• 替换noexcept反对抛出：没有：20.6.4指针安全[util.dynamic.safety] template<class T> T*undeclare_reachable(T*p);
• 添加noexcept：20.6.3.2。指针特征成员函数 [pointer.traits.functions]：static pointer pointer_trait<T*>::pointer_to(...) noexcept;

这里的问题：

• 是否有一般规则/模式，什么时候我们会发现noexceptvs. Throws： Std-Lib 中什么都没有？
• 用户是否应该根据给定的规则得出特定的行为？即他们何时应该或不应该添加noexcept到自己的功能？

我读到有关过度使用noexcept可能会阻碍可测试库的担忧。

考虑：

使用noexcept编译器的注释可能会优化异常代码，这将/可能阻止正确处理assert()（或作者想要在此处用于他的测试的任何函数）。

因此，我想知道，在库中从不使用无条件noexcept但始终将其与 am-I-in-a-test-condition“链接”是否可行。像这样：

然后可能将其添加为宏（尽管我讨厌那样）：

你怎么看？这有任何意义吗？还是不可行？还是不能解决问题？或者根本没有问题？:-)

在此示例代码中：

这里的使用noexcept正确吗？wstring可以潜在地在构造中抛出，但是抛出是在我们在构造函数之前还是在我们在构造函数中时发生？

编辑：假设这可以推广到任何采用按值参数的函数。

想象一下，我正在编写一些容器模板或其他东西。是时候专攻std::swap它了。作为一个好公民，我将通过执行以下操作来启用 ADL：

这是非常整洁的。直到我想添加一个异常规范。我swap的 isnoexcept只要交换为Tis noexcept。所以，我会写这样的东西：

问题是，swap其中需要发现 ADLswap或std::swap. 我该如何处理？

函数类型定义中是否接受 noexcept 说明符？

如：

直观地说， noexcept 说明符似乎是有意义的，因为它们允许在调用方进行一些优化。

我从 gcc 4.6.1 得到了一个混合的答案。

导致：错误：使用异常规范声明的“fptr”

但：

编译没有警告。

关于是否允许抛出移动构造函数/赋值，我一直在阅读一些相互矛盾的文章。

因此我想问是否允许移动构造函数/赋值在最终的 C++11 标准中抛出？

这个问题是"Constructor with by-value parameter & noexcept" 的对偶。该问题表明，按值函数参数的生命周期管理由调用函数处理；因此调用者处理发生的任何异常，并且被调用函数可以标记自己noexcept。我想知道如何处理输出端noexcept。

假设返回值在MyFunction. 假设适当的特殊成员函数（复制/移动分配/构造）MyType 可能不是noexcept.

1. 关于将返回值从被调用函数传输到调用者的 RVO/NRVO/Whatever-from-C++11 规则是否意味着无论noexcept相应的特殊成员函数的状态如何，传输总是成功不抛出？
2. 如果上一个问题的答案是“否”，那么如果返回值传输抛出异常，该异常是否计入被调用函数或调用者？
3. 如果上一个问题的答案是“被调用函数”，那么简单的noexcept标记 onMyFunction将导致调用std::terminate. MyFunction的noexcept个人资料应该改成什么？当我在 Usenet 上询问这个问题时，一位受访者认为应该是std::is_nothrow_move_assignable<MyType>::value. （请注意，MyCaller使用了几种使用返回值的方法，但MyFunction不知道正在使用哪一种！答案必须涵盖所有情况。）如果MyType更改为可复制但不可移动，是否会有所不同？

noexcept因此，如果第二个和第三个问题的最坏情况是准确的，那么如果返回类型具有可抛出的移动，则任何按值返回的函数都不能有一个平原！现在具有可抛出动作的类型应该很少见，但模板代码仍然必须在is_nothrow_move_assignable每次使用按值返回时“弄脏”自己。

我认为让被调用函数负责是坏的：

至少对我来说，这个问题在调用者端似乎是可以解决的（只需用try/包装移动分配catch），但从被调用函数端无法解决。我认为调用者必须处理这个问题，即使我们需要更改 C++ 的规则来这样做。或者至少需要某种缺陷报告。

我目前正试图了解 noexcept （就像几乎所有我避免使用旧的“运行时异常规范”的人一样）。虽然我认为我了解了 noexcept 的基本概念，但我不确定在以下情况下会发生什么：

将 sample::operator- 声明为 noexcept 是否安全？（考虑到它在返回时调用构造函数）

编辑：我更新了代码部分，因为问题的中心部分似乎不清楚......</p>

可能重复：
C++11 功能检查

我对noexcept随着 GCC 4.7 的引入似乎在 C++11 标准库中乱扔垃圾的规范案例特别感兴趣。在这种情况下，检测编译器版本就足够了；这是生成可移植代码的最佳机制吗？