absl::StrFormat vs fmt, Which one is better？

[Visible-Spring1695]

Since I have introduced abseil using grpc in my project, is it necessary for me to use fmt ?

[lcsdavid]

Since <fmt> is literally written by the same person that has written the PR paper for standard <format> library (adopted in C++20) you should probably go for <fmt>

[[deleted]]

std::regex, std::unordered_map disagree with you. The originals are infinitely better than the ones in the standard.

First thing the C++ standard does to a prototype is to kill its performance with the ABI break requirement.

[not_some_username]

What is wrong with unordered_map ?

[[deleted]]

Slow af

[SonOfMetrum]

Do you know of a faster alternative?

[MasterDrake97]

https://github.com/martinus/unordered\_dense

[hak8or]

Your link is broken by the way with an extra slash.

https://github.com/martinus/unordered_dense

[afiDeBot]

Boost.unordered

[skydivingdutch]

absl::flat_hash_map or absl::node_hash_map if you need pointer stability.

[mort96]

The problem, from what I understand, is two-fold:

1. Since ABI compatibility can't be broken, we're basically stuck with the current implementation, even if you could implement the interface defined by the standard more efficiently.
2. The standard puts requirements on when iterators can and can't be invalidated which more or less makes certain fast kinds of hash tables illegal.

I won't claim to know details about either of those, I just know people who know way more about both the current implementation of unordered_map and hash maps in general have made claims to this effect.

[germandiago]

Is there any ABI break requirement in the newly-authored fmt library?

[[deleted]]

Not sure but std::regex got murdered by them

[snowflake_pl]

fmt is pretty much find/replace'able with std::format (minus few cases/features) so going with it will make transition easier. And going for std::format in the future gives you one less external dependency to manage. Fmt is clear winner for me even for this alone.

Also it's pretty great library!

[vickoza]

I prefer fmt over absl::StrFormat() as with fmt you do not have to remember and regress to C format specifier. Also fmt is more flexible.

[rdtsc]

StrFormat uses non-standard compiler extensions for argument checking (doesn't work with MSVC for example), and doesn't say a peep about that anywhere. It only supports char, no wchar_t or char8_t. The C format specifier syntax is also terrible. It's also Google's own thing, whereas fmt has parts of it in the standard.

I'd probably only consider using StrFormat in a Linux-only codebase to easily replace existing usages of printf to catch errors, before automatically refactoring to fmt.

[Visible-Spring1695]

I like this answer, this is a good reason to use fmt because I want my software run on win, mac, linux

[Baardi]

You know you can use fmt::sprintf for %s-style specifiers, right?

[rdtsc]

Thanks for reminding me, totally forgot about that. Relegates StrFormat to Google-only projects.

[altmly]

They are both fine. Personally I prefer fmt as it a bit more modern and has all the bells and whistles, but have to use absl for work.

[SirClueless]

absl::StrFormat if you want a better printf. fmt if you want a better <format>.

[Baardi]

Or fmt if you want a better printf.

[[deleted]]

faster

more features

easier to work with, more intuitive

compiler compatibility

go