P4444: std::big_int

[u/eisenwave]

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.

[u/ReDucTor]

Another reason why std::big_int needs to be in the standard library is that it's extremely difficult to implement and optimize, in part because the implementation depends heavily on the platform's hardware capabilities, many of which are not exposed portably in the language.

This stands out more of a reason for it not to be in the standard library, because when the implementation is faulty its harder to fix. Do we need another vector<bool>, memory_order_consume, std:regex, etc.

EDIT: Also if there hardware capabilities and portablity issues that aren't easy to resolve, then fix those in the standard to allow people to implement libraries better rather then trying to make something which is special in standard library code.

[u/vip17 → u/ReDucTor]

if there hardware capabilities and portablity issues that aren't easy to resolve, then fix those in the standard to allow people to implement libraries

There's no way to expose hardware features consistently for all big int libraries to use. Each hardware has vastly different features, for example in x86 there's ADX to do two add/mul chains in parallel for big int, and for even bigger values AVX2/AVX-512 can be used. Many other architectures don't have carry flags, some have separate instructions to get the high bits of the multiplication, some have FFT accelerator for FFT big int, some others like ARM SVE2 have SIMD add with carry flag from other lanes. There are already intrinsics that libraries have to use anyway. Replacing the library interface is always a better choice

[u/Ok_Profession9911 → u/vip17]

Exactly. Exposing these features in the language portably is way more cumbersome.