If I understand correctly you still have to write something like

    template<typename... Arguments> auto make_window(Arguments&&... args)
    {
        return detail::make_resource(SDL_CreateWindow, SDL_DestroyWindow, std::forward<Arguments>(args)...);
    }

for each resource.

Quite honestly at that point I'd sooner use a good old variadic macro, C99 style. I mean, sure, it's arguably less "elegant" and C++-ish but it'll be easier to understand, to maintain and won't spam me with pages of arcane template errors when I forget a colon somewhere, so it'll be easier to debug as well.

That's the double edged sword of the C++ template system I suppose, in order to gain in purity they lost the simplicity of the C macro system without gaining the expressiveness and convenience of the Lisp macro system. In the end, what percentage of C++ coders use templates outside of the STL you think?

The C++ template will give you extra type checking that the varadic macro won't, which is worth the tradeoff for the obscure error messages for me.

(At least the errors have got slightly better in recent g++ releases with colourised error output.)

> If I understand correctly you still have to write something like

You don't have to, you can create further helper function calling the generic thing but it's optional.

The code that makes use of templates and such is meant to be library code in the same way that STL is, not something the average user interacts with other than to know they need to pass an Init and Destroy function followed by initialization parameters. I don't see people tearing apart <tuple>'s code because of its complexity, or <vector> or any other reusable STL component that most developers who've complained about the verbosity of my solution use every day without batting an eye.

In these proposed solutions I've not yet seen one that has the capability to do this:

    auto window = make_resource(SDL_CreateWindow, SDL_DestroyWindow, ....);

With my solution all you have to do is call make resource with different parameters it automatically works with other C style init/destroy created resources, not just from the SDL library but any C library that follows that practice.

Can you try posting what your solution to the general problem would look like?

The thing is, you're going to be wrapping in a class anyways, so why not move all the nonsense into a normal destructor and then use normal smart pointers?

I suggest that this is somewhat solving the wrong problem.

This, and also it would bother me a lot to know that I'm essentially re-implementing what is already available in the standard library.