pottery

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

I recently released a new version of my C MessagePack library MPack [1] with a cool new feature to dynamically calculate the size of maps and arrays during encoding. Having to always specify the size of containers up-front was a pain. I believe it's the only C/C++ MessagePack implementation that can do this. Of course bugs appeared immediately so I am working on a patch release. I am also working on and off on my C template library Pottery [2]. I haven't pushed any code in a while; having a day job and young children makes progress slow :( [1]: https://github.com/ludocode/mpack [2]: https://github.com/ludocode/pottery

But then your code can't be used by anyone without your preprocessor. There is a lot of value in plain C metaprogramming because it can be compiled with an ordinary C compiler. You can, however, use a script to generate some of the preprocessor boilerplate while still having the templates configurable and instantiable with an ordinary C compiler. This is how my metaprogramming library Pottery works: https://github.com/ludocode/pottery It uses #include for templates rather than code block macros, something the article doesn't really go into. It's more powerful this way and the templates are far more readable; aside from the generated metaprogramming boilerplate, the templated code looks like (and preprocesses to) ordinary C.

I built Pottery, a C template library. It provides vectors, hash tables, binary search trees, priority queues, sort algorithms, etc. https://github.com/ludocode/pottery These templates are composable: high-level templates are implemented using lower-level ones. It also supports custom lifecycle functions, so you can tell containers how to copy, move, destroy your values; it supports custom array access functions, so you can use algorithms like sort or heap over a generalized array that may not be contiguous in memory; and more. There is still nothing else like it as far as I know. The closest alternative is CTL but it doesn't have any of those features: https://github.com/glouw/ctl/

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 por

hcreate_r() can be used on some of the BSDs as well, but of course they're not 100% compatible with GNU. I've implemented a platform-independent POSIX hsearch as a wrapper to a templated hashtable in Pottery: https://github.com/ludocode/pottery/tree/master/examples/pot... Be warned, hsearch is terrible. You should probably only use this if you have some existing code that depends on hsearch and you want to make it portable.

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 wit

This is true, but your second point is difficult to do in C. You would have to have a set template and a separate lookup template to search the set based on a key type. This is actually how heterogeneous lookup is implemented in C++: it's a template within a template. This is not a big deal in C++ because templates are instantiated automatically but we're instantiating templates manually in C. It's also only available as of C++14 and only on ordered containers, not hash tables. It's more straightforward to combine these templates: make map the fundamental type, but make values contain their keys and make the key type default to the value type if omitted. This way it's both a map and a set. My own C hash table template does it this way [1]: it stores only a value type and not keys, but there is an optional separate key type used for lookup

Might as well plug mine too: https://github.com/ludocode/pottery I'm not really sure what makes a project take off on HN. I posted mine here a couple weeks ago and got one single upvote :(. I'm glad to see the new style of #include templates getting more attention though. I think in general it's the right way to do templates in C.

I wrote a toy chess engine a few weeks ago as well as an example for one of my open source libraries [1]. I was inspired by a video of someone writing one in half an hour [2], so I also assumed it would take a day or two at most. It took more like a week. But it was very satisfying to not be able to beat my engine anymore. I highly recommend that all programmers with even a passing interest in chess spend some time writing an engine. [1] https://github.com/ludocode/pottery/tree/master/examples/pot... [2] https://youtube.com/watch?v=nzObJ2BpKrk