A String Formatting Library in 65 Lines of C++

Posted4 months agoActive4 months ago

PaulHoule

51 points

23 comments

riki.houseTechstory

calmmixed

Debate

40/100

C++String FormattingLibrary Design

Key topics

C++

String Formatting

Library Design

A lightweight C++ string formatting library is presented, sparking discussion on its design choices, comparison to existing libraries like {fmt} and std::format, and potential improvements.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

18m

Peak period

0-2h

Avg / period

2.6

Comment distribution23 data points

Loading chart...

Based on 23 loaded comments

Key moments

01Story posted
Sep 15, 2025 at 11:51 AM EDT
4 months ago
Step 01
02First comment
Sep 15, 2025 at 12:09 PM EDT
18m after posting
Step 02
03Peak activity
8 comments in 0-2h
Hottest window of the conversation
Step 03
04Latest activity
Sep 16, 2025 at 6:24 PM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (23 comments)

Showing 23 comments

cppisnice

4 months ago

1 reply

How many CVEs?

speed_spread

4 months ago

1 reply

Yes, true. But the probability of finding new CVEs from any 65 lines of non-obfuscated code diminishes rapidly. In many situations I'd rather use a short minimal fresh lib that I can review as if it was mine than a mature but overly feature-loaded one that may still have any number of pending gotchas in dark corners.

prerok

4 months ago

1 reply

I must admit I was very much against the practice of NIH syndrome, but if it's that short I would prefer to write my own version instead of adding a dependency.

