fast_io

Early Discoveries

My interest in building a new I/O library began in high school. While exploring performance benchmarks online and running my own tests, I discovered that both ifstream and stdio were painfully slow. In many cases, they were at least 5× slower, and on some platforms even 10× to 100× slower, compared to simply reading an entire file into memory and parsing it manually.

This inefficiency convinced me that the standard I/O facilities in C++ were fundamentally flawed and needed a complete rethinking.

Generic Programming vs. OOP

I was a strong admirer of the generic programming paradigm used in the C++ standard library’s containers and algorithms. They demonstrated how templates could provide both flexibility and performance. Yet, I/O in C++ felt inconsistent: iostream leaned heavily on object-oriented programming, with virtual inheritance at its core. This design choice introduced complexity and inefficiency, and it stood in stark contrast to the elegance of generic programming elsewhere in the language.

The Problem with Format Strings

Another major frustration was the reliance on format strings. I always considered them redundant and unsafe. My years of programming in Lua, particularly while developing World of Warcraft addons, gave me a different perspective. Lua’s defaults often felt more correct than C++, though Lua itself had its own flaws.

I came to believe that format strings should be eliminated entirely. No matter how you constrain them — even at compile time — they remain vulnerable. Macros, code generators, or even AI-generated code can reintroduce format string vulnerabilities. The complexity never truly disappears. In my view, format strings are a trillion-dollar historical mistake, comparable to the infamous gets() function. Since gets() was itself an I/O function in stdio, this only reinforced my belief that the entire stdio system is extremely dangerous.

The Birth of fast_io

In 2013, when Bjarne Stroustrup introduced concepts prototypes at CppCon, I had a breakthrough idea: why not use concepts to rewrite the entire I/O subsystem? That was the moment fast_io was born — at least in theory. I built an early prototype using GCC’s experimental concepts implementation, just to prove the idea was viable.

Unfortunately, concepts were still immature at the time, existing only as a Technical Specification (TS). Without proper standard library support, fast_io couldn’t move beyond a prototype. The real implementation only began in earnest around 2020, once concepts became part of mainstream C++.

Refinement and Philosophy

Even after 2020, fast_io went through multiple waves of refactoring. My goal was not just to make it functional, but to make it good — elegant, portable, and robust. Because it is concepts-based, the library is designed to work across all platforms, and even in environments without operating systems.

Herb Sutter’s talk on Herbceptions further influenced my vision. Since I/O is one of the largest consumers of exceptions in C++, I realized that fast_io would eventually need to integrate Herbceptions to truly complete its design. Until that happens, the library will continue to evolve, with APIs gradually stabilizing as the design matures.

Backwards Compatibility

A key design principle of fast_io is backwards compatibility. The library is built to interoperate with multiple existing systems: wine (host file descriptors), NT handles, Win32 handles, POSIX file descriptors, stdio, and even filebuf from iostream/fstream. Considerable effort has gone into making these systems compatible with one another under a unified interface.

Freestanding Environments

Because fast_io is intended to work everywhere, including freestanding environments, I came to realize that many features advocated by the C++ community — exception handling (EH), RTTI, vector, array, and others — simply do not function reliably outside of hosted environments. This reinforced the need for a library that is both freestanding-friendly and conceptually modern.

Looking Ahead

fast_io is more than just an I/O library. It is a proof of concept — a demonstration to WG21 and the broader C++ community that I/O can be reimagined using modern language features. It is a statement against inefficiency, redundancy, and outdated design patterns. And it is a commitment to building tools that are both fast and conceptually clean.

Video Introduction

Here’s a talk that further illustrates the ideas behind fast_io: