pottery
sc
pottery | sc | |
---|---|---|
14 | 17 | |
119 | 2,168 | |
- | - | |
1.8 | 6.3 | |
about 2 years ago | about 1 month ago | |
C | C | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pottery
-
Popular Data Structure Libraries in C ?
Pottery - The page for open hash map reads "Documentation still needs to be written. In the meantime check out the examples."
-
So what's the best data structures and algorithms library for C?
"Using macros" is a broad description that covers multiple paradigms. There are libraries that use macros in combination with typed pointers and functions that take void* parameters to provide some degree of API genericity and type safety at the same time (e.g. stb_ds and, as you mentioned, my own CC). There are libraries that use macros (or #include directives) to manually instantiate templates (e.g. STC, M*LIB, and Pottery). And then there are libraries that are implemented entirely or almost entirely as macros (e.g. uthash).
-
Better C Generics: The Extendible _Generic
The prototype of CC used this mechanism to provide a generic API for types instantiated via templates (so basically like other container libraries, but with an extendible-_Generic-based API laid over the top of the generated types). This approach has some significant advantages over the approach CC now uses, but I got a bit obsessed with eliminating the need to manually instantiate templates.
- C_dictionary: A simple dynamically typed and sized hashmap in C - feedback welcome
-
Common libraries and data structures for C
I think it's common for C programmers to roll their own. I did the same [0].
I went pretty deep into composable C templates to build mine so it's more powerful than most. The containers can handle non-bitwise-movable types with full C++-style lifecycle functions and such, and the sort algorithms can handle dynamic and non-contiguous arrays (they are powerful enough to implement qsort() [1], which is more than I can say for any other C sort templates I've seen.) My reasoning for the complexity at the time was that any powerful container library is going to be reasonably complex in implementation (as anyone who's looked at STL source code knows), so it just needs to be encapsulated behind a good interface.
I'm not so sure that's true anymore. These sorts of simpler libraries like the one linked here definitely seem to be more popular among C programmers. I think if people are using C, it's not just the C++ language complexity they want to get away from, but also the implementation complexity of libraries and such. There's a balance to be had for sure, and I think the balance varies from person to person, which is why no library has emerged as the de facto standard for containers in C.
[0]: https://github.com/ludocode/pottery
- C++ containers but in C
- Pottery – A pure C, include-only, type-safe, algorithm template library
- Ask HN: What you up to? (Who doesn't want to be hired?)
-
Type-safe generic data structures in C
Yes! The include style of templates in C is way better than the old way of huge macros to instantiate code. The template code can look mostly like idiomatic C, it interacts way better with a debugger, it gives better compiler errors... everything about it is better and it's finally starting to become more popular.
I've open sourced my own C template library here:
https://github.com/ludocode/pottery
Not only does it use the #include style of templates, but it actually makes the templates composable. It takes this idea pretty far, for example having a lifecycle template that lets you define operations on your type like move, copy, destroy, etc. This way the containers can fully manage the lifecycles of your types even if they're not bitwise movable.
There's also this other more popular C template library, one that tries to more directly port C++ templates to C but with a lot less features:
https://github.com/glouw/ctl/
-
Beating Up on Qsort (2019)
This article doesn't really make it clear but the merge sort discussion is specifically about glibc's implementation of qsort(). glibc's qsort() and Wine's qsort() are the only ones I know of that use merge sort to implement qsort(). Most implementations use quick sort.
I recently did my own benchmarking on various qsort()s since I was trying to implement a faster one. The various BSDs and macOS qsort() are all faster than glibc at sorting integers and they don't allocate memory:
https://github.com/ludocode/pottery/tree/master/examples/pot...
Of course sorting is much faster if you can inline the comparator so a templated sort algorithm is always going to be faster than a function that takes a function pointer. But this does not require C++; it can be done in plain C. The templated intro_sort from Pottery (linked above) is competitive with std::sort, as are the excellent swensort/sort templates:
https://github.com/swenson/sort
sc
- A simple hash table in C
- Advice for bigger c projects?
- sc - Common libraries and data structures for C
-
Hacker News top posts: May 17, 2022
Common libraries and data structures for C\ (107 comments)
-
Common libraries and data structures for C
Can someone tell me what is this line from sc_signal.c:247 in sc/signal/
If the way it is used requires the user to break the abstraction/encapsulation and manually buffer some fields in order not to break the data structure and leak memory, I would call that a bug.
There is one use of sc_array_clear() in the test code [1] which really makes it look as if it is being used in a way that I think (again, I haven't single-stepped this code, only read it) leaks memory.
I agree on the pain of everything being macros, it's more pain than it's worth I think and will likely lead to code duplication (and more pain in debugging, probably).
I would even go so far as to think that this kind of single-file design, where each file is independent of the others, makes it harder and more annoying to implement more complicated data structures.
[1]: https://github.com/tezc/sc/blob/master/array/array_test.c#L3...
-
Uthash – C macros for hash tables and more
https://github.com/tezc/sc/tree/master/map
For those who are interested in faster hashmaps, I tried bunch of hashmaps and this one performs better than others. This is for C. Maybe C++ has better hashmaps.
What are some alternatives?
mpack - MPack - A C encoder/decoder for the MessagePack serialization format / msgpack.org[C]
frr - The FRRouting Protocol Suite
pdqsort - Pattern-defeating quicksort.
wazero - wazero: the zero dependency WebAssembly runtime for Go developers
mavis - opinionated typing library for elixir
chibicc - A small C compiler
Klib - A standalone and lightweight C library
stage0 - A set of minimal dependency bootstrap binaries
ctl - My variant of the C Template Library
gcc
libc - Raw bindings to platform APIs for Rust
libderp - C collections. Easy to build, boring algorithms. Dumb is good.