|
| 1 | +<!DOCTYPE html> |
| 2 | +<html lang="en"> |
| 3 | +<head> |
| 4 | + <meta charset="UTF-8"> |
| 5 | + <meta name="viewport" content="width=device-width, initial-scale=1.0"> |
| 6 | + <title>Introduction - fast_io Documentation</title> |
| 7 | + <link rel="stylesheet" href="/style.css"> |
| 8 | + <link rel="manifest" href="/manifest.json"> |
| 9 | +</head> |
| 10 | +<body> |
| 11 | + <main> |
| 12 | + <h1>Introduction to fast_io</h1> |
| 13 | + |
| 14 | + <section> |
| 15 | + <h2>Early Discoveries</h2> |
| 16 | + <p> |
| 17 | + My interest in building a new I/O library began in high school. While exploring |
| 18 | + performance benchmarks online and running my own tests, I discovered that both |
| 19 | + <code>ifstream</code> and <code>stdio</code> were painfully slow. In many cases, |
| 20 | + they were at least <strong>5× slower</strong>, and on some platforms even |
| 21 | + <strong>10× to 100× slower</strong>, compared to simply reading an entire file |
| 22 | + into memory and parsing it manually. |
| 23 | + </p> |
| 24 | + <p> |
| 25 | + This inefficiency convinced me that the standard I/O facilities in C++ were |
| 26 | + fundamentally flawed and needed a complete rethinking. |
| 27 | + </p> |
| 28 | + </section> |
| 29 | + |
| 30 | + <section> |
| 31 | + <h2>Generic Programming vs. OOP</h2> |
| 32 | + <p> |
| 33 | + I was a strong admirer of the <strong>generic programming paradigm</strong> used |
| 34 | + in the C++ standard library’s containers and algorithms. They demonstrated how |
| 35 | + templates could provide both flexibility and performance. Yet, I/O in C++ felt |
| 36 | + inconsistent: <code>iostream</code> leaned heavily on object-oriented programming, |
| 37 | + with virtual inheritance at its core. This design choice introduced complexity |
| 38 | + and inefficiency, and it stood in stark contrast to the elegance of generic |
| 39 | + programming elsewhere in the language. |
| 40 | + </p> |
| 41 | + </section> |
| 42 | + |
| 43 | + <section> |
| 44 | + <h2>The Problem with Format Strings</h2> |
| 45 | + <p> |
| 46 | + Another major frustration was the reliance on <strong>format strings</strong>. |
| 47 | + I always considered them redundant and unsafe. My years of programming in |
| 48 | + <strong>Lua</strong>, particularly while developing World of Warcraft addons, |
| 49 | + gave me a different perspective. Lua’s defaults often felt more correct than |
| 50 | + C++, though Lua itself had its own flaws. |
| 51 | + </p> |
| 52 | + <p> |
| 53 | + I came to believe that format strings should be eliminated entirely. No matter |
| 54 | + how you constrain them — even at compile time — they remain vulnerable. Macros, |
| 55 | + code generators, or even AI-generated code can reintroduce format string |
| 56 | + vulnerabilities. The complexity never truly disappears. In my view, format |
| 57 | + strings are a <strong>trillion-dollar historical mistake</strong>, comparable |
| 58 | + to the infamous <code>gets()</code> function. Since <code>gets()</code> was |
| 59 | + itself an I/O function in <code>stdio</code>, this only reinforced my belief |
| 60 | + that the entire <code>stdio</code> system is extremely dangerous. |
| 61 | + </p> |
| 62 | + </section> |
| 63 | + |
| 64 | + <section> |
| 65 | + <h2>The Birth of fast_io</h2> |
| 66 | + <p> |
| 67 | + In 2013, when Bjarne Stroustrup introduced <strong>concepts prototypes</strong> |
| 68 | + at CppCon, I had a breakthrough idea: why not use concepts to rewrite the entire |
| 69 | + I/O subsystem? That was the moment <strong>fast_io</strong> was born — at least |
| 70 | + in theory. I built an early prototype using GCC’s experimental concepts |
| 71 | + implementation, just to prove the idea was viable. |
| 72 | + </p> |
| 73 | + <p> |
| 74 | + Unfortunately, concepts were still immature at the time, existing only as a |
| 75 | + Technical Specification (TS). Without proper standard library support, |
| 76 | + <strong>fast_io</strong> couldn’t move beyond a prototype. The real |
| 77 | + implementation only began in earnest around 2020, once concepts became part of |
| 78 | + mainstream C++. |
| 79 | + </p> |
| 80 | + </section> |
| 81 | + |
| 82 | + <section> |
| 83 | + <h2>Refinement and Philosophy</h2> |
| 84 | + <p> |
| 85 | + Even after 2020, <strong>fast_io</strong> went through multiple waves of |
| 86 | + refactoring. My goal was not just to make it functional, but to make it |
| 87 | + <em>good</em> — elegant, portable, and robust. Because it is concepts-based, |
| 88 | + the library is designed to work across all platforms, and even in environments |
| 89 | + without operating systems. |
| 90 | + </p> |
| 91 | + <p> |
| 92 | + Herb Sutter’s talk on <strong>Herbceptions</strong> further influenced my vision. |
| 93 | + Since I/O is one of the largest consumers of exceptions in C++, I realized that |
| 94 | + <strong>fast_io</strong> would eventually need to integrate Herbceptions to |
| 95 | + truly complete its design. Until that happens, the library will continue to |
| 96 | + evolve, with APIs gradually stabilizing as the design matures. |
| 97 | + </p> |
| 98 | + </section> |
| 99 | + |
| 100 | + <section> |
| 101 | + <h2>Backwards Compatibility</h2> |
| 102 | + <p> |
| 103 | + A key design principle of <strong>fast_io</strong> is backwards compatibility. |
| 104 | + The library is built to interoperate with multiple existing systems: |
| 105 | + <code>wine</code> (host file descriptors), <code>NT</code> handles, |
| 106 | + <code>Win32</code> handles, <code>POSIX</code> file descriptors, |
| 107 | + <code>stdio</code>, and even <code>filebuf</code> from |
| 108 | + <code>iostream/fstream</code>. Considerable effort has gone into making these |
| 109 | + systems compatible with one another under a unified interface. |
| 110 | + </p> |
| 111 | + </section> |
| 112 | + |
| 113 | + <section> |
| 114 | + <h2>Freestanding Environments</h2> |
| 115 | + <p> |
| 116 | + Because <strong>fast_io</strong> is intended to work everywhere, including |
| 117 | + freestanding environments, I came to realize that many features advocated by |
| 118 | + the C++ community — exception handling (EH), RTTI, <code>vector</code>, |
| 119 | + <code>array</code>, and others — simply do not function reliably outside of |
| 120 | + hosted environments. This reinforced the need for a library that is both |
| 121 | + <strong>freestanding-friendly</strong> and conceptually modern. |
| 122 | + </p> |
| 123 | + </section> |
| 124 | + |
| 125 | + <section> |
| 126 | + <h2>Looking Ahead</h2> |
| 127 | + <p> |
| 128 | + <strong>fast_io</strong> is more than just an I/O library. It is a proof of |
| 129 | + concept — a demonstration to WG21 and the broader C++ community that I/O can |
| 130 | + be reimagined using modern language features. It is a statement against |
| 131 | + inefficiency, redundancy, and outdated design patterns. And it is a commitment |
| 132 | + to building tools that are both fast and conceptually clean. |
| 133 | + </p> |
| 134 | + </section> |
| 135 | + <section> |
| 136 | + <h2>Video Introduction</h2> |
| 137 | + <p> |
| 138 | + Here’s a talk that further illustrates the ideas behind <strong>fast_io</strong>: |
| 139 | + </p> |
| 140 | + <div class="video-container"> |
| 141 | + <iframe width="560" height="315" |
| 142 | + src="https://www.youtube.com/embed/CefgZlXeMUg" |
| 143 | + title="YouTube video player" |
| 144 | + frameborder="0" |
| 145 | + allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" |
| 146 | + allowfullscreen> |
| 147 | + </iframe> |
| 148 | + </div> |
| 149 | + </section> |
| 150 | + <!-- Add this after the last section --> |
| 151 | + <div class="next-page"> |
| 152 | + <a href="/docs/examples.html" class="next-button">Next: Examples →</a> |
| 153 | + </div> |
| 154 | + </main> |
| 155 | + |
| 156 | +</body> |
| 157 | +</html> |
0 commit comments