c_std reimplements the C++ standard library and half of Python in C17

One language, two libraries' worth of API

c_std is a project that reimplements a large slice of the C++ Standard Library, containers, algorithms, smart pointers, together with many Python style conveniences such as statistics, random, secrets, json and regex, in pure C17. The stated goal is to give C developers familiar, well documented building blocks, dynamic arrays, maps, strings, JSON, networking and big integers among them, without leaving the C ecosystem.

That combination is the interesting part. A C project that grows needs a vector, a hash map, a string type and a JSON parser, and the usual options are to write them badly once, to vendor a single library, or to move to C++. This project takes the position that you can have the API shapes you already know, in C, with the type safety limits that C imposes.

The API shapes are borrowed deliberately. The containers are modelled on the C++ STL, with names like vector, map and unique_ptr, and the utility modules are modelled on the Python standard library, with random, statistics, json, regex and even turtle in the list. The tests and documentation follow from that choice, since a developer coming from either language meets a familiar surface.

The technical constraints are stated plainly. It is pure C17 with no C++ and only portable standard C plus thin platform shims, it builds and runs on Windows with both MSVC and MinGW-w64 and on Linux with GCC and Clang behind POSIX and Win32 backends under one API, and it compiles cleanly under -Wall -Wextra. The build is CMake, and you can build the whole library, a single module, or one example at a time with GCC, Clang or MSVC.

The audience is a C developer who wants the ergonomics without the language change. The licence is ISC, which is short and permissive, and the last push was on 2026-10-18 with the repository not archived.

Why the type erased API costs you on some containers

The benchmark section is the most valuable part of this project, and the part that shows the author understands the trade-off rather than hiding it.

The premise is careful. Each C container is compared against its C++ STL counterpart on the same workload, the same data and the same compiler family at -O2, with both programs walking an identical deterministic key stream and computing identical checksums, so they do exactly the same work and only the implementation differs. The environment is Windows 10 with MinGW-w64 GCC and G++ 14.2.0, single threaded, best of three runs, and the readme says the absolute numbers vary by machine while the ratio is what carries over.

The results are mixed and the readme explains each one. The map is 0.83 times the time of std::map and the hashmap is 0.63 times the time of std::unordered_map, so both are faster, and the reason is a pooled slab allocator: the tree nodes and buckets come out of a few large allocations rather than a million tiny ones, which beats the STL's per node new. The set is about parity at 1.1 times, and the readme is careful about why the lookup is actually slightly faster while the insert is slightly slower, with the net effect coming from the value semantics, since the C set deep copies each element exactly like std::set and cannot win the copy back, and because the node carries publicly inspectable key, left, right, parent and color fields that the test suite walks to check the red-black invariants, which a templated node does not expose.

The losses have the same kind of explanation. The vector is 1.3 times and the priority queue 1.4 times, and the reason is the type erased ABI: a runtime itemSize stride and a size dispatched element copy where C++ has a compile-time sizeof, plus the bounds check in vector_at that operator[] skips, and for the priority queue an indirect call through a function pointer per comparison where the STL inlines it from the template argument. The readme calls it a small fixed per element cost, the price of a uniform C API, rather than a worse complexity.

The remaining rows follow the same pattern. The deque at 2.2 times stores elements inline in byte budgeted block buffers and inlines front, back and at, and the residual is the out-of-line push_back and pop_front calls the STL inlines from templates. The list at 1.2 times stores its element inline in the same allocation instead of a second heap block per element, and the residual is a slightly larger node plus the out-of-line per node call. The forward list is at parity at 1.05 times because the per node malloc dominates and both pay it once per element. The queue at 2.0 times is a contiguous vector used as a ring, with an O(1) front index bump rather than a buffer shift and the dead prefix reclaimed in bulk, so both ends are amortized O(1). And the stack is 1.7 times.

This is the kind of analysis that makes a benchmark table worth reading. Every number has a mechanism attached to it.

The table in full

The published table, with the C container on the left of each pair and the ratio computed as the C time divided by the C++ time, so a value below 1.0 means the C library is faster:

| C container and STL counterpart | Workload | C | C++ | C divided by C++ | | --- | --- | --- | --- | --- | | vector and std::vector of int | push_back and sum, 10,000,000 | 0.041 s | 0.031 s | 1.3x | | map and std::map of int, ordered | insert and lookup, 1,000,000 | 1.00 s | 1.20 s | 0.83x | | hashmap and std::unordered_map of int | insert and lookup, 1,000,000 | 0.231 s | 0.364 s | 0.63x | | set and std::set of int, ordered | insert and lookup, 1,000,000 | 1.17 s | 1.05 s | 1.1x | | priority_queue and std::priority_queue | push and pop, 1,000,000 | 0.156 s | 0.108 s | 1.4x | | deque and std::deque | push_back, iterate, pop_front, 1,000,000 | 0.009 s | 0.004 s | 2.2x | | list and std::list | push_back, iterate, teardown, 1,000,000 | 0.093 s | 0.075 s | 1.2x | | forward_list and std::forward_list | push_front, iterate, teardown, 1,000,000 | 0.080 s | 0.076 s | 1.05x | | queue and std::queue | enqueue and dequeue, 1,000,000 | 0.006 s | 0.003 s | 2.0x | | stack and std::stack | push and pop, 1,000,000 | 0.005 s | 0.003 s | 1.7x |

