What everybody seems to miss (including in the other comments here) is the fact that no kind of hackery with destructors will ever make them equivalent to scope(exit) or finally{}, because of the simple reason that destructors invoked via exceptions can't throw their own exceptions. And this makes sense, because destructors are meant to <i>release resources</i>, whereas finally/scope(exit) are meant to <i>execute after prior operations in a LIFO manner</i>. Not all operations that need to occur in a LIFO manner are inherently tied to resource acquisition. More fundamentally, one is inherently about data, and the other is inherently about control-flow... simply put, they're different tools with different use cases, even though people don't bother to make the distinction. Nevertheless, if people insist on using the same hammer for both nails, the language needs to address this fundamental issue before people can claim it's possible to do scope(exit) or the equivalent in C++.
This type of construct is unnecessary in C++11; the presence of RAII containers and structures totally obviates it. C++ provides a language-level construct for logic performed at the end of object lifetime (i.e., when value types fall out of scope or when heap-allocated objects are deleted): the destructor!<p>This person is describing an error-prone reimplementation of std::unique_ptr with a custom deleter. I could understand the value of an article like this if the use of C++11 were not allowed, but given that the article is written with C++11 in mind, I fear the author has totally missed the point of RAII-style resource management that the newer language-level constructs provide.<p>Deterministic destruction and associated logic, as well as the RAII strategies that follow, are perhaps the greatest strength of C++. Languages like Rust have gone on to improve this even further by eliminating some of the greatest sources of error. Capabilities like this don't seem accurately described as C++ learning from D; indeed, if D provides hooks for running logic when names fall out of scope, that seems more accurately described as vice versa.
It's nice to see some D ideas make it into C++.<p>I think that D is kind of like Mercurial: both less popular than some other wildly popular alternative, but we still hope that at least some of their ideas trickle back into the more popular sibling.
This is pretty similar to std::lock_guard (and similar RAII types). Except instead of unlocking (or tearing down a resource, etc.) upon destruction, it invokes a lambda.
The site doesn't load for me. Here's an archived copy:<p><a href="https://archive.is/srQvw" rel="nofollow">https://archive.is/srQvw</a>
You can do the same thing with no C++11 features other than C99 variadic macros. (IMO cleaner, too).<p><pre><code> #define SCOPE_EXIT(...)\
struct SE##__LINE__##_{~SE##__LINE__##_(){__VA_ARGS__;}}se##__LINE__##_</code></pre>