RAII wrapper for function pairs and template specialization

Question

I've written a RAII wrapper for C function pairs which initialize and release resources and it serves me well for most cases.

#include <GL/glfw.h>
#include <string>
#include <functional>
#include <stdexcept>

template <typename UninitFuncType,
          typename SuccessValueType,
          SuccessValueType successValue>
class RAIIWrapper
{
public:
    template <typename InitFuncType, typename... Args>
    RAIIWrapper(InitFuncType initializer,
                UninitFuncType uninitializer,
                const std::string &errorString,
                const Args&... args) : 
        uninit_func(uninitializer)
    {
        if (successValue != initializer(args...))
            throw std::runtime_error(errorString);
        initialized = true;
    }

    bool isInitialized() const
    {
        return initalized;
    }

    ~RAIIWrapper()
    {
        if (initalized)
            uninit_func();
    }

    // non-copyable
    RAIIWrapper(const RAIIWrapper &) = delete;
    RAIIWrapper& operator=(const RAIIWrapper &) = delete;

private:
    bool initalized = false;
    std::function<UninitFuncType> uninit_func;
};

using GLFWSystem = RAIIWrapper<decltype(glfwTerminate), decltype(GL_TRUE), GL_TRUE>;
using GLFWWindow = RAIIWrapper<decltype(glfwCloseWindow), decltype(GL_TRUE), GL_TRUE>;

int main()
{
    GLFWSystem glfw(glfwInit,
                    glfwTerminate,
                    "Failed to initialize GLFW");
}

However, say when a function returns void like Enter/LeaveCriticalSection I'm not sure how to go about and do it in this class. Should I specialize the class for SuccessValueType = void case? Or something with default template parameter should do?

Ruth

do you need to have SuccessValueType and successValue as class template parameters? couldn't they be parameters of the constructor? then you could create two separate constructors... just thinking aloud – Emmieemmit

Wow, didn't occur to me, lemme try now :) – Ruth

@AndyProwl: Oh,wait, but that would make my caller site look ugly :( and also when the success value is known @ compile time, passing it @ runtime is unnecessary. – Ruth

How it would it look ugly? You were going to have to specify the successValue somewhere... – Demavend

that would be just one more argument, no? GL_TRUE should be enough, its type should be deduced so you won't have to specify it – Emmieemmit

Why don't you put those init and deinit functions as template parameters too? So you have a single ugly using statement once for every type but a clean instance line. – Jannery

@legends2k: conceptually I would say passing the return value when constructing each instance of the wrapper (i.e. not as a template argument of the class) makes more sense, because each instance of the same wrapper type could invoke a different initialization function and that could have a different success code – Emmieemmit

An RAII type without a user-defined copy constructor and copy assignment operator? Something smells about that. – Nonlegal

@JonathanWakely: It's not complete yet, hence it's in the wash @ SO :) – Ruth

Add deleted copy operations. – Nonlegal

@JonathanWakely: Happy now? Added 'em :) I omitted them, since they're besides the question's point. – Ruth

Overjoyed :) correct copying is always relevant to RAII – Nonlegal

You initialize uninit wrong. – Northeast

Answer 1

I'd like to note, that

1. You do not need information on your initialization function in your wrapper class. You only need to know about uninitialization function.

2. You can create function helpers to instantiate your wrapper.

I came up with the following solution (I liked @ipc exception handling idea)

template <typename UninitF>
struct RAII_wrapper_type
{
    RAII_wrapper_type(UninitF f)
    :_f(f), _empty(false)
    {}
    RAII_wrapper_type(RAII_wrapper_type&& r)
    :_f(r._f), _empty(false)
    {
      r._empty = true;
    }

    RAII_wrapper_type(const RAII_wrapper_type&) = delete;
    void operator=(const RAII_wrapper_type&) = delete;

    ~RAII_wrapper_type()
    {
      if (!_empty) {
        _f();
      }
    }

  private:
    UninitF _f;
    bool _empty; // _empty gets true when _f is `moved out` from the object.
};

template <typename InitF, typename UninitF, typename RType, typename... Args>
RAII_wrapper_type<UninitF> capture(InitF init_f, UninitF uninit_f, RType succ, 
                                   const char* error, Args... args)
{
  if(init_f(args...) != succ) {
    throw std::runtime_error(error);
  }
  return RAII_wrapper_type<UninitF>(uninit_f);
}

template<typename InitF, typename UninitF, typename... Args>
RAII_wrapper_type<UninitF> capture(InitF init_f, UninitF uninit_f, Args... args)
{
  init_f(args...);
  return RAII_wrapper_type<UninitF>(uninit_f);
}

Example:

void t_void_init(int){}
int t_int_init(){ return 1; }
void t_uninit(){}

int main()
{
  auto t1 = capture(t_void_init, t_uninit, 7);
  auto t2 = capture(t_int_init, t_uninit, 0, "some error");
}

Edit

RAII_wrapper_type should have move semantics and we should carefully implement its move constructor to prevent uninit_f from calling several times.

Barkeeper

This is nice and elegant :) I see that a simple function solves the issue here. – Ruth

