RAII无法真正保证防止资源泄漏,可以吗？

Question

请原谅我这个问题太傻了.使用RAII最有用的例子是:

void func(){
  // create some object pointer using any smart pointer
  // do some operation that may throw

  return;
}
// whether method returns from the *return* statement or because of any exception it is guaranteed that the memory will be released

本文说(如果我理解正确),如果运行时系统知道没有异常处理程序可以在抛出后捕获异常, 它可能会跳过调用自动对象的析构函数.

还有一个建议解决这一问题,即使用catch(..)在main.

现在我担心的是如果不使用所提出的解决方案,那么即使在使用RAII之后也可能存在资源泄漏.并且存在无法应用解决方案的情况(例如创建将由其他人使用的库).在这种情况下,可能会发生严重问题,例如破坏包含有价值信息的文件.

我们真的应该关注这个问题吗？或者我只是错过了一些东西？

Answer 1

为了使您的关注有效,您需要某种可以由RAII清理的资源,但是在调用并且您的进程终止时操作系统将无法清理std::terminate.

那么,让我们检查一下你可以合理使用RAII来清理的资源:

1. 进程本地内存:操作系统将清理它
2. 打开文件:操作系统将关闭它们,并刷新已写入的任何内容,但是您留给RAII dtor的任何提交/完成样式操作都不会发生
3. 打开套接字:操作系统将关闭它们,但是如果你的RAII dtor应该发送一个友好的注销/再见,那就不会发生
4. 共享内存:同样,将释放操作系统级资源,但不会执行任何显式清理或一致性代码
5. 等等(特别是,Alf提出了一些我没想过的外部可见资源)

因此,问题通常不是通常由操作系统发布的资源,而是语义,其中您的RAII dtor应该保证共享资源(共享内存,文件或网络流)的某些干净状态.

我们真的应该关注这个问题吗？

好吧,无论如何我们应该关注正确的程序语义.如果您的程序有一些需要保证的外部副作用,那么保证RAII清理的全部(至少在相关代码周围)是最简单的问题.

Answer 2

关于

“我们真的应该关心这个问题吗？”

这取决于具体情况。

如果您使用析构函数断点或登录调试，则需要调用相关的析构函数。同样，如果析构函数正在为崩溃后重新实例化的“凤凰鸟”进程保存关键状态。如果可能的话，最好删除不需要恢复的临时文件，而不是在崩溃后闲置。

另一方面，由于解决方案非常简单 -try围绕catch一些调用代码，例如 up in main- 这并不是一个真正的实际问题。这不仅仅是一件需要注意的事情。例如，不要期望析构函数一定会在其他因未处理的异常而崩溃的代码中执行。