5 ms·
Uh, this stb library [1] seems to follow a horrible pattern: not only combining your code into a single .c file (which is fine, like the sqlite amalgamation),
by chubot 11y ago
Uh, this stb library [1] seems to follow a horrible pattern: not only combining your code into a single .c file (which is fine, like the sqlite amalgamation), but putting the code into a single .h file. [2]
I've never seen a C or C++ codebase that does this. Maybe you can rely on link-time deduplication, but it will still cause duplicate compilation, and thus increased compile times. I haven't thought it about it lately, but I thought the common wisdom was not to depend on the linker to dedupe or strip unused symbols. Actually it should cause link-time errors, not just duplicated cause.
The justification is also somewhat ridiculous: 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.)
Really? Why not just lay out your source normally, and then munge it with a simple script into something Windows can handle (similar to sqlite)? Because writing trivial scripts on Windows is also a pain?
[1] https://github.com/nothings/stb https://github.com/nothings/stb
[2] https://github.com/nothings/stb/blob/master/stb_c_lexer.h https://github.com/nothings/stb/blob/master/stb_c_lexer.h
- mbrock 11y agoNote that the implementation code is conditionally compiled. By default you only compile the headers, so it's up to you instantiate the implementation somewhere by setting a preprocessor symbol before you include the library. This is described in the comment at the top of the file.
- chubot 11y agoOK, I missed that... it makes it a slightly less crazy pattern, but still weird and offputting. If you really have problems adding one .h and one .c file to your project, I think the development environment is broken. (Admittedly, I last used Visual Studio C++ in 2007... I installed it from a DVD, only to find it was broken, and I had to copy a .DLL from the Microsoft website to get it to work.)
- lifthrasiir 11y agoC programmers certainly hate dependencies. So much that the most extreme class cannot even tolerate multi-file external dependencies. That is really extreme, but given the history of dealing (or coping) with dependencies such paranoia is rather justified. > Why not just lay out your source normally, and then munge it with a simple script into something Windows can handle (similar to sqlite)? Because writing trivial scripts on Windows is also a pain? Instead of making a big library with multiple files, they took an alternative to make a small well-defined library with a single file and small number of entry points.
- pjmlp 11y agoSo much that they created POSIX instead of making it part of ANSI C.
- Turbo_hedgehog 11y ago> I've never seen a C or C++ codebase that does this. One example I've seen in the wild https://github.com/dtschump/CImg https://github.com/dtschump/CImg
- fsloth 11y agoIn general, I find the stb libraries practical and technically excellent. I can't see how they could be improved by arbitratily splitting it into a header and c-file. Best practices are best practises within a specific usage domain. Sometimes the best solution to particular problem constraints is not the one that follows an orthodoxy. "it will still cause duplicate compilation" No, there is nothing in general that would cause this. The implementation is written behind a specific preprocessor condition which is not supposed to be a project wide definition. For example user can write one stb-*-impl.c file that includes the header after the library specific preprocessor definiton.
- jblow 11y agoOn the contrary, this is the best way to make code reusable, because it is the only way that allows a C or C++ program to add more code solely via the compiler, without also requiring modification of external build scripts / tools / etc. When you are shipping and maintaining code on 5 or 10 different platforms, this really matters, because the friction of adding new files becomes huge ... you have to go add that file to 5 or 10 different fuckity fuck build systems that are all uniquely terrible, and hey maybe Apple updated XCode to whatever the new lousy version is instead of the old lousy version, so you have to go through the rigamarole of installing that, which of course won't completely work, oh and the internet is slow today, and on some console platform that shall not be named our dev software didn't auto-renew its license and that is mysteriously timing out so now we get to deal with that for hours, blah blah blah. This is not an exaggeration. You're lucky if you actually get to do any programming on the day you decide to add a cpp file. Experienced programmers who ship on a lot of platforms really want the simplest and most straightforward way of using code, and this is what that is for C and C++. More modern languages could be designed to be better at this, but they usually aren't. (A 'package manager' is not really the answer, it is a solution to a kind-of orthogonal problem and usually brings in way too many of its own complexities.)