Writing your own C++ standard library from scratch

Original Article ↗ Hacker News Discussion ↗

Scope of the project and title (“STL” vs standard library)

  • Several comments argue the title is misleading: this is not a reimplementation of the C++ standard library, just a small alternative library in another namespace with overlapping features.
  • Repeated clarification that “STL” historically refers to a subset (templates: containers + algorithms), whereas the full C++ standard library also includes I/O, math, concurrency, C headers, etc.
  • Others note that in practice many developers and even major vendors casually use “STL” to mean the whole standard library, so the terminology is fuzzy but widely accepted.

Compilation cost and template complexity

  • Discussion on why 27k vs 1k lines of header code only yields ~4× compile-time difference.
  • Points raised: cost depends more on what’s on each line than on pure line count; templates and instantiated types dominate; only used members are optimized/codegen’d.
  • Separate template instantiations for each vector<T> type are mentioned as a potential compile-time and code-size factor.

Language–library coupling and freestanding use

  • A commenter reports difficulty writing a fully custom stdlib because some core language features (e.g., <=>) are specified to return types in std (std::partial_ordering).
  • Debate over whether such types should be “built into” the compiler vs defined in the library, and how this blurs the historical C vs library boundary.
  • Some note that in practice even C compilers rely on library functions and support libraries, so the separation was already somewhat theoretical.

Motivations for custom libraries

  • Examples given: minimal WebAssembly binaries, game development needs (safety-by-default, avoiding locales, custom allocators, ABI constraints), and dissatisfaction with complexity/overloads/exceptions in std.
  • Others observe many in-house “OurString/OurVector” implementations exist without a clear technical justification, often cargo-culting “STL is slow.”
  • Consensus: for most domains the standard library is “good enough,” but niche performance/safety/ABI needs can justify custom containers.

ABI stability skepticism

  • The post’s “perfect ABI stability” claim is called naïve: any 3rd-party binary that embeds library types (e.g. pystd::HashMap) is tied to that epoch; mixing epochs breaks ABI.
  • Comparisons drawn to inline namespaces like std::__1 and to upcoming reflection proposals, with multiple commenters stressing that class layout/value representation changes are inherently ABI-breaking.
  • One speculative idea: a “dynamic class-sizer”/“struct linker” that remaps layouts at link or load time, but others argue this is infeasible for general C++ templates and semantics.

Standard library size, guarantees, and compile-time

  • Some wonder how much complexity/size comes from supporting multiple standards and preprocessor branches; others respond that parsing + semantics, not preprocessing, dominate.
  • Complexity also stems from strong semantic and complexity guarantees (e.g., iterator validity and asymptotic bounds), constraining implementations.

String trimming, Unicode, and std::string

  • Multiple people are surprised C++ has no standard trim and note that “everyone rolls their own.”
  • Discussion quickly turns to “trim what?”: ASCII spaces? all ASCII whitespace? full Unicode whitespace? This depends on encodings and Unicode version, making a simple, stable definition hard.
  • Some argue precisely because it’s tricky it belongs in the standard library (even suggesting folding ICU in by reference); others say ICU is too big, evolving, and binary-incompatible for the standard.
  • It’s noted that std::string is just a byte container, which complicates Unicode‑aware operations; contrast is drawn with languages like Rust that tie string APIs to a known encoding.

What belongs in the standard library vs third-party

  • One view: stdlib should provide (1) shared “vocabulary types” (string, vector, hash map, basic algorithms) and (2) widely-needed, easy‑to‑get‑wrong utilities (e.g., trimming).
  • Another view: not everything that “everyone reimplements” must be standardized; better third‑party libraries + modern package managers (vcpkg, conan) can fill gaps.
  • Historical note: in ecosystems with weak package management, stdlibs tend to become “batteries included,” whereas Rust/Python comparisons show different tradeoffs.

Safety and evolution of std

  • Some want safer defaults (bounds‑checked operator[], “safety profiles” that disable unsafe operations).
  • Others note ongoing committee work on safety/hardening, but acknowledge full retrofitted safety is impossible without breaking large amounts of existing code.

Modules, modern C++, and examples of clean code

  • Commenters express interest in C++ modules and their support in major compilers; suggestion to use import std; is tempered by the reality that not all toolchains fully support it yet.
  • Suggestions for studying modern C++ style include reading certain OS/browser codebases and introductory modern C++ books; experience varies on how up-to-date their idioms are.

Code-quality critique of the example program

  • One detailed critique claims the example code is not performance-conscious: repeated allocations per line, repeated hash lookups, no preallocation, and use of printf instead of type-safe I/O.
  • The critic argues that renaming the library doesn’t change the underlying coding style; others don’t push back strongly, leaving this as an open criticism.

Backward compatibility and compilers

  • A non-C++ user asks how such a library will fare with future compilers. Response: new compilers overwhelmingly compile old code, with breaking changes mainly tied to fixing compiler bugs.

Miscellaneous

  • Some praise the post’s fun tone and the use of a concrete sample program but dislike that the sample code is shown as an image instead of text.
  • One person asks about the meaning of the “py” prefix in the library name; no clear answer is given in the thread.