[wscott]

I was surprised to see `fmt/format.h` on that list, but I do have to admit that the objections seem reasonable. Perhaps because he(?) mentioned wanting to use -O0. Template code is almost useless without optimization. If -O0 is needed then I am surprised that all of the STL doesn't get pitched.

Ok, I was also surprised to see co-routines on the nice list, but I don't have direct experience there. I normally see complaints about them. I would like them to be good because some code is easier to express that way.

[danpla]

> I was surprised to see `fmt/format.h` on that list, but I do have to admit that the objections seem reasonable

The author talks about the code bloat, beacause of "an API that encourages custom formatter specification to live in a template". But at the end he mentions the standard solution to this problem:

> A preferable interface (I use, but also others AFAIK) is to check the type in a template (no choice there), and dispatch the formatting routine to somewhere that lives in a single translation unit.

So what prevents you from doing this with <format>? As I understand, the implementations of parse() and format() of std::formatter don't depend on the template parameters and can delegate to non-template functions residing in one CPP file. You can also provide additional wformat_parse_context/wformat_context overloads if you need wchar_t support.

[gumby]

I guess there’s some legitimate complaint about compile time, but the code bloat issue is simply crazy if you use a linker written since ~1995. And the “fix” is simply to move the common code into a .cc file which the author even mentions.

The alternatives are worse: un-type-checked printf or the horrible stream interpreter system (std::cout << “foo”) which was a cute but bad idea in 1985.

[PH95VuimJjqBqy]

The author talked about its effect on compile-times and I have to say, I agree with him. It's also why I dislike header-only libraries, they also bloat the compile times unnecessarily.

Don't get me wrong, the fmt library is very nice, but you can't deny its effect on compile times.

[vitaut]

fmt/core.h has been heavily optimized for build speed and is usually faster to compile than equivalent iostream code: https://github.com/fmtlib/fmt?tab=readme-ov-file#compile-tim.... Once modularized std is available we might be able to be compete with printf.

[IAmLiterallyAB]

Wondering the same. Seems like you could provide your own implementation or use a third party implementation. Be curious to see a write up on the bloat, what exactly it looks like

[verall]

He says in a different line they he doesn't use the STL, which does make sense for gamedev.

In my corner of the C++ world though, I am so, so excited for <format> in 6 years or however long it will take us to move to C++20.

[vitaut]

{fmt} doesn't encourage "custom formatter specification to live in a template". On the contrary, if you look at the docs in https://fmt.dev/latest/api.html#formatting-user-defined-type..., none of the examples is parameterized. One even demonstrates how to define your formatting code in a source file. And if your formatters are so big that they meaningfully impact build speed you are doing something wrong. fmt/core.h is heavily optimized for build speed so you can just use it as a type-safe replacement for *printf. That said, implementations of std::format (especially Microsoft's) may not be as optimized for build speed yet. This will likely improve now that the ABI can be stabilized.

[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.