The std::function<void(char*)> is the tell :-)

Why do you think that marks a troll? Have you never had to use a C library which wants you to use the library's structure allocator / deallocator? In that case, this translates very well to malloc/dealloc.

@unlinked_dll has it correct: the C++ way to allocate an array of chars is `std::vector<char>` (or `std::array<char, size>`).

It's a bit bloaty and verbose as well, you could just use void(&)(void *).

Doesn't that break when std::free does not have the default C++ calling convention? I think `decltype(std::free)` would be easier to read anyway, but writing a deleter class that calls std::free in its operator() has the advantage that it will not use any memory in the unique_ptr thanks to the empty base class optimization.

I don't think that's possible, and in that case the std::function wouldn't work either.

I was thinking about calling conventions because std::free can use extern "C", but the function pointer declaration in C++ code points to an extern "C++" function, and the standard says these are two distinctive types. Are they guaranteed to be compatible - since they're only linkage specifiers, not calling conventions? I'm not sure.

std::function would still work in this case because pointers to C functions have a normal operator().

Oh, right, it would work. Anyway, it looks like compilers have a known bug and they’re supposed to treat the types as incompatible.