为什么fmt库不是头文件库？

Question

我知道可以在头文件中使用fmt格式化库：

如何在头文件中使用 fmt 库？

但是，为什么它不只是头文件而已呢？也就是说，在非头文件模式下使用它有什么好处？

- einpoklum

Answer 1

主要原因是建立速度，正如其他人已经正确指出的那样。例如，使用静态库编译（默认情况下）比使用仅头文件编译快约2.75倍：

#include <fmt/core.h>

int main() {
  fmt::print("The answer is {}.", 42);
}

% time c++ -c test.cc -I include -std=c++11
c++ -c test.cc -I include -std=c++11  0.27s user 0.05s system 97% cpu 0.324 total

% time c++ -c test.cc -I include -std=c++11 -DFMT_HEADER_ONLY
c++ -c test.cc -I include -std=c++11 -DFMT_HEADER_ONLY  0.81s user 0.07s system 98% cpu 0.891 total

在仅由头文件构成的库中，实现细节和依赖关系会泄露到使用它们的每个翻译单元中。

- vitaut

Answer 2

像 vformat 这样的函数不是模板。将它们放在头文件中并减慢整个编译过程毫无意义。我想这就是背后的原理。 fmt 库似乎非常关心编译时间。

- Ayxan Haqverdili

Answer 3

在非头文件模式下使用它的好处是什么？

我不是作者，所以无法代表他们发言。但我可以告诉您不采用头文件方式的优点。

·允许库的头文件不包含特定于系统的头文件，这些头文件通常存在问题，例如定义名称可能与用户程序冲突的宏（例如windows.h可能定义与某些标准库函数重叠的宏）。实际上，Libfmt确实利用了这个机会。在头文件方式下省略了特定于操作系统的功能，除非我弄错了。

·非内联函数通常允许快速重新构建，以便在实现更改时提高效率。这对于库开发人员非常重要，他们可能经常这样做。如果库经常更新，这也可能对用户有帮助。随着库的增长，这一点变得越来越重要。在无限制的模板代码的情况下无法利用此优势。对于Libfmt来说，大多数这些条件可能都属于“不太相关或无法利用”的范畴，这可能是为什么它首先提供头文件的选项的原因。

- eerorika