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
Safety: the library is fully type safe, errors in format strings can be
reported at compile time, automatic memory management prevents buffer overflow
errors
Ease of use: small self-contained code base, no external dependencies,
permissive MIT license
Portability with
consistent output across platforms and support for older compilers
Clean warning-free codebase even on high warning levels such as
-Wall -Wextra -pedantic
Locale-independence by default
Optional header-only configuration enabled with the FMT_HEADER_ONLY macro
{fmt} is the fastest of the benchmarked methods, ~35% faster than printf.
The above results were generated by building tinyformat_test.cpp on macOS
10.14.6 with clang++ -O3 -DNDEBUG -DSPEED_TEST -DHAVE_FORMAT, and taking the
best of three runs. In the test, the format string "%0.10f:%04d:%+g:%s:%p:%c:%%\n"
or equivalent is filled 2,000,000 times with output sent to /dev/null; for
further details refer to the source.
{fmt} is up to 20-30x faster than std::ostringstream and sprintf on
floating-point formatting (dtoa-benchmark)
and faster than double-conversion and
ryu:
Compile time and code bloat
The script bloat-test.py
from format-benchmark
tests compile time and code bloat for nontrivial projects.
It generates 100 translation units and uses printf() or its alternative
five times in each to simulate a medium sized project. The resulting
executable size and compile time (Apple LLVM version 8.1.0 (clang-802.0.42),
macOS Sierra, best of three) is shown in the following tables.
Optimized build (-O3)
Method
Compile Time, s
Executable size, KiB
Stripped size, KiB
printf
2.6
29
26
printf+string
16.4
29
26
iostreams
31.1
59
55
{fmt}
19.0
37
34
Boost Format
91.9
226
203
Folly Format
115.7
101
88
As you can see, {fmt} has 60% less overhead in terms of resulting binary code
size compared to iostreams and comes pretty close to printf. Boost Format
and Folly Format have the largest overheads.
printf+string is the same as printf but with extra <string>
include to measure the overhead of the latter.
Non-optimized build
Method
Compile Time, s
Executable size, KiB
Stripped size, KiB
printf
2.2
33
30
printf+string
16.0
33
30
iostreams
28.3
56
52
{fmt}
18.2
59
50
Boost Format
54.1
365
303
Folly Format
79.9
445
430
libc, lib(std)c++ and libfmt are all linked as shared libraries to
compare formatting function overhead only. Boost Format is a
header-only library so it doesn't provide any linkage options.
Running the tests
Please refer to Building the library for the instructions on how to build
the library and run the unit tests.
Benchmarks reside in a separate repository,
format-benchmarks,
so to run the benchmarks you first need to clone this repository and
generate Makefiles with CMake:
If you are aware of other projects using this library, please let me know
by email or by submitting an
issue.
Motivation
So why yet another formatting library?
There are plenty of methods for doing this task, from standard ones like
the printf family of function and iostreams to Boost Format and FastFormat
libraries. The reason for creating a new library is that every existing
solution that I found either had serious issues or didn't provide
all the features I needed.
printf
The good thing about printf is that it is pretty fast and readily available
being a part of the C standard library. The main drawback is that it
doesn't support user-defined types. printf also has safety issues although
they are somewhat mitigated with __attribute__ ((format (printf, ...)) in GCC.
There is a POSIX extension that adds positional arguments required for
i18n
to printf but it is not a part of C99 and may not be available on some
platforms.
iostreams
The main issue with iostreams is best illustrated with an example:
Matthew Wilson, the author of FastFormat, called this "chevron hell". iostreams
don't support positional arguments by design.
The good part is that iostreams support user-defined types and are safe although
error handling is awkward.
Boost Format
This is a very powerful library which supports both printf-like format
strings and positional arguments. Its main drawback is performance. According to
various benchmarks, it is much slower than other methods considered here. Boost
Format also has excessive build times and severe code bloat issues (see
Benchmarks).
FastFormat
This is an interesting library which is fast, safe and has positional arguments.
However, it has significant limitations, citing its author:
Three features that have no hope of being accommodated within the
current design are:
Leading zeros (or any other non-space padding)
Octal/hexadecimal encoding
Runtime width/alignment specification
It is also quite big and has a heavy dependency, STLSoft, which might be too
restrictive for using it in some projects.
Boost Spirit.Karma
This is not really a formatting library but I decided to include it here for
completeness. As iostreams, it suffers from the problem of mixing verbatim text
with arguments. The library is pretty fast, but slower on integer formatting
than fmt::format_to with format string compilation on Karma's own benchmark,
see Converting a hundred million integers to strings per second.
The Format String Syntax
section in the documentation is based on the one from Python string module
documentation.
For this reason the documentation is distributed under the Python Software
Foundation license available in doc/python-license.txt.
It only applies if you distribute the documentation of {fmt}.
Maintainers
The {fmt} library is maintained by Victor Zverovich (vitaut) and Jonathan Müller (foonathan) with contributions from many other people.
See Contributors and
Releases for some of the names.
Let us know if your contribution is not listed or mentioned incorrectly and
we'll make it right.
请发表评论