问题标签 [raii]

（我修改了原来的问题更有意义）

关于 return 语句，Raii 对象是否在 return 语句之前/之后/之间被销毁？

例如

谢谢你

这是好习惯吗？或者我应该只用函数替换代码块{吗}？它可能是可重用的（我承认），但我这样做的唯一动机是解除分配colsum，因为它很大而且不需要，因此我可以释放分配的内存。

我正在处理一段代码，它有许多可能的故障点，导致它提前退出函数。我正在与之交互的库要求将 C 样式的数组传递给函数。因此，我没有在每个退出点对数组调用 delete ，而是这样做：

我想使用unique_ptr，但我当前的编译器不支持它，在这种情况下引用计数开销并不重要。

我只是想知道在与遗留代码交互时是否有人对这种做法有任何想法。

更新 我完全忘记了shared_ptr调用delete而不是delete []. 我只是看到没有内存泄漏并决定使用它。甚至没有想到使用矢量。由于我最近一直在研究新的（对我而言）C++，我想我有一个案例“如果你拥有的唯一工具是锤子，那么一切看起来都像钉子”。综合征。感谢您的反馈。

UPDATE2我想我会改变这个问题并提供一个答案，让它对犯我同样错误的人更有价值。尽管有scoped_array,shared_array和之类的替代方法vector，但您可以使用 ashared_ptr来管理数组的范围（但在此之后我不知道为什么要这样做）：

我为 sqlite3 连接创建了以下类：

然后可以按如下方式初始化连接

但是，我希望能够共享此连接，将其存储为类中的成员等，而问题在于默认的赋值运算符operator=。做类似的事情

当每个变量超出范围时，将导致对数据库指针的两次 sqlite3_close 调用。当您需要将资源分配给不同的变量时，如何使用 RAII 克服这一困难？

谁能为我提供一个或多个具体示例，其中 RAII不是最有效的资源管理方法，为什么？

我在堆栈上有一个对象，我希望它的析构函数在调用析构函数时跳过一些工作，因为由于堆栈上对象的范围引发了特定异常，堆栈正在展开。

现在我可以在堆栈项的范围内添加一个 try catch 块并捕获有问题的异常并通知堆栈对象不运行要跳过的工作，然后重新抛出异常，如下所示：

但是，我希望有一种更优雅的方式来做到这一点。例如想象：

假设我有一个充当“智能指针”的类，并在销毁时释放某种系统资源。

我有一些函数返回用于初始化“资源”的值：

现在，如果我在我的代码中这样做：

AND allocateHandle()抛出异常，究竟会发生什么？崩溃会发生在 Resource() 构造期间还是构造之前？

常识告诉我，因为在 allocateHandle 返回之前抛出异常，执行甚至不会进入 Resource() 构造函数，但我不确定。这是一个正确的假设吗？

我正在尝试将RAII概念与 ofstream 对象的 STL 容器一起使用。例如：

但是，无论我如何尝试调整代码和声明，编译器总是抱怨。显然，位于流内部的 std::basic_ios 的复制构造函数是私有的。是否有任何简单的 C++/STL 解决方案可以使用 RAII 执行此操作，或者我是否需要涉及某种类型的智能指针？

注意：对象生命周期 RAII 不使用/与块范围 RAII

似乎可以使用额外的 gc 类别、短期对象（经常检查 gc 类别）、长期对象（不经常检查 gc 类别）和资源对象（非常频繁地检查 gc 类别）。或者可能为资源对象使用额外的引用计数 gc。

似乎 using/with 风格可以通过提升 I/O 的功能性风格（如果我错了，这不是功能性风格，请原谅我）阻止大量 I/O 分散在这个地方与基于对象的 RAII 的灵活性（因为它更容易）。但是有些问题可能需要很难跟踪资源的生命周期。

除了避免 gc 的复杂性和速度之外，还有其他原因没有在主流语言上完成吗？（我知道有些语言在其主要实现中使用引用计数作为 gc 的一部分，因此，RAII 可能在那里工作，但我相信他们的规范没有为某些类型的对象/或所有对象指定引用计数，并且人们使用的其他实现没有引用计数，从而限制了这些语言中对象生命周期 RAII 的使用。

PS：他们在 perl 中有 c++ 类型的 RAII 吗？

给定一个用于控制拥有项目的库的 C API，将 C API 封装到 RAII C++ 类中的最佳设计是什么？

C API 看起来像：

加上对这些类型（会话或项目）之一有用并直接映射到相关对象的 C++ 成员函数的其他函数。但这里不需要它们。我的主要兴趣是构建和销毁这些对象，使用 RAII 来管理这些类的正确打开和关闭。

我对课程设计的第一个想法是纯粹而直接的 RAII。包含的类接受一个容器对象作为构造函数参数。

这种设计的缺点是允许不良行为：一个 Session 对象可以在其所有 Item 对象被破坏之前被破坏（并调用 CloseSession 函数）。这很烦人，因为它不应该发生。即使这种错误行为是可能的，因此是无效的，使用 C API，我希望在 C++ API 中通过设计来避免它。

这就是为什么我想知道使用以下设计，其中 Session 包含其项目（这显示了实际关系），并且是唯一能够构造和销毁项目的类。

在我看来，它是确保 Session 在其 Item 关闭之前不关闭的唯一方法：在设计中反映 Item 对象是 Session 的成员，因此将在 Session 被销毁之前被销毁。

但是，它看起来有点奇怪，因为它将这些函数 OpenItem 和 CloseItem 留在了 Session 类的接口中。我一直在寻找更多 RAII 行中的东西（对我来说，这意味着使用 Item 的构造函数），但无法想象一种封装它的方法，以确保正确的销毁顺序。

此外，使用指针、new 和 delete 太过古老的世纪 C++。应该可以使用 Item 的向量（而不是 Item*），代价是正确定义 Item 类的移动语义，但代价是允许 Item 的默认构造函数创建未初始化的第二类公民 Item 对象。

有更好的设计理念吗？