5 ms·

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 -

by wscott 3y ago

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.

tubs 3y ago
For me the compile time increases are a killer, even if the api is considerably nicer.
- danpla 3y ago
  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_with_compilation_times_in_c20 https://www.reddit.com/r/cpp/comments/o94gvz/what_happened_w...
- gumby 3y ago
  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 3y ago
    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 3y ago
      {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://vitaut.net/posts/2020/fast-int-to-string-revisited/ * https://github.com/fmtlib/fmt/pull/1882 https://github.com/fmtlib/fmt/pull/1882 * https://vitaut.net/posts/2020/optimal-file-buffer-size/ 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-export/ https://aras-p.info/blog/2022/02/03/Speeding-up-Blender-.obj...
      - tubs 3y ago
        Of that blog post the float formatting is a tiny fraction (excuse the pun) of the perf win.
        vitaut 3y ago
        It's just one example showing a decent win with minimal efforts. {fmt} is widely used for getting better perf in formatted code.
danpla 3y ago
> 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.
- IAmLiterallyAB 3y ago
  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
- gumby 3y ago
  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 3y ago
  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 3y ago
    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-time-and-code-bloat 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.
verall 3y ago
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 3y ago
{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-types 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.

by wscott 3y ago

tubs 3y ago

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

danpla 3y ago
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_with_compilation_times_in_c20 https://www.reddit.com/r/cpp/comments/o94gvz/what_happened_w...
gumby 3y ago
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 3y ago
  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 3y ago
    {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://vitaut.net/posts/2020/fast-int-to-string-revisited/ * https://github.com/fmtlib/fmt/pull/1882 https://github.com/fmtlib/fmt/pull/1882 * https://vitaut.net/posts/2020/optimal-file-buffer-size/ 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-export/ https://aras-p.info/blog/2022/02/03/Speeding-up-Blender-.obj...
    - tubs 3y ago
      Of that blog post the float formatting is a tiny fraction (excuse the pun) of the perf win.
      - vitaut 3y ago
        It's just one example showing a decent win with minimal efforts. {fmt} is widely used for getting better perf in formatted code.

danpla 3y ago

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

IAmLiterallyAB 3y ago
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
gumby 3y ago
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 3y ago
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 3y ago
  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-time-and-code-bloat 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.

verall 3y ago

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 3y ago

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