[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