问题标签 [exception-safety]

在Effective C++ 3/E中，我读到：

这是异常不安全的代码：

因为编译器可以这样实现：

1. 跑new Test
2. call bar() <--如果bar()抛出异常，Test分配者的对象new Test不能被删除。
3. 调用构造函数std::shared_ptr<Test>
4. 称呼foo()

但是在这种情况下，编译器可以知道存在内存泄漏。delete如果抛出异常，编译器不能自动执行吗？

此外，delete在这种情况下，编译器会自动执行：

是这样实现的：

1. 调用operator new分配内存
2. 调用构造函数Test。如果构造函数抛出异常，内存会被自动删除。

为什么编译器在第一种情况下不做，不像第二种情况？

我正在使用此代码发布一个事件：

QCoreApplication::postEvent 在这里描述。但是，如果在 postEvent 中引发异常，绝对没有关于我应该做什么的信息。

我想这个函数属于这四个类别之一：

1. 它从不抛出异常（特别是没有 std::bad_alloc ）
2. 如果它抛出它永远不会删除事件。
3. 如果它抛出它有时会删除事件。
4. 如果它抛出它总是会删除事件。

最坏的情况是第三种情况。

那么：如果 postEvent 抛出，我是否需要删除事件？

在亚伯拉罕斯创建的异常安全中，我们有三个保证：基本、强和不抛出保证。我可以说，如果我有一个代码库使用 nothrow 表示“new”并且 noexcept 表示方法签名，那么我有 no-throw 保证吗？

谢谢。

我有一个函数可以对作为接收器参数传入的大量数据进行操作。我的BigData类型已经支持 C++11，并带有功能齐全的移动构造函数和移动赋值实现，因此我无需复制该死的东西就可以逃脱：

这一切都很好。但是，我的处理功能可能会在运行时偶尔失败，从而导致异常。这不是一个真正的问题，因为我可以修复一些东西并重试：

当然，这是行不通的。

由于我将数据移动到处理函数中，当我到达异常处理程序时，b将不再可用。

这可能会大大降低我按价值传递接收器参数的热情。

那么问题来了：如何在现代 C++ 代码中处理这样的情况？如何检索对先前移动到无法执行的函数中的数据的访问？

您可以随意更改两者的实现和BigData接口processBigData。然而，最终的解决方案应该尽量减少原始代码在效率和可用性方面的缺陷。

好的，所以我想我了解 RAII。我想我也知道异常安全是什么。

为了符合 RAII，并试图使我的代码更加安全，我试图从我的 cMain 类中删除一个错误余量。之前，它会有一个 cD3D 类型的普通私有成员，然后在创建我的 HWND 对象后，我将在 cMain 的构造函数中调用 Initialize(HWND) on。

当然，这在某种程度上违背了 RAII 的观点，因为 cD3D 被定义为

（我已经修剪了一些其他成员，因为它们与此查询无关）

cMain 的构造如下：

从而在构造 cMain 时为 m_d3d 获取资源。然后单独调用初始化。我不喜欢这个并且从来没有，因为它留下了一个想法，即在某个地方有人可能会忘记初始化一个对象，因此可能会引发异常。在这种情况下，它并不是特别糟糕，因为我确保它在任何事情发生之前都已经完成，但我经常担心添加检查以确保在使用对象之前对其进行初始化。我还私有化了默认构造函数和复制构造函数，所以不能使用它们，以确保使对象始终正确初始化它。

然后我将其更改为以下内容：

出于某种原因，这感觉更安全，除了新的 cD3D(m_hWnd) 和取消引用它。

这是 RAII 的正确做法吗？为其他课程这样做是否应该减少我对异常的暴露？除此之外，我不得不改变 cD3D 在 cMain 中的存储方式，因为我使 cD3D 的复制构造函数无法访问（出于相同的原因），因此不得不改变

至

我知道这是一个愚蠢的问题，但我是否朝着正确的方向前进？我正在学习很多新技能，以确保这款游戏从一开始就写得很好

我在哪里可以找到有关 DirectX 11 API 中不同方法的异常安全级别的文档？

在下面的代码中，作者指出new operator函数调用可能会导致异常，因此此实现不是异常安全的，因为对象状态已在第一行中更改。

在阅读时，我想知道 C 库函数是否会在 C++ 中引发异常？我知道 C 中没有异常，但是由于我们使用的是 C++ 编译器，因此可能会有异常。

那么，我们可以将 c 标准库函数视为异常安全函数调用吗？

谢谢你。

顺便说一句，为了记录，实现上述功能的正确方法（异常安全）如下。

我一直在阅读GOTW102，并且想知道为什么make_unique比其他情况更安全，或者详细说明为什么f(new T(...))比f(new T1(...), new T2(...)).

博客中的make_unique实现如下：

现在我想知道f(new T(...))在一般情况下是否是异常安全的（无泄漏），或者它是否只是make_unique由于构造函数std::unique_ptr不会抛出的附加知识而导致的异常安全？（因为如果T按照我的理解，新构建的无论如何都会泄漏。

到目前为止，每个查看的范围守卫都有一个守卫布尔变量。例如，请参阅此讨论： 最简单和最整洁的 c++11 ScopeGuard

但是一个简单的守卫工作（gcc 4.9，clang 3.6.0）：

为什么没有临时副本被破坏？依赖这种行为有危险吗？

让我们问一下这个简单的范围保护：

在这里依靠破坏令安全吗？即是否可以安全地假设~finop_t()将在 lambda 析构函数之前调用？