This library is not ideal enough. I have a better solution, which supports the anonymous guard and the named guard at the same time, plus the commit/rollback semantics:

http://4bsd.biz/post/35333867680/a-simplified-transctional-scopeguard

Maybe you should consider to follow my blog, which is

4BSD -- http://4bsd.biz/

I post cutting edge discoveries

I don't see why this is better than using std::unique_ptr with a custom deleter. Also it has the downside that it actually separates the moment of binding between the resource and its destructor.
Consider this example :

FILE *fp = fopen(argv[1], "r");
if (fp == nullptr)
return false;
defer(fclose(fp));

It's all too easy for someone to insert some lines of code above the defer(...) macro and have the function return early, never noticing that fp will leak.

FILE *fp = fopen(argv[1], "r");
if (fp == nullptr)
return false;
if (somethings_not_right_with(fp))
return false; // oops, fp leaks
defer(fclose(fp));

The unique_ptr approach does not have this problem.
struct FILE_deleter {
void operator()(FILE* fp) const {
if (fp)
fclose(fp);
}
};

std::unique_ptr<FILE, FILE_deleter> fp_handle(fopen(...));

Plus, as a bonus, it does not require ugly macros and works with non C++11 code

Christ allmighty, the formatting :((

It's not, as I pointed out in my blog. defer() is good for implementing transactional semantics; scope guarding is just one use.

BTW, unique_ptr does not support non-pointer resources, like a file descriptor.

Yes, unique_ptr is limited to pointers, but its not terribly hard to code a unique_handle that deals with non pointer resources, or find a library out there that offers it out of the box.

Note: You can put code in "pre" & "/pre" blocks.

#include <iostream>

int main() { std::cout << "Hello!" }

RAII please. I guess such macros do declare an in-scope class and a variable out of the definition, but that article for scope(exit) is just praying on the RAII principle.