c++支持“finally”块吗?
RAII习语是什么?
c++的RAII习语和c#的using语句有什么区别?
当前回答
正如许多人所说，解决方案是使用c++ 11的特性来避免最终阻塞。其中一个特性是unique_ptr。
以下是Mephane使用RAII模式编写的答案。
#include <vector>
#include <memory>
#include <list>
using namespace std;
class Foo
{
...
};
void DoStuff(vector<string> input)
{
list<unique_ptr<Foo> > myList;
for (int i = 0; i < input.size(); ++i)
{
myList.push_back(unique_ptr<Foo>(new Foo(input[i])));
}
DoSomeStuff(myList);
}
这里有更多关于在c++标准库容器中使用unique_ptr的介绍
其他回答
很抱歉挖了这么老的一个线程，但下面的推理有一个重大错误:
RAII将异常安全的责任从对象的用户转移到对象的设计者(和实现者)。我认为这是正确的地方，因为你只需要让异常安全正确一次(在设计/实现中)。通过使用finally，您需要在每次使用对象时都获得正确的异常安全性。
通常情况下，你必须处理动态分配的对象，动态数量的对象等。在try块中，一些代码可能会创建许多对象(有多少是在运行时确定的)，并将指向它们的指针存储在一个列表中。现在，这不是一个奇异的场景，但很常见。在这种情况下，你会想写这样的东西
void DoStuff(vector<string> input)
{
list<Foo*> myList;
try
{
for (int i = 0; i < input.size(); ++i)
{
Foo* tmp = new Foo(input[i]);
if (!tmp)
throw;
myList.push_back(tmp);
}
DoSomeStuff(myList);
}
finally
{
while (!myList.empty())
{
delete myList.back();
myList.pop_back();
}
}
}
当然，当超出作用域时，列表本身将被销毁，但这不会清除您创建的临时对象。
相反，你必须走一条丑陋的路:
void DoStuff(vector<string> input)
{
list<Foo*> myList;
try
{
for (int i = 0; i < input.size(); ++i)
{
Foo* tmp = new Foo(input[i]);
if (!tmp)
throw;
myList.push_back(tmp);
}
DoSomeStuff(myList);
}
catch(...)
{
}
while (!myList.empty())
{
delete myList.back();
myList.pop_back();
}
}
另外:为什么即使是托管语言也会提供一个final块，尽管垃圾收集器会自动释放资源?
提示:使用“finally”可以做的不仅仅是内存释放。
我有一个用例，我认为它最终应该是c++ 11语言中完全可以接受的一部分，因为我认为从流的角度来看，它更容易阅读。我的用例是线程的消费者/生产者链，其中在运行结束时发送一个哨兵nullptr以关闭所有线程。
如果c++支持它，你会希望你的代码看起来像这样:
extern Queue downstream, upstream;
int Example()
{
try
{
while(!ExitRequested())
{
X* x = upstream.pop();
if (!x) break;
x->doSomething();
downstream.push(x);
}
}
finally {
downstream.push(nullptr);
}
}
我认为把finally声明放在循环的开始更符合逻辑，因为它发生在循环退出之后……但这只是一厢情愿的想法，因为我们无法在c++中实现它。注意，下游队列连接到另一个线程，所以你不能在下游的析构函数中放入哨兵推(nullptr)，因为此时它不能被销毁……它需要保持活动状态，直到另一个线程接收到nullptr。
下面是如何使用带有lambda的RAII类来做同样的事情:
class Finally
{
public:
Finally(std::function<void(void)> callback) : callback_(callback)
{
}
~Finally()
{
callback_();
}
std::function<void(void)> callback_;
};
下面是你如何使用它:
extern Queue downstream, upstream;
int Example()
{
Finally atEnd([](){
downstream.push(nullptr);
});
while(!ExitRequested())
{
X* x = upstream.pop();
if (!x) break;
x->doSomething();
downstream.push(x);
}
}
不一定，但你可以在一定程度上模仿他们，例如:
int * array = new int[10000000];
try {
// Some code that can throw exceptions
// ...
throw std::exception();
// ...
} catch (...) {
// The finally-block (if an exception is thrown)
delete[] array;
// re-throw the exception.
throw;
}
// The finally-block (if no exception was thrown)
delete[] array;
注意，final -block本身可能在原始异常被重新抛出之前抛出一个异常，从而丢弃原始异常。这与Java final -block中的行为完全相同。同样，你不能在try&catch块中使用return。
RAII通常更好，但在c++中可以很容易地获得finally语义。使用少量的代码。
此外，c++核心指南最后给出了。
这里有一个到GSL微软实现的链接和一个到Martin Moene实现的链接
Bjarne Stroustrup多次表示，GSL中的所有内容最终都将被纳入标准。所以它最终应该是一种经得起考验的使用方式。
如果你想，你可以很容易地实现自己，继续阅读。
在c++ 11中RAII和lambdas允许做出一般的最后:
namespace detail { //adapt to your "private" namespace
template <typename F>
struct FinalAction {
FinalAction(F f) : clean_{f} {}
~FinalAction() { if(enabled_) clean_(); }
void disable() { enabled_ = false; };
private:
F clean_;
bool enabled_{true}; }; }
template <typename F>
detail::FinalAction<F> finally(F f) {
return detail::FinalAction<F>(f); }
使用示例:
#include <iostream>
int main() {
int* a = new int;
auto delete_a = finally([a] { delete a; std::cout << "leaving the block, deleting a!\n"; });
std::cout << "doing something ...\n"; }
输出将是:
doing something...
leaving the block, deleting a!
就我个人而言，我多次使用这个方法来确保在c++程序中关闭POSIX文件描述符。
有一个真正的类来管理资源，从而避免任何类型的泄漏通常是更好的，但这最终是有用的情况下，使一个类听起来有点多余。
此外，我喜欢它胜过其他语言，因为如果自然地使用它，你可以在开始代码附近编写结束代码(在我的例子中是new和delete)，并且在c++中按照后进先出(LIFO)的顺序进行构造。唯一的缺点是你得到了一个你并不真正使用的auto变量，lambda语法使它有点嘈杂(在我的例子中，在第四行中，只有单词finally和右边的{}块是有意义的，其余的基本上都是嘈杂的)。
另一个例子:
[...]
auto precision = std::cout.precision();
auto set_precision_back = finally( [precision, &std::cout]() { std::cout << std::setprecision(precision); } );
std::cout << std::setprecision(3);
如果只有在失败的情况下才必须调用finally，则disable成员非常有用。例如，你必须在三个不同的容器中复制一个对象，你可以设置finally来撤销每次复制，并在所有复制成功后禁用。这样做，如果破坏不能扔，你就保证了强有力的保证。
禁用的例子:
//strong guarantee
void copy_to_all(BIGobj const& a) {
first_.push_back(a);
auto undo_first_push = finally([first_&] { first_.pop_back(); });
second_.push_back(a);
auto undo_second_push = finally([second_&] { second_.pop_back(); });
third_.push_back(a);
//no necessary, put just to make easier to add containers in the future
auto undo_third_push = finally([third_&] { third_.pop_back(); });
undo_first_push.disable();
undo_second_push.disable();
undo_third_push.disable(); }
如果你不能使用c++ 11，你仍然可以使用，但是代码会变得有点冗长。只需定义一个只有构造函数和析构函数的结构，构造函数引用所需的任何内容，而析构函数执行所需的操作。这就是lambda的作用，手动完成。
#include <iostream>
int main() {
int* a = new int;
struct Delete_a_t {
Delete_a_t(int* p) : p_(p) {}
~Delete_a_t() { delete p_; std::cout << "leaving the block, deleting a!\n"; }
int* p_;
} delete_a(a);
std::cout << "doing something ...\n"; }
希望你能使用c++ 11，这段代码更多地是为了表明“c++最终不支持”是如何从c++的最初几周开始就毫无意义的，甚至在c++得到它的名字之前就可以编写这种代码。
不，c++不支持'finally'块。原因是c++支持RAII:“资源获取是初始化”——对于一个真正有用的概念来说，这是一个糟糕的名字。
其思想是，对象的析构函数负责释放资源。当对象具有自动存储持续时间时，当创建对象的块退出时，对象的析构函数将被调用——即使该块在出现异常时退出。以下是Bjarne Stroustrup对这个话题的解释。
RAII的一个常见用途是锁定互斥量:
// A class with implements RAII
class lock
{
mutex &m_;
public:
lock(mutex &m)
: m_(m)
{
m.acquire();
}
~lock()
{
m_.release();
}
};
// A class which uses 'mutex' and 'lock' objects
class foo
{
mutex mutex_; // mutex for locking 'foo' object
public:
void bar()
{
lock scopeLock(mutex_); // lock object.
foobar(); // an operation which may throw an exception
// scopeLock will be destructed even if an exception
// occurs, which will release the mutex and allow
// other functions to lock the object and run.
}
};
RAII also simplifies using objects as members of other classes. When the owning class' is destructed, the resource managed by the RAII class gets released because the destructor for the RAII-managed class gets called as a result. This means that when you use RAII for all members in a class that manage resources, you can get away with using a very simple, maybe even the default, destructor for the owner class since it doesn't need to manually manage its member resource lifetimes. (Thanks to Mike B for pointing this out.)
For those familliar with C# or VB.NET, you may recognize that RAII is similar to .NET deterministic destruction using IDisposable and 'using' statements. Indeed, the two methods are very similar. The main difference is that RAII will deterministically release any type of resource -- including memory. When implementing IDisposable in .NET (even the .NET language C++/CLI), resources will be deterministically released except for memory. In .NET, memory is not deterministically released; memory is only released during garbage collection cycles.
†有些人认为“破坏是资源放弃”是RAII习语更准确的名称。
