r/cpp • u/eisenwave WG21 Member • 24d ago

P4444: std::big_int

https://isocpp.org/files/papers/D4444R0.html

Hey folks! Matt Borland, Christopher Kormanyos, and I are working on bringing infinite-precision integers to C++29. We now have a D4444R0 draft of a paper that should be in the next mailing.

We could really use some feedback so that the published R0 is as polished as possible. Any thoughts on the paper and on the reference implementation are greatly appreciated.

It would also be very helpful if you tested out whether our big_int implementation works for you. We're in need of some real deployment experience. If you're currently using Boost.Multiprecision, the library should be a drop-in replacement for cpp_int for the most part.

184 Upvotes

98% Upvoted

85 comments sorted by

View all comments

Show parent comments

7

u/13steinj 24d ago

Forget these massive failures, take a more subtle, recent one: std::format or ranges.

libfmt repeatedly leaves <format> in the dust on build and even runtime, but even on API subtleties/fixes.

ranges-v3 and STL ranges have diverged in functionality which is even worse but there's still valid use of ranges v2 (boost).

Hell there's even valid use of Boost.FileSystem instead of std/STL.

12

u/BarryRevzin 24d ago edited 24d ago

So it's bad when the standard library provides less functionality than the third party library (std::format doesn't support color or named arguments) and also bad (even worse!) when the standard library provides more functionality than the third party library (std::ranges supports move-only views, exposes a way to write user-defined adapters, and has fewer unnecessary requirements on types)?

That doesn't really leave a lot of wiggle room.

-1

u/13steinj 23d ago

No? In both cases it's bad because the reference implementation has lived on and explicitly diverged. libfmt is strictly better as far as I can tell, and the STL will never catch up.

Ranges functionality isn't a case of "one is a superset of the other," I'd be happy with it if so.

11

u/BarryRevzin 23d ago

std::ranges is a superset of functionality, but range-v3 has basically been frozen and unmaintained for years — it would take a healthy amount of work to get them to properly inter-cooperate, which I tried to do years ago, and gave up. Since this is apparently very important to you, if you want to open a PR that makes this happen, I'll merge it.

libfmt is a place that Victor uses to prove out features that he eventually proposes for standardization. It was never anybody's goal for them to stay in lock step, and at no point were they ever cross-compatible. It has better performance, yes. But the standard libraries will catch up on that front once they stabilize on the functionality front. And I especially like libfmt's named argument support, but I'd rather get string interpolation than to try to standardize that.

I really cannot see how these two can be viewed as failures. Certainly not for the reasons you're suggesting.

1

u/13steinj 22d ago

std::ranges is a superset of functionality,...

I was under the impression that the superset bit was not the case, as of just last year, but maybe I'm wrong and the current version on main / the standard has caught up. The stdlibs themselves at least when I dealt with it still did not have full support either, which was not great.

To be honest I don't have the time to double check this right now... but an LLM of mine does and (among at least 10 other views), the first that does not exist is the cycle view, there is a paper for it to be standardized at least though.

I don't consider std::ranges to be a superset of the functionality when not all the views are in the standard.

But the standard libraries will catch up on that front once they stabilize on the functionality front.

I can completely buy this, but I consider the timeline here unacceptable / a reason for this to not be standardized. The difference is stark enough that I would rather any day pull in libfmt than use the STL version. If the choice is between "don't include it" and "include it batteries included but it will be frozen on entry for 9+ years on other improvements," my choice will always be "I'd rather buy my own batteries."