c++支持“finally”块吗?
RAII习语是什么?
c++的RAII习语和c#的using语句有什么区别?
当前回答
不，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习语更准确的名称。
其他回答
我想出了一个finally宏，可以像¹Java中的finally关键字一样使用;它使用std::exception_ptr及其友项，lambda函数和std::promise，因此它要求c++ 11或以上;它还使用了clang也支持的复合语句表达式GCC扩展。
警告:这个答案的早期版本使用了这个概念的不同实现，有更多的限制。
首先，让我们定义一个helper类。
#include <future>
template <typename Fun>
class FinallyHelper {
template <typename T> struct TypeWrapper {};
using Return = typename std::result_of<Fun()>::type;
public:
FinallyHelper(Fun body) {
try {
execute(TypeWrapper<Return>(), body);
}
catch(...) {
m_promise.set_exception(std::current_exception());
}
}
Return get() {
return m_promise.get_future().get();
}
private:
template <typename T>
void execute(T, Fun body) {
m_promise.set_value(body());
}
void execute(TypeWrapper<void>, Fun body) {
body();
}
std::promise<Return> m_promise;
};
template <typename Fun>
FinallyHelper<Fun> make_finally_helper(Fun body) {
return FinallyHelper<Fun>(body);
}
然后是实际的宏观。
#define try_with_finally for(auto __finally_helper = make_finally_helper([&] { try
#define finally }); \
true; \
({return __finally_helper.get();})) \
/***/
它可以这样使用:
void test() {
try_with_finally {
raise_exception();
}
catch(const my_exception1&) {
/*...*/
}
catch(const my_exception2&) {
/*...*/
}
finally {
clean_it_all_up();
}
}
使用std::promise使其非常容易实现，但它可能也引入了相当多不必要的开销，这些开销可以通过只从std::promise中重新实现所需的功能来避免。
注意:有一些东西不像java版本的finally那样工作。我能想到的是:
it's not possible to break from an outer loop with the break statement from within the try and catch()'s blocks, since they live within a lambda function; there must be at least one catch() block after the try: it's a C++ requirement; if the function has a return value other than void but there's no return within the try and catch()'s blocks, compilation will fail because the finally macro will expand to code that will want to return a void. This could be, err, avoided by having a finally_noreturn macro of sorts.
总而言之，我不知道我自己是否会使用这些东西，但玩它很有趣。：）
总之，微软Visual c++确实支持try，它在MFC应用中一直被用作捕获严重异常的方法，否则会导致崩溃。例如;
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}
在过去，我用它来做一些事情，比如在退出之前保存打开文件的备份。不过，某些JIT调试设置会破坏这种机制。
很抱歉挖了这么老的一个线程，但下面的推理有一个重大错误:
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++中，由于RAII, final是不需要的。
RAII将异常安全的责任从对象的用户转移到对象的设计者(和实现者)。我认为这是正确的地方，因为你只需要让异常安全正确一次(在设计/实现中)。通过使用finally，您需要在每次使用对象时都获得正确的异常安全性。
在我看来，代码看起来更整洁了(见下文)。
例子:
一个数据库对象。为了确保使用了DB连接，必须打开并关闭它。通过使用RAII，这可以在构造函数/析构函数中完成。
C+像火车
void someFunc()
{
DB db("DBDesciptionString");
// Use the db object.
} // db goes out of scope and destructor closes the connection.
// This happens even in the presence of exceptions.
RAII的使用使得正确使用DB对象变得非常容易。DB对象将通过使用析构函数正确地关闭自身，无论我们如何尝试和滥用它。
Java终于来了
void someFunc()
{
DB db = new DB("DBDesciptionString");
try
{
// Use the db object.
}
finally
{
// Can not rely on finaliser.
// So we must explicitly close the connection.
try
{
db.close();
}
catch(Throwable e)
{
/* Ignore */
// Make sure not to throw exception if one is already propagating.
}
}
}
当最终使用对象时，对象的正确使用委托给对象的用户。例如，正确地显式地关闭DB连接是对象用户的责任。现在，您可能会认为这可以在终结器中完成，但资源可能有有限的可用性或其他约束，因此您通常希望控制对象的释放，而不是依赖于垃圾收集器的非确定性行为。
这也是一个简单的例子。 当需要释放多个资源时，代码可能会变得复杂。
更详细的分析可以在这里找到:http://accu.org/index.php/journals/236
为什么即使是托管语言也会提供final块，尽管垃圾收集器会自动释放资源?
实际上，基于垃圾收集器的语言需要更多的“finally”。垃圾收集器不会及时销毁您的对象，因此不能依赖它正确地清理与内存无关的问题。
就动态分配数据而言，许多人认为应该使用智能指针。
然而……
RAII将异常安全的责任从对象的用户转移到设计人员
可悲的是，这是它自己的失败。旧的C编程习惯很难改掉。当您使用用C或非常C风格编写的库时，将不会使用RAII。除了重写整个API前端，这就是你必须要处理的。那么，“终于”这个词的缺失真的很伤人。
