-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use fmt
C++ library? OPINIONS WANTED!
#400
Comments
This is new to me, so I don't have strong opinions on it. However, I use python f-strings, and I prefer its syntax over |
I also don't have a strong opinion, but I would tend to agree with John. The Python print formatting is very useful, and as the code gets increasingly broken down into subdirectories to make compilation faster I think that compiling as a potential issue will be less of a problem. Also, if this is the way that the language is going then we should adopt it sooner rather than later! |
Strong support for {fmt}! I have never been quiet about my dislike of iostreams. |
I have no objection to people using fmt in principle. But keep in mind this is a parallel code: If you're guaranteed to be doing terminal I/O from the root chare, I think I would recommend deferring widespread use of |
This is an idea I had a few years back. I've gone back and forth on it a lot (I'm torn about whether the benefits outweigh the negatives... it seems a little close). I figured that I would throw it out there to see what people think
The problem
Using data to format strings in C++ is unsatisfactory. Historically, there are 2 approaches:
printf
-functions. (what we currently do)std::cout
orstd::cerr
Of these 2 options I'm generally a fan of the first since it is far less verbose and the data-formatting syntax is fairly "standard". However, the major drawback is that it can't properly handle any non-C primitives (e.g. it handles
const char*
strings, but notstd::string
or a user-defined custom string implementation).The potential solution
The potential solution to is to make use of
fmt
C++ library (docs and GitHub repository). This is an extremely popular library that takes aprintf
-style approach to string formatting. In fact, it is so popular, that it has become part of the standard library (most features were added in C++20, a few more introduced in C++23 and C++26).The basic premise is that it performs formatting based on python's
str.format(*arg, **kwargs)
formatting string. As a basic example, if one wroteThen
s
would hold"This is a float 42.395 and this is an int 42"
.Importantly, it provides:
std::vector
. It also includesstd::string
(and supportingstd::string
is extremely important)1fmt::format_to
function that can be used to avoid heap allocations.I think a major advantage is that in 3 to 6 years (whenever we update to future C++ releases), we could eventually remove
fmt
as a dependency and use the standard library instead (just like we did withboost::filesystem
).Drawbacks
The primary drawbacks is compilation times. I'm most concerned about this. Some compile-time and binary-size benchmarks were done (here). In that benchmark
fmt
takes 3 times longer to compile thanprintf
and produces larger binaries. With that said, at runtime these other benchmarks suggest thatfmt
is generally ~20% faster thanprintf
and an order of magnitude faster at formatting floats.In theory, another drawback is that we're introducing a new dependency. However, I don't think this is a problem in practice.2
Summary
Again, I'm really torn on this. I think it all boils down to the question: "will we use this feature when we transition to C++20 and it becomes part of the standard library?"
I definitely want to hear people's opinions on this topic!
Footnotes
Yes
std::string
has the.c_str()
method which lets it work with normalprintf
. However, there is some "messiness" with making sure that thestd::string
is alive over the course of theprintf
-related function, that comes up when you call.c_str()
on a temporarystd::string
that hasn't been stored in a variable (e.g. iffoo()
allocates and returns a string, then callingfoo().c_str()
may have some weird behavior). I believe that this "messiness" invokes undefined behavior (that may produce desired results on some platforms but not on others) ↩Since
fmt
is small & lightweight and makes use of cmake (with modern practices), we could make Enzo-E's build have the default behavior of automatically downloading and installing it as a part of the build process. In other words, the end-user doesn't need to do anything. The only other dependency-related concern is compiler support (e.g. maybe a particular compiler has issues with it). Since this only uses standard C++ features this shouldn't be a problem. Plus I imagine that any compiler issues have been sorted out given the immense popularity of this library. ↩The text was updated successfully, but these errors were encountered: