Hacker News Reader

Comment by wscott | Hacker News Reader

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.

View on HN

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

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

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.

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.

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.

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.

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

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

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

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.

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.

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

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

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

Reply on news.ycombinator.com