c_std

C STL — C++ Standard Library & Python-style utilities, reimplemented in C

This project reimplements a large slice of the C++ Standard Library (containers, algorithms, smart pointers, …) together with many Python-style conveniences (statistics, random, secrets, json, regex, …) in pure C17. The goal is to give C developers familiar, well-documented building blocks — dynamic arrays, maps, strings, JSON, networking, big integers, and much more — without leaving the C ecosystem.

Highlights

• Zero memory leaks. Every module, test suite, and README example is verified under Valgrind (--leak-check=full) — 0 leaks, 0 errors. Network/socket code is additionally checked for descriptor leaks (--track-fds=yes).

• Cross-platform. Builds and runs on Windows (MSVC and MinGW-w64) and Linux (GCC/Clang), with POSIX/Win32 backends behind one API. Compiles cleanly under -Wall -Wextra.

• Pure C17. No C++ — just portable standard C with thin platform shims.

• 40+ modules. Containers, algorithms, smart pointers, strings, JSON/XML/CSV/INI, networking (TCP/UDP/HTTP), crypto & JWT, arbitrary-precision math, graphics, and more.

• Familiar APIs. Modeled on the C++ STL (vector, map, unique_ptr, …) and the Python standard library (random, statistics, json, regex, turtle, …).

• Heavily tested with true results. Deep per-module test suites, plus runnable examples in every README whose shown output is captured from a real run.

• Fast & predictable. Efficient data structures (geometric vector growth with inlined push_back/at, O(1) average hashmap, O(log n) map), clear ownership rules and deallocators.

• CMake build. Build the whole library, a single module, or one example at a time, with GCC, Clang, or MSVC.

Benchmarks vs the C++ STL

The library aims to be fast where it counts. The table below pits each C container against its C++ `` counterpart on the same workload, the same data, and the same compiler family at -O2. Both programs walk an identical deterministic key stream and compute identical checksums, so they do exactly the same work — only the container implementation differs.

Environment: Windows 10, MinGW-w64 GCC / G++ 14.2.0, -O2, single thread, best of three runs (lower is better). Absolute numbers vary by machine; the ratio is what carries over.

C ÷ C++ is the C time divided by the C++ time — below 1.0 means the C library is faster.

• Where C wins — map and hashmap. Both allocate their tree nodes / buckets from a pooled slab allocator, so a million inserts cost a handful of big mallocs instead of a million tiny ones, beating the STL's per-node new.
• About set — near parity. Same pooled-slab, inline-element RB-tree as map. Lookups are actually a hair faster than std::set; inserts are a little slower, so it nets ~1.1×. Unlike map (which stores caller-owned pointers and skips the copy), set has value semantics and deep-copies each element exactly like std::set, so it can't win the copy back — and its node carries the publicly-inspectable key/left/right/parent/color fields (the test suite walks them to check the red-black invariants), which a templated std::set node doesn't expose. A large RB-tree is cache-miss-bound, so that slightly larger node is the whole gap.
• Where C++ wins — vector and priority_queue. Both are tight loops over raw ints. The C vector now inlines push_back/at at the call site just like std::vector and closes most of the gap (~1.3×); the small residual is the type-erased ABI — a runtime itemSize stride and a size-dispatched element copy where C++ has a compile-time sizeof(int), plus the bounds check in vector_at that operator[] skips. The C priority_queue size-dispatches its heap moves the same way (~1.4×); its residual is the comparator — one indirect call through a function pointer per comparison, which std::priority_queue inlines from its template argument. Either way it's a small fixed per-element cost — the price of a uniform C API — not a worse complexity.
• About deque. The C deque stores elements inline in byte-budgeted block buffers (one allocation per block, not one malloc per element) and inlines front / back / at with shift-indexed block math like std::deque, so it lands at ~2.2×; the residual is the out-of-line push_back / pop_front calls that std::deque inlines from templates.
• About list. Each node stores its element inline in the same allocation (one malloc per node, like std::list) instead of a second heap block per element, which roughly halves the allocation/teardown cost and lands it at ~1.2×. The residual is a slightly larger node — the type-erased API keeps a value pointer and aligns the inline element for any type — plus the out-of-line per-node call std::list inlines.
• About forward_list — at parity. It already uses the same single-node- allocation, inline-element design as std::forward_list, so push_front / iterate / teardown match it within measurement noise (≈1.05×). No type-erasure penalty survives here because the per-node malloc dominates and both pay it once per element.
• About queue. The C queue is a contiguous vector used as a ring: enqueue appends and dequeue advances a front index (an O(1) bump, not a buffer shift), with the dead front prefix reclaimed in bulk when the buffer fills — so both ends are amortized O(1), like std::queue. The hot ops are inlined; the ~2× residual is the per-element copy into the contiguous buffer vs std::queue's deque node writes. (Previously dequeue shifted the whole buffer — O(n), an O(n²) drain; that's fixed.)
• About stack. LIFO at the back of a contiguous vector, so push and pop are already O(1). push / top / pop / empty are now inlined in the header (the way std::stack inlines through its container), which cut it from ~3.3× to ~1.7×; the residual is the vector's amortized realloc-copy on growth vs std::stack's default deque adding blocks — in exchange the C stack keeps its elements fully contiguous.

Reproduce it yourself — a C and a C++ program over the identical key stream:

# C  (link the containers used + algorithm, which queue depends on):
gcc -O2 bench.c vector/vector.c queue/queue.c priority_queue/priority_queue.c \
    hashmap/hashmap.c map/map.c algorithm/algorithm.c -I. -o bench_c && ./bench_c
# C++:
g++ -O2 -std=c++17 bench.cpp -o bench_cpp && ./bench_cpp

A personal note

I undertake this project out of a deep affection for the C programming language. C remains an essential tool for any computer engineer, providing the foundation needed to build efficient and robust software. This effort aims to enrich the language with the conveniences found in higher-level standard libraries.

Table of contents

• Highlights
• Benchmarks vs the C++ STL
• Modules
• Dependencies
• Installing the dependencies
  • Windows (MSYS2 / MinGW-w64)
  • Debian / Ubuntu
  • Fedora
• Building with CMake
  • Build everything
  • Build / run one piece at a time
  • Choosing a compiler (GCC / Clang / MSVC)
  • Build options
• Examples
• Per-module documentation
• Contributing
• License

Modules

Every module lives in its own directory with a .c source, a .h header, and a README.md containing a full API reference and runnable examples.

Containers

Algorithms & numerics

Text, data & I/O