scope_exit macro

Question

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__)
#endif



namespace 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.

Answer 1

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.

Answer 2

Destructor has very dangerous behavior if anything inside of the code block may throw. Since C++11, every destructor is implicitly noexcept, thus any exception thrown will immediately call std::terminate() without any chance to recover.

The fix is simple, just modify destructor declaration:

    ~ScopeGuardOnExit() noexcept(false)
    {
        f();
    }