Wrapping C functions in auto objects without code duplication

Question

In C++03, when you were to wrap a bunch of C functions in a class to create an 'auto object', you had to customize the object to the type of functions it encapsulated. As an example, to wrap a windows file HANDLE, you needed to call CloseHandle() in the destructor and CreateFile() in the constructor. The constructor would need to mimic the function signature of the CreateFile() function, sans the file HANDLE variable (since it's being managed).

Anyway, what I'd like to know is if it's possible to use the new features of C++11 to create a single generic class that can be used to wrap any type of resource by only providing an implementation for creation and deletion?

One problem I foresee is that the creation function, such as noted above with CreateFile(), can taken any number of parameters. Is there a way to auto-magically generate a templated constructor that mimics the signature of the function? Variadic Parameters come to mind, but I have not yet used them.

Has anyone tried writing something like this?

EDIT: Some code to help illustrate (pseudo):

template<typename Res, FunctionPtrToCreatorFunc Func, typename... Arguments>
class creator
{
public:
  operator()(Res &r, Arguments... Args)
  {
    Func(r, /*use args?*/ Args); // Allocate resource, ie. CreateFile(r, args)
  }
};

template<typename Res, FunctionPtrToDeleterFunc Func>
class deleter
{
  operator()(Res &r)
  {
    Func(r); // delete the resource, ie. CloseHandle(r)
  }
};

Then this will be the implementation of my super auto object:

template<typename Res, typename Creator, typename Deleter>
class auto_obj
{
public:

  auto_obj(/*somehow copy Args from Creator class?*/)
  {
    Creator(_res, /*args?*/);
  }

  ~auto_obj()
  {
    deleter(_res);
  }

  Res _res;
};

Yes, this has a similar structure to shared_ptr or unique_ptr, but instead the constructor will be the one that creates the resources by developer written creator and deleter classes. I have a feeling that std::bind may play a role in this, but I have never used it.

Answer 1

Here is a stab at it:

#include <utility>
#include <type_traits>
#include <cstddef>

A more friendly way to wrap up a function. I move the signature boilerplate to this template, instead of messing up the actual RAII class below. This also allows full fledged function objects to be used, as well as functions, in the RAII class below:

template< typename FuncSig, FuncSig func >
struct Functor {
  template<typename... Args>
  auto operator()(Args&&... args) const
  -> decltype( func(std::forward<Args>(args)...) )
    { return ( func(std::forward<Args>(args)...) ); }
};

One operation that is needed for more than basic functionality is the ability to "null" a handle, allowing invalid handles to exist, and allowing handles to be moved around. Zeroer is my default function object for "null"ing a handle:

struct Zeroer {
  template<typename T>
  void operator()( T& t ) const {
    t = 0;
  }
};

RAII_handle herself. You pack the creation and destruction signatures into it, and it forwards construction to the underlying data. .close() lets you close the RAII_handle early, which is a common requirement in practice. You access the underlying data via operator* or operator->, and while this makes it look pointer-like, RAII_handle does not obey pointer semantics. It is a move-only type.

template< typename T, typename Creator, typename Destroyer, typename Nuller=Zeroer >
struct RAII_handle {
  RAII_handle( std::nullptr_t ):
    data()
  {
    Nuller()(data);
  }
  RAII_handle( RAII_handle const& ) = delete;
  RAII_handle( RAII_handle && o ):data(std::move(o.data)) {
    Nuller()(o.data);
  }
  RAII_handle& operator=( RAII_handle const& ) = delete;
  RAII_handle& operator=( RAII_handle && o ) {
    data = std::move(o.data);
    Nuller()(o.data);
    return *this;
  }
  template<typename... Args>
  RAII_handle( Args&&... args ):
    data( Creator()(std::forward<Args>(args)...) )
  {}
  auto close()->decltype( Destroyer()(std::declval<T&>()) ) {
    auto retval = Destroyer()(data);
    Nuller()(data);
    return retval;
  }
  ~RAII_handle() {
    close();
  }
  T& get() { return data; }
  T const& get() const { return data; }

  T& operator*() { return get(); }
  T const& operator*() const { return get(); }

  T* operator->() { return &get(); }
  T const* operator->() const { return &get(); }
private:
  T data;
};

Now, some test code. My file handles will be unsigned char, and opening/closing will simply test if things are not working right.

#include <iostream>
typedef unsigned char HANDLE;
HANDLE CreateFile( char const* name ) {
  std::cout << name << "\n";
  return 7;
}
bool CloseFile( HANDLE h ) {
  if (h) {
    --h;
    std::cout << (int)h << "\n";
    return true;
  } else {
    std::cout << "already closed\n";
    return true;
  }
}

Once you have your open/close functions or function objects, here is how you make the type of the FileHandle:

typedef RAII_handle< HANDLE, Functor< HANDLE(*)( char const* ), CreateFile >, Functor< bool(*)(HANDLE), CloseFile > > FileHandle;

You can support entire overload sets by simply creating a function object that forwards to a fixed function name, instead of to a fixed function pointer. Basically take Functor above, remove the template signature and pointer, and replace the use of func with actual use of your function name.

Suddenly your function object represents not calling one function, but calling an entire overload set.

Fancier work can even support multiple functions, allowing one function object to support calling either CreateFile or CreateFileEx depending on what arguments are passed in.

And here is our trivial test code:

int main() {
  FileHandle bob("hello.txt");
  HANDLE value = *bob; // get the HANDLE out of the FileHandle
  bob.close(); // optional, to close early
}

Requirements: your CloseFile must accept Nuller()(std::declval<T&>()) and not behave badly. The default Nuller()(...) just assigns zero to your T, which works for many handle types.

It supports move semantics, allowing you to return these from a function, but I didn't include a Copier argument (which I'd expect would be required for any RAII objects that can be copied).

Live example with very slightly different code.