Can you make this non-copyable, when I do the usual deletion of copy ctor and assignment operator functions, the compiler complains returning RAII_wrapper_type from capture, which is also a copy. – Ruth

@legends2k, I've added move issue soultion. – Barkeeper

Isn't _empty redundant? Can't you just check _f != nullptr instead? – Ruth

@legends2k, if your UninitF is actually C function pointer, it would be ok, but if it will be a functor, you wouldn't be able neither assign nullptr to it, nor compare functor with nullptr – Barkeeper

I understand functors quite well, thank you. BUT in your implementation above, assigning a nullptr to _f works, meaning the compiler deduces it as a function pointer. I tried it in both GCC and MSVC (msvc without variadic templates), it deduces the RAII_wrapper_type's template argument as a C-style function pointer. – Ruth

And this is the reason why I, in the question, have a function<T> as a member variable and use decltype to deduce the function type and NOT the function pointer type. – Ruth

@legends2k, because in an exmaple t_uninit is function. If it would be functional object, it wouldn't. – Barkeeper

Answer 2

I would seperate the logic of return-Checking and of RAII-Wrapping

template <typename UninitFuncType>
class RAIIWrapper
{
public:
  template <typename InitFuncType, typename... Args>
  RAIIWrapper(InitFuncType fpInitFunc,
              UninitFuncType fpUninitFunc,
              Args&&... args)
    : fpUninit(std::move(fpUninitFunc))
  {
    static_assert(std::is_void<decltype(fpInitFunc(args...))>::value, "ignored return value");
    fpInitFunc(std::forward<Args>(args)...);
  }

  bool isInitialized() const { return true; } // false is impossible in your implementation

  ~RAIIWrapper() { fpUninit(); } // won't be called if constructor throws

private:
  UninitFuncType fpUninit; // avoid overhead of std::function not needed
};

template <typename InitFuncType, typename UninitFuncType, typename... Args>
RAIIWrapper<UninitFuncType>
raiiWrapper(InitFuncType fpInitFunc,
            UninitFuncType fpUninitFunc,
            Args&&... args)
{
  return RAIIWrapper<typename std::decay<UninitFuncType>::type>
    (std::move(fpInitFunc), std::move(fpUninitFunc), std::forward<Args>(args)...);
}

template <typename InitFuncType, typename SuccessValueType>
struct ReturnChecker {
  InitFuncType func;
  SuccessValueType success;
  const char *errorString;
  ReturnChecker(InitFuncType func,
                SuccessValueType success,
                const char *errorString)
    : func(std::move(func)), success(std::move(success)), errorString(errorString) {}

  template <typename... Args>
  void operator()(Args&&... args)
  {
    if (func(std::forward<Args>(args)...) != success)
      throw std::runtime_error(errorString);
  }
};
template <typename InitFuncType, typename SuccessValueType,
          typename Ret = ReturnChecker<InitFuncType, SuccessValueType> >
Ret checkReturn(InitFuncType func, SuccessValueType success, const char *errorString)
{
  return Ret{func, success, errorString};
}

I also added functions to allow type deduction. Here is how to use it:

auto _ = raiiWrapper(checkReturn(glfwInit, GL_TRUE, "Failed to initialize GLFW"),
                     glfwTerminate);

Since having a function object that has a non-void return value causes the static_assert to fail, the following is impossible:

raiiWrapper(glfwInit, glfwTerminate); // fails compiling

If you really want to ignore it, you can add an ignoreReturn function object. Also note that the return code checking can be as sophisticated as you want (like success has to be an even number) since you can write your own return code checker.

Dorene

+1 for showing me that function<> isn't required and also for a good answer, I like this solution, but let's give it more time, since I still feel this could be done without decoupling the 2 operations. – Ruth

Are you sure that function is not required? I tried compiling, clang throws error: data member instantiated with function type 'void ()'. I think you intend it to be used as a function pointer i.e. UninitFuncType*. I didn't want that, hence I used function. – Ruth

Do some std::decay to fix that. – Northeast

@ipc: The functor ReturnChecker's operator() should take variable arguments; edited the answer for this. – Ruth

That could easily fixed, but I like the solution from @Barkeeper more, so use them ;) – Dorene

@ipc: Yes, I up voted it too :) But I don't just copy-pasting code, I try to it & that's why I come to SO. Could you explain the static_assert in your code? I.e. the functor's operator() will always be returning void, then why do you check it for is_void? – Ruth

@Dorene What is more queer is that I don't see the static_assert's message flagged ever by the compiler, but ideally I should see it all the time, since the return type is void all the time. – Ruth

The static_assert checks whether the return value is void, if it's not, then it fails. This is, because otherwise, raiiWrapper(glfwInit, glfwTerminate); would be valid code too. IMHO ignoring (aka forgetting to check it) such a return value is mostly an error. – Dorene

@ipc: I understand that, I guess you didn't read my comments properly. The functor ReturnChecker's operator() will always be returning void, which is actually the input for the RAIIWrapper ctor and there by to static_assert, then why do you check for it's voidness? Yes, it makes sense in the case where the caller directly calls raiiWrapper circumventing the functor. – Ruth