This is actually not something new, but I think many people wanted something useful and not incredibly complicated. So, here it is:#pragma once#include <utility>#define concat_impl(x, y) x##y#define concat(x, y) concat_impl(x, y)#ifdef __COUNTER__#define ANONYMOUS_VARIABLE(NAME) concat(NAME, __COUNTER__)#else#define ANONYMOUS_VARIABLE(NAME) concat(NAME, __LINE__)#endifnamespace detail{    template <typename Func>    class ScopeGuardOnExit    {        Func f;    public:        ScopeGuardOnExit(Func&& f) :            f(std::forward<Func>(f))        {}        ~ScopeGuardOnExit()        {            f();        }    };    struct dummy {};    template <typename Func>    ScopeGuardOnExit<Func> operator+(dummy, Func&& f)    {        return std::forward<Func>(f);    }}#define scope_exit \    auto ANONYMOUS_VARIABLE(SCOPE_EXIT_WHATEVER) = ::detail::dummy() + [&]()Usage:#include scope_exit.hpp#include <iostream>int f(){    scope_exit {std::cout << exiting f()\n;};    return 0;}int main(){    f();    scope_exit {std::cout << It's working!\n;};}Do note that the lambda takes (pulls into abyss) everything by reference. On top of that, it is possible to register multiple function to execute at exit. Is it possible to make it more user friendly? The best would be to try to write it using templates.By being more user friendly I mean eliminating that SCOPE_EXIT_WHATEVERN variable from the variable list for the current scope, because people will get surprised when they will see it in an IDE. Also, forgetting semicolon ; will lead to pretty confusing error messages.
scope_exit macro
c++;c++14;macros;scope
Between operator+ and the constructor of ScopeGuardOnExit, you twice move-construct an object of the lambda type. In Auto() I deliberately avoided any move-constructions in favor of just storing a reference to the original lambda; if I recall correctly, that was because I had found that GCC had a hard time optimizing away those move-constructions (even though the lambda object doesn't contain any data members except references, which are trivially moveable and thus ought to be easy to optimize away).However, I've just now tried to construct a test case where scope_exit's assembly output differs (at -O2 or higher) from Auto's, and failed to come up with any actual differences; so I think your move-construction-based version is safe in practice.