Read as a whole, the pattern is that the C library wins where allocation dominates, which is the tree and hash structures, and loses where the work is a tight loop over raw integers, which is the sequence containers and the heap.

That is a coherent story, and it is the reason the project can be honest about being slower in eight of the ten rows. The comparison is also narrower than it looks: it is one workload per container, on one operating system, with one compiler, at one optimisation level, single threaded, and the readme says so rather than presenting the ratios as universal.

Valgrind clean, and a test suite per module

The testing story is the second thing that distinguishes this project from a personal utility library.

The headline is that every module, test suite and README example is verified under Valgrind with the full leak check, and the result is stated as zero leaks and zero errors. The network and socket code is additionally checked for descriptor leaks with the file descriptor tracking option, which is a distinction that matters, since a socket library can pass a memory leak check and still leak file descriptors.

The project also claims deep per module test suites, and runnable examples in every README whose shown output is captured from a real run. That last detail is the one to appreciate. It means the output in the documentation is not illustrative, it is the output, so a reader can compare their own run against the documented one and know whether something is wrong.

The features list adds efficiency notes that are consistent with the benchmark analysis: a geometric vector growth with inlined push_back and at, an O(1) average hashmap and an O(log n) map, plus clear ownership rules and deallocators. The set's red-black invariants are checked directly by walking the node fields, which is the kind of test that catches a subtle insertion bug that a functional test would miss.

The trade-off with the Valgrind claim is that it was measured on one platform. The readme does not describe a continuous integration matrix, and the repository listing does not show a workflow directory of the kind other projects here carry, so the checks appear to be part of the development process rather than something enforced on every commit.

Forty plus modules, several of them surprising

The directory listing is the module catalogue, and it is longer and more eclectic than the STL and Python comparison suggests.

The container set is what you would expect: vector, array, deque, list, forward_list, map, set, hashmap, priority_queue, queue, stack, span, variant, tuple, uniqueptr, bitset, and an algorithm folder and a sort folder. Around them are the utility modules that a C project ends up needing: string, fmt, log, config, json, xml, csv, encoding, regex, uuid, time, date, sysinfo, numbers, and a bigint and bigfloat pair for arbitrary precision arithmetic.

Then there are the ones that explain the Python comparison. There is a random module, a statistics module, a secrets module, and a turtle module, which is a graphics turtle in the style of the Python educational library, alongside a plot folder and a matrix folder for graphics work, plus an evalexpr folder for evaluating expressions.

And there is a set of modules that belong to neither library. There is network, with TCP, UDP and HTTP, a serial_port module for talking to hardware, a database module, a crypto module and a jwt module, a concurrent folder, a cli folder for command line parsing, a file_io folder, a dir folder, a unittest folder, and a main.c at the root for the example runner.

So the honest summary is that c_std is two libraries in one: a familiar container and utility layer for C, and a grab bag of system and text processing modules that a C developer would otherwise write badly. The first half is a coherent design with a benchmark story, and the second half is a utility collection whose quality you would have to check module by module.

Building it, and the absence of releases

The build is CMake, and the readme describes three ways to use it: build the whole library, build a single module, or build one example at a time, with GCC, Clang or MSVC. The top level has a CMakeLists.txt and the module directories are the natural unit of build, which is a practical arrangement for a project with forty plus modules, since most consumers want two or three of them rather than all of them.

The project does not publish releases, and the repository has no GitHub releases, so there is no version to pin and no changelog to read. The last push was on 2026-10-18, and the repository is not archived.

For a dependency, that combination is the deciding factor. The ISC licence is about as permissive as they come, so there is no licensing obstacle to vendoring or reusing the code. But with no tagged versions, no package registry entry and no stated support policy, the realistic way to use this is to vendor the modules you need into your tree, or to pin a specific commit, and to treat the upstream repository as a source of code rather than as a package you can update with a version bump.

That also determines how you should read the benchmark and the Valgrind results. They are evidence about a particular state of the code on a particular platform, produced by someone who cared enough to measure. They are not a maintenance guarantee, and the absence of releases means the guarantee has to be yours instead.

Editorial conclusion

c_std suits a C project that needs dynamic arrays, maps, strings, JSON and a hash map without pulling in a C++ toolchain, and it suits a developer who wants familiar STL and Python style APIs in a codebase that must stay C. It is the wrong choice if you need a maintained dependency with published versions, because the repository has no releases and no package registry entry, and a poor match if you need the last few percent of container throughput, since the type erased C API costs measurable time on the hot paths of vector and priority queue. Before adopting, read the benchmark notes for the container you care about, check that the module you want is present in the directory listing, and run the project's own Valgrind checks on your platform, since the leak results were produced on one operating system.

Frequently asked questions

Official sources

1. Issues
2. KaisenAmin/c_std on GitHub
3. License: ISC
4. README