From the popular (in game development circles, at least) stb libraries:
>Why single-file headers?
>Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)
>There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.
>Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)
>Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.
How does header-only versus header+impl file have anything to do with deploying libraries? Versus a separate header + DLL, sure. But having an impl file isn't gonna matter if you link it all in. This sounds more like a source-vs-bin issue. What am I missing?
Worth noting that only the first two points there are relevant here, since these are not single file libraries. Also, the STB libraries work massively differently from C++ header only libs (#define STB_FOO_IMPLEMENTATION, for example).
Also, fwiw Sean Barrett also has gone on record as saying that he's not really a fan of C++ before. I'm struggling to find a specific link, but it's not really a secret.
(As a side note, to anybody who is in the need for what they do, the STB libraries are really absurdly high quality and can do exactly what you want them to 99% of the time. Highly recommend!!)
> Windows doesn't have standard directories where libraries live.
Visual Studio certainly does:
Microsoft Visual Studio 11.0\VC\include
Many people argue don't put libraries there - well then you are back to the original problem. Just as long as you don't overwrite a provided library - there are no issues. And if you do overwrite it - you get a rolled up newspaper and start beating the person who overwrote it.
It's a different directory for every version of Visual Studio (and obviously mingw doesn't use it), ergo it's not a standard directory like /usr/include
His point is that it's arguably simpler to tell people to copy a single source file to their project's source tree, than it is to help them find the include dir for whatever compiler they happen to be using. And that it's probably easier to have to manually update this file when the library is patched, than it is to coordinate manual library updates across an entire team without the use of a package manager.
>Why single-file headers?
>Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)
>There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.
>Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)
>Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.
https://github.com/nothings/stb/