Mostly related: https://github.com/blanham/PDCLib
Not one file but public domain and a great project :)
Single-file public-domain/open source C libraries with minimal dependencies
31–40 of 51 posts
Re: Single-file public-domain/open source C libraries with minimal dependencies
#32Why isn't SQLite's amalgamated build on this list? Come on. I don't understand this. Can someone explain it to me?
> The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3, FTS5, RTREE, DBSTAT, JSON1, and RBU extensions. This file contains about 184K lines of code (113K if you omit blank lines and comments) and is over 6.4 megabytes in size. Though the the various extensions are included in the "sqlite3.c" amalgamation file, they are disabled using #ifdef sta…
In other words, it's stretching the definition of "single file" a bit... but then again, I don't know any other SQL databases anywhere near as small as SQLite.
Re: Single-file public-domain/open source C libraries with minimal dependencies
#33Shameless plug: I also maintain a few small single-file C libs at https://dev.yorhel.nl/ylib And, separately, a small-single-file-but-correct XML parser: https://dev.yorhel.nl/yxml
[deleted]
Re: Single-file public-domain/open source C libraries with minimal dependencies
#34Earlier quoted context omitted.
I strongly doubt you're going to build a faster thread-safe workqueue by adding spinlocks to it, but if you think what I wrote is too slow, feel free to build something faster and show the speed difference in a benchmark. You can use the code in test/ if you'd like. The code I wrote does leave an optimization or two on the table. Apple's lockfree queue in GCD is faster than mine because of batching. It also has a ton…
Locking is cheap, switching a pointer around is cheap. The only expensive thing is waking up a thread that is waiting on a lock. Spinlocks avoid that problem, which is why they outperform other implementations in terms of throughput (of course inversely proportional to the amount of work you do during a lock). Atomic operations have a fixed cost. Spinlocks only really have a cost when contention is high. When you're…
You are making a big assumption that threads will be woken up in the first place.
Also when it comes to concurrency it is all about scaling, and whatever scales will perform better as there are more cores.
Re: Single-file public-domain/open source C libraries with minimal dependencies
#35Earlier quoted context omitted.
Locking is cheap, switching a pointer around is cheap. The only expensive thing is waking up a thread that is waiting on a lock. Spinlocks avoid that problem, which is why they outperform other implementations in terms of throughput (of course inversely proportional to the amount of work you do during a lock). Atomic operations have a fixed cost. Spinlocks only really have a cost when contention is high. When you're…
You are making a big assumption that threads will be woken up in the first place. Also when it comes to concurrency it is all about scaling, and whatever scales will perform better as there are more cores.
I never said spinlocks are better in every situation. I'm saying they are better in this situation (SPSC queue).
Re: Single-file public-domain/open source C libraries with minimal dependencies
#36Just proposed two of my C projects for inclusion:
TinyExpr - evaluate math from string - https://github.com/codeplea/tinyexpr
minctest - very minimal C unit tests - https://github.com/codeplea/minctest
TinyExpr is a single source file + header, while minctest is a single header. Both are zlib licensed.
Also, I'd appreciate feedback if anyone is interested.
Re: Single-file public-domain/open source C libraries with minimal dependencies
#37Another good source of small utility libraries is CCAN.
List of available modules: https://ccodearchive.net/list.html
Re: Single-file public-domain/open source C libraries with minimal dependencies
#38Uh, 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 lat…
On 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.)
Re: Single-file public-domain/open source C libraries with minimal dependencies
#39Earlier quoted context omitted.
I strongly doubt you're going to build a faster thread-safe workqueue by adding spinlocks to it, but if you think what I wrote is too slow, feel free to build something faster and show the speed difference in a benchmark. You can use the code in test/ if you'd like. The code I wrote does leave an optimization or two on the table. Apple's lockfree queue in GCD is faster than mine because of batching. It also has a ton…
Locking is cheap, switching a pointer around is cheap. The only expensive thing is waking up a thread that is waiting on a lock. Spinlocks avoid that problem, which is why they outperform other implementations in terms of throughput (of course inversely proportional to the amount of work you do during a lock). Atomic operations have a fixed cost. Spinlocks only really have a cost when contention is high. When you're…
> Atomic operations have a fixed cost. Spinlocks only really have a cost when contention is high.
You're making it sound like spinlocks don't need atomic operations. I'm pretty sure locking a spinlock requires an atomic operation.
Re: Single-file public-domain/open source C libraries with minimal dependencies
#40Why isn't SQLite's amalgamated build on this list? Come on. I don't understand this. Can someone explain it to me?
Yeah I think that's rather silly, both the lack of an explanation and the implied reason if we guessed it correctly (thanks for making us guess and have this hypothetical discussion).
Being single file is about simplified project management. How is the file size relevant?