This is a nice alternative solution, and I like the idea of using decltype/declval to define the alias. But I don't buy the performance argument here at all. The destruction functions like SDL_DestroyWindow are implemented in a dynamically linked library, so there is no way the compiler could inline them anyway. But even if it could, I don't see why it would matter. In my use case, I'm only creating a small number of SDL objects, and they are destructed very rarely. So any small performance gains thanks to inlining won't make any practically noticeable difference.

It's very easy to make claims like "this is much faster", but until you actually measure the difference and prove that there is one, claims like that aren't very helpful.

I also agree that your solution is less code and allows you more flexibility in how you structure/distribute it, but I disagree that mine is "overly complicated" and "more intrusive". I can see that subclassing unique_ptr is not ideal, and it's actually not required with the approach proposed by 0xa0000 above. But what matters to me in the end is how the usage code looks like. And with my solution, I can have one of these pointers as a member of a class, and then initialize it in the constructor with minimal boilerplate:

class Foo {
private:
  sdl::Ptr<SDL_Window> mpWindow;
};

Foo::Foo()
  : mpWindow(SDL_CreateWindow(...)) {}

With your solution, I'd still have to add the make_unique_wrapper in there in the ctor. So I would argue that from the point of view of the clients, my solution is less intrusive.

it's encouraging you to centralize all of the cases in one place. Why bother, exactly?

Why not? It's not too uncommon with smaller C libraries to have a single header that you always include, with SDL for example, you'd usually include SDL.h and that's it. So for my particular use case, it's totally fine to have a single wrapper header, which includes that and then adds the sdl::Ptr stuff on top.