In this day and age who knows when a dependency is hijacked :(

speed_spread

4 months ago

At 65 lines, if the license is right, you can just copy it like you would with a StackOverflow answer. In these situations I leave a comment on top saying where the code came from so it can be revisited later.

kevin_thibedeau

4 months ago

1 reply

  char buffer[64];
  String_Buffer buf = {str, sizeof str};

Probably meant the "buffer" to be "str" here.

thw_9a83c

4 months ago

1 reply

Clearly yes. BTW, I don't see a benefit to use a non-owning String_Buffer over std::string (or std::string_view) in this context.

kevin_thibedeau

4 months ago

The subtext is a resource constrained system where std::format is considered too heavyweight. In that scenario, explicit non-automatic memory management is a benefit. It could still leverage std::string_view and be agnostic on the topic.

dpmdpm

4 months ago

1 reply

I prefer https://github.com/rokudev/rostd/blob/main/doc/printx.adoc, but it does increase compile times (which OP was trying to avoid).

o11c

4 months ago

If you're willing to use one measly little macro - solely to smuggle the format string in a constexpr manner - instead of insisting on using templates everywhere, you can use a printf wrapper with essentially 0 compile-time overhead. And the only runtime overhead is if you have to copy a `string_view` back into a `string` to add the `NUL`-terminator.

You do still need templates for the arguments (unless you're willing to resort to nasty preprocessor hackery, which would be needed if doing this in C - hmm, are the lifetime-of-temporary rules different too?), but it's pretty easy to just do:

  my_asprintf_or_whatever(to_borrowed_primitive(to_owning_primitive(arg))...)

where `to_owning_primitive` is the ADL'ed function you implement for every type you want to print, and `to_borrowed_primitive` probably only needs to be implemented for each string type (though I did find it also useful for wrapped integers of unknown size/rank, such as `time_t`).

merlincorey

4 months ago

3 replies

There's a section on "why not printf" which is Standard C, but I can't find any section on "why not std::format"[1] which is Standard C++ since C++20 and works on all major compilers today in 2025.

They do mention "std::print"[2] from C++23 (which uses std::format) and compile times, but, they don't touch on "std::format" at all.

See:

[1] https://en.cppreference.com/w/cpp/utility/format/format.html

[2] https://en.cppreference.com/w/cpp/io/print.html

hoten

4 months ago

1 reply

Is it in major compilers yet? Last I checked for MSVC it was behind a "latest" compiler flag (not C++20). I've been vendoring the fmt library for awhile now.

shakna

4 months ago

From GCC 13, and clang 17. (2023).

Unfortunately, MSVC, always lags and fails to implement some things.

pton_xd

4 months ago

std::print / std::format also bloat the binary size, which is a consideration for some platforms (eg WASM).

amomchilov

4 months ago

This is the eternal selection pressure that slows new C++ adoption.

The kinds of places still waiting C++ aren’t usually the ones that put much emphasis on using a compiler from the past decade.

Java 8 and C++98 will be here forever lol

dxuh

4 months ago

1 reply

I have recently started re-implementing parts of the standard library myself just to improve compile times (and I did - massively!), but I purposely kept {fmt} around, because I think it's a great library and I thought it would be as fast to compile as you could possibly make it (it likely still is considering what it can do). Also because the dev put a lot of effort into optimizing compile times [1] and seems to be much smarter than me. So I made benchmark to prove you wrong and show you it's not that easy. But it turns out formatting a couple of numbers and strings is much faster with your basic formatting library [2] [3].

Comparing using `hyperfine --warmup 3 "g++ FILE.cpp"` (and some flags for fmt) I get 72ms vs 198ms. So I changed my mind and might take a crack at replacing {fmt} as well. Cool stuff! Thank you.

[1] https://vitaut.net/posts/2024/faster-cpp-compile-times/

[2] https://godbolt.org/z/3YaovhrjP bench-fmt.cpp

[3] https://godbolt.org/z/qMfM39P3q bench-rikifmt.cpp

vitaut

4 months ago

rikifmt only supports the default formatting which is somewhat limited and in the current implementation cannot even format std::string or FP numbers without data loss. Once more functionality is added the variadic template approach will quickly become the limiting factor both for build speed and binary size. But for toy examples you can definitely do better.

teo_zero

4 months ago

I'm lost at the first line of code:

  char buffer[64];

And then it's not used anywhere!

I was curious about the "Why not printf" section, but I found code I don't understand there, too. For example this admittedly non-working snippet is cited as idiomatic:

  char str[4] = {0};
  int cursor = 0;
  cursor += snprintf(str, sizeof str, "hello ");
  cursor += snprintf(str, sizeof str, "world!");

Of corse this doesn't work (if the intent was to assemble the "hello world!" string, of which I'm not entirely sure), but not for the reason stated in TFA. You need to actually use cursor, not merely set it! :)

secondcoming

4 months ago

Nice. I think most people have tried doing something like this in C++ at some point.

One issue that I had is that printing floating-point values really needs the ability for the user to specify the precision and format. It's actually absurd that `std::to_string(double)` does not allow this.

Also, I believe `std::to_chars(double)` uses a fast algorithm and allows writing directly into a buffer.

vjvjvjvjghv

4 months ago

I much prefer string interpolation like

$"i={i}"

symmetricsaurus

4 months ago

Pretty neat and a very nice walkthrough of the code.

For localization you might want numbered holes which makes it way more complicated.

You can detect if the backing buffer is too short, but can you detect other errors? Like having different numbers of holes and arguments? I couldn’t find any discussion about this.

worstenbrood

4 months ago

Love the method name uhm bool next_hole

renox

4 months ago

Next time can you to do Python's string interpolation? ;-) It's much more pleasant to read (when properly used).

vitaut

4 months ago

Note that {fmt} provides a lightweight API (`fmt/base.h`) with a superset of `printf` functionality and optimized for build speed (https://vitaut.net/posts/2024/faster-cpp-compile-times/) and binary size (https://vitaut.net/posts/2024/binary-size/) through type erasure. Variadic templates, while OK in simple cases, won't scale for more realistic ones (especially once you start adding support for more types) and won't work even for basic things like positional arguments.

View full discussion on Hacker News

ID: 45251178Type: storyLast synced: 11/20/2025, 2:18:13 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN