Code bloat info actual?

[stgatilov]

The README page advertises fmt as lightweight library. always pointing the user to benchmarks against <fmt/core.h>:

• Try {fmt} in Compiler Explorer.
• Small code size both in terms of source code with the minimum configuration consisting of just three files, core.h, format.h and format-inl.h, and compiled code; see Compile time and code bloat

However, it is not said anywhere that benchmarked <fmt/core.h> is not considered default.
In fact, <fmt/core.h> does not support many other of the features advertised:

• errors in format strings can be reported at compile time
• Safe printf implementation including the POSIX extension for positional arguments
• Optional header-only configuration enabled with the FMT_HEADER_ONLY macro

I won't be surprised if extensibility with custom types also does not work with <fmt/core.h>.

---

In my tests with Visual Studio 2019 optimized build, I noticed that <fmt/format.h> produces 32 times larger object files and takes 10 times more time to compile.
The difference between two modes is huge!

In my measurements, the cost of <fmt/format.h> is 800 KB of object code and 0.5 seconds compilation time (one thread) per one cpp file using it. I got this both on synthetic benchmark and from adding a few fmt calls to all cpp files of a real project.
That's absolutely not lightweight anymore!

This gives the library bad smell.
As if the author of readme is deliberately confusing users with flashy statistics to make the library more popular =)
I totally agree that <fmt/format.h> is a great library with compile-time checks and that <fmt/core.h> is very lightweight, but readme should say straight that these two qualities don't combine, and that user has to choose.

UPDATE: I got very slow compilation because of fmt::format_to_n + <fmt/format.h> combo (more info below).

---

Also note that the cited compilation time benchmark from tinyformat does not use precompiled headers.
So the reported times include time of parsing, and thus don't reflect the best-practices real world usage.

I'm not sure about GCC/Clang, but on MSVC parsing usually takes the majority of time without PCH, but it can be completely removed by adding libraries to precompiled header.
This explains why boost looks so bad (including boost without PCH is absurd), and why printf+string looks so much slower than printf (including STL in PCH is obvious, isn't it?).

Just to clarify: I added fmt headers to precompiled headers in my benchmarks of fmt.

[vitaut]

However, it is not said anywhere that benchmarked <fmt/core.h> is not considered default.

Not sure what you mean by default but fmt/core.h is the recommended way to consume the library if you care about code bloat and compile times and don't need any optional features.

In fact, <fmt/core.h> does not support many other of the features advertised

This is not correct. fmt/core.h supports compile-time checks. printf implementation is not included there and mostly exists for porting legacy code and the header-only configuration is not recommended at all.

The reason why fmt/format.h is relatively large is mostly because it has the full implementation of FP formatter but most of the generated binary code is from templates and will be deduped by the linker.

I think the readme is pretty clear that it compares equivalent uses of iostreams, stdio and {fmt} and in that respect it is completely fair. If you need advanced features you might obviously need to pay more.

Please see the {fmt} docs: https://fmt.dev/latest/api.html#core-api.

[stgatilov]

This is not correct. fmt/core.h supports compile-time checks.

I followed the link "Try {fmt} in Compiler Explorer" to godbolt, and changed the line in main:

fmt::print("The answer is {:d}.", "abc");

After that I didn't get any compiler error or warning.
Here is the link.

My experiments locally on MSVC with recent master show the same: I need to use FMT_FORMAT macro to enable compile-time checks, which is not available in <fmt/core.h>

[vitaut]

Quoting the {fmt} docs: https://fmt.dev/latest/api.html#core-api:

The fields are replaced with formatted arguments in the resulting string. format_string is a format string which can be implicitly constructed from a string literal or a constexpr string and is checked at compile time in C++20.

There is no such thing as FMT_FORMAT. If you mean FMT_STRING, it's a legacy API and no longer needed.

[stgatilov]

I took MSVC2022 and tried with /std:c++20 switch.
Yes, <fmt/core.h> detects type errors during compilation.

In the end, my confusion came from two separate issues:

1. Compile-time checks work with <fmt/core.h> but require C++20. Without C++20, they only work with FMT_STRING from <fmt/format.h>.
2. fmt::format_to_n is very slow to compile with <fmt/format.h>, regardless of availability of C++20, FMT_STRING and compile-time checks. But it compiles fast with <fmt/core.h>, and replacing it with ordinary fmt::format compiles fast even with <fmt/format.h>.

---

Speaking of slow fmt::format_to_n, here is my test code (hopefully, most of it is not important):

qq.cpp:

#include "stdafx.h"
std::string qq(int a, int b) {
    char buff[1000] = {0};
    fmt::format_to_n(buff, 900, "{:f} + {:f} = {:f}\n", a + 0.0, b + 0.0, a + b + 0.0);
    return buff;
}

stdafx.h:

#include <fmt/format.h>
#include <string>

stdafx.cpp:

#include "stdafx.h"

build script (second line is slow):

cl stdafx.cpp /std:c++20 /O2 /EHsc /I. /Yc
cl qq.cpp /std:c++20 /O2 /EHsc /I. /Yu"stdafx.h"

[vitaut]

Please note that format_to_n is part of the core API too: https://fmt.dev/latest/api.html#_CPPv4I0DpEN3fmt11format_to_nE18format_to_n_resultI8OutputItE8OutputIt6size_t13format_stringIDp1TEDpRR1T, so you should include fmt/core.h, not fmt/format.h. Godbolt: https://godbolt.org/z/dv95K1s1Y

[vitaut]

BTW 48327a8 fixes a small regression when compiling format_to with fmt/format.h included. It is still recommended to use fmt/core.h but if you don't it won't be too bad. Thanks for bringing this to my attention.

[stgatilov]

Oh yes, this commit definitely explains the difference =)

I simply switched to fmt::format for now.
Measurements showed 34 KB object code and 80 milliseconds single-thread compile time --- that's totally negligible.

Sorry for negative feedback, and thank you for your help!