[tubs]

For me the compile time increases are a killer, even if the api is considerably nicer.

[danpla]

Unfortunately, if you're using the standard library, you get this just by switching to the C++20 mode. For example, the committee decided to put tons of std::ranges-related stuff right in <algorithm>.

https://www.reddit.com/r/cpp/comments/o94gvz/what_happened_w...

[gumby]

It isn’t just a nicer API but type safe and much faster at runtime.

Since I rarely compile all my code at once (usually just a single file followed by a re-link) compile time doesn’t matter much. And that’s even though while editing or writing code I don’t have all the slowdown bloat of an IDE so compile time is more noticeable.

[tubs]

In my experience if you're doing perf critical stuff with string formatting you won't be using anything like fmt or printf, and for everything else the runtime difference is almost entirely unimportant.

[vitaut]

{fmt} is commonly used for performance critical code because it provides some of the fastest numeric formatting and I/O:

* https://vitaut.net/posts/2020/fast-int-to-string-revisited/ * https://github.com/fmtlib/fmt/pull/1882 * https://vitaut.net/posts/2020/optimal-file-buffer-size/

Here's just one example: https://aras-p.info/blog/2022/02/03/Speeding-up-Blender-.obj...

[tubs]

Of that blog post the float formatting is a tiny fraction (excuse the pun) of the perf win.

[vitaut]

It's just one example showing a decent win with minimal efforts. {fmt} is widely used for getting better perf in formatted code.