from Hacker News

Writing your own C++ standard library from scratch

by JNRowe on 3/25/25, 8:10 AM with 131 comments

by bregma on 3/25/25, 10:54 AM
He's not writing the C++ standard library from scratch. He's writing his own library, in a different namespace, with some similar functionality. It's easy to write a non-standard library that only satisfies your limited subset of needs. People do it all the time. It's not special.
The ABI stability boast is based on having no legacy to support. It will work fine as long as everything is shipped only as code and the whole world needs to be rebuilt from scratch every time and even then, you never change any code ever even for a major bugfix. That's hardly practical in the real world where one tiny misstep on the ABI front can result in billion-dollar multinationals threatening suit (ask me how I know). It's a facile claim.
The C++ standard library hasn't been known as "the STL" for almost 30 years, ever since part of the STL was modified and adopted into the C++ standard library. Most of the features he's providing implementations for were never a part of the STL (file I/O, strings, hash maps, UTF-8).
I maintain an implementation of the C++ standard library for a living. It's a full-time job. It's a huge library (note to the committee: please stop) and it's really easy to mess something up. But if you want to write your own library that doesn't do what the standard library does or meet any of its requirements and implementation constraints or serve its real-world purpose, go right ahead. Just don't claim you're writing your own C++ standard library. You're not.
by leni536 on 3/25/25, 9:27 AM
The section about the "perfect ABI stability" is rather naive. If you have a 3rd party library that exposes a class like this in a header:
```
  class SomePublicClass {
    pystd::HashMap<pystd::U8String, size_t> member;
    /*...*/
  };
```
and distribute that 3rd party library as compiled against a particular pystd version and the headers, then that build is tied to one particular "epoch" or version of pystd, you can't safely link that library against a program that uses a different "epoch" of pystd.
It's also not a new idea either. libc++ puts everything inside an inline namespace `std::__1`. There is a reason that they never bumped that.
by fefe23 on 3/25/25, 8:42 AM
The title is confusing. He is not reimplementing the STL. He is writing some C++ classes providing functionality that is also already implemented in STL.
by BonusPlay on 3/25/25, 8:58 AM
A problem I encountered while writing custom stdlib, is that certain language features expect stdlib to be there.
For example, <=> operator assumes, that std::partial_ordering exists. Kinda lame. In the newer C++ standards, more and more features are unusable without stdlib (or at least std namespace).
by grandempire on 3/25/25, 1:35 PM
There is a science to designing reusable containers and algorithms, and it’s based on research like Art of Computer programming and you can learn more by reading primary sources about the design of STL.
STL can absolutely be improved, but posts like this indicate most programmers are clueless about how it works, and not in a position to learn from its mistakes and make something better.
If we are serious about code reuse we need to study these ideas and learn how to actually write libraries. The alternative is the npm/crates model - where you throw together 100 different open source concoctions and hope it works.
by unwind on 3/25/25, 8:40 AM
Very nice! I like the tone and flippant energy of the post, of course, and also the way to get a nice scope by having a concrete case of a program to implement.
I also appreciated the comparisons against STL, very informative. It's ... interesting that if including `vector` in STL brings in 27,000 lines, and the author's implementation of the functionality for the example program was only 1,000 lines, that the compilation time difference is only 4X. Not sure I understand that, really. But benchmarking is hard, of course.
If I could come with a single suggestion it would be to include the sample program's source as text, not as a picture of text. If that means losing the pretty syntax highlighting, that's fine (by me). :)
by dvh on 3/25/25, 10:12 AM
I unexpectedly did some cpp few days ago and I was surprised that cpp standard library doesn't have string trim function! Everybody is rolling their own. What is the reason behind that?
by quibono on 3/25/25, 11:50 AM
A bit off-topic maybe, what is a good open source library to read through to see some clean&modern C++? I've not dealt with the language in a bit and was thinking of diving back in
by germandiago on 3/25/25, 9:37 AM
A bit off-topic, but as a Meson user, I would love to see C++ modules support since they start to be usable in all three big compilers.
Nice experiment for the pyStd, though, as pointed out, this would break with pre-compiled 3rd party deps that use pystd in a different version :)
by daemin on 3/25/25, 9:07 AM
I do wonder how much smaller the STL source code would be if it was pre-processed or written with only a single C++ standard in mind. So only for C++20 or only for C++23 etc. In that case how much faster would things be to compile where it doesn't need to filter through hundreds of preprocessor options?
by larusso on 3/25/25, 11:33 AM
How will this year release scale when you need to work with newer compilers? I don‘t write cpp so I honestly don‘t know. Do you need to freeze your version of the compiler forever? Or is gcc / clang backwards compatible? Or do you sprinkle tons of pragmas on the files to control this? What I mean is how can you make sure your version one API is still compiling in the future. Take the counter example of ruby for instance. I could write a package with lots of namespaces and declare v1 frozen. But I still need to potentially
update the code so it can run in newer versions of the runtime. Edit: typos
by usrnm on 3/25/25, 9:20 AM
Years ago every C++ project worth its salt had at least one implementation of of strings, vectors and other basic things. I hoped we finally were past that.
by atombender on 3/25/25, 12:02 PM
> The C++ standard library (also know as the STL)
The C++ Standard Library is not the same as the STL.
The STL is the Standard Template Library, which provides containers such as vectors, as well as related functionality like iterators.
The C++ Standard Library includes STL, but is a lot more, including things like I/O, math, concurrency, and so on.
by singularity2001 on 3/25/25, 9:09 AM
I did that to get minimal wasm binaries, not sure if tree shaking today would sufficiently shrinks c++ wasm apps.
by zerr on 3/25/25, 9:18 AM
I recall years ago there was some kind of competition in implementing full C++ parser/front-end and standard library, or something like that, allegedly organized by nvidia.
by cozzyd on 3/25/25, 11:43 PM
Is there an explanation for the py prefix? Is that some sort of cruel joke?
by SleepyMyroslav on 3/25/25, 8:51 PM
Rant. I do not see any improvement in the outcome code. Lets not nitpick on fast parsing and just scroll through unnecessary code actions.
> ... u8line(move(line))
We are not reusing parsed line object between iterations. Forcing fresh allocation per line.
> auto words = ...
Fresh allocation per line.
> lookup/insert
Lookup and hashing done 2 times for each word. Each unique word individually allocated on the heap.
> stats.push_back
Not preallocated. Likely doing full allocate + copy per each word.
> sort_relocatable
Could have been faster with additional memory provided. But this is minor because sorting probably was not ideal in the first place.
and the icing on the cake:
>printf("%d ... (int)count ...
As old saying goes "One can write Fortran program in any language". There are zero reasons to write non type safe text output in 2025 in C++ but here we are.
TLDR. One can name their foundation library any name and use any namespace it does not change how the code written much. Right?