Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Single-file public-domain/open source C libraries with minimal dependencies

github.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Single-file public-domain/open source C libraries with minimal dependencies

#11

Post by lifthrasiir »

chubot wrote: post #6

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 lat…

C 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.

Re: Single-file public-domain/open source C libraries with minimal dependencies

#13

Post by chubot »

mbrock wrote: post #9
chubot wrote: post #6

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 lat…

Note 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.

OK, 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.)

Re: Single-file public-domain/open source C libraries with minimal dependencies

#14

Post by pjmlp »

lifthrasiir wrote: post #11
chubot wrote: post #6

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 lat…

C 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 s…

So much that they created POSIX instead of making it part of ANSI C.

Re: Single-file public-domain/open source C libraries with minimal dependencies

#17

Post by djcapelis »

Just proposed one of my projects for inclusion: https://github.com/djcapelis/atomic-ring

Lock-free Single Producer, Single Consumer (SPSC) queue. The dependencies include C11 and that's it. No POSIX required, should work on any arch you can find a C11 compiler for.

Re: Single-file public-domain/open source C libraries with minimal dependencies

#18

Post by rat87 »

Plug for a tiny header library I wrote

https://github.com/rtaycher/debug_print_h

It's a little thing for simple printf debugging. I got tired as hell of using formatting strings. It prints line, file, and function, expression and value. Since it stands out /greppable it's easier to delete then random printfs.

It has support for different colors(to make things stand out) and uses c99 _Generic to support different types with a single "function" and c initializers for named arguments. It supports basic c types and you can sort of extend it by modyfing the header(unfortunately I couldn't find anything cleaner using c).

C99 only (works on gcc>4.9 (due to use of designated initializers) and llvm/clang >3.3 (maybe earlier but I tested it with 3.3) I was hoping to support msvc but it looks like Microsoft hasn't implemented _Generic yet.

Re: Single-file public-domain/open source C libraries with minimal dependencies

#19

Post by Turbo_hedgehog »

chubot wrote: post #6

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 lat…

> 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

Re: Single-file public-domain/open source C libraries with minimal dependencies

#20

Post by biokoda »

djcapelis wrote: post #17

Just proposed one of my projects for inclusion: https://github.com/djcapelis/atomic-ring Lock-free Single Producer, Single Consumer (SPSC) queue. The dependencies include C11 and that's it. No POSIX required, should work on any arch you can find a C11 compiler for.

If all you're doing is passing pointers from one thread to another, lock free is not a very good choice. Try a trivial spinlock based implementation. It will outperform it easily.
Post reply on HN