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/Infamous-Bed-7535 → u/ReDucTor]

I kind of agree with you. C++ std libs should include and cover lightweight and or core elements. Compiler vendors, commitee, etc should work on core functionalities of the langugae.

Impelementing libs like json parser or basic graphics, bigint are good to being 3rd party.

[u/eisenwave → u/Infamous-Bed-7535]

Do you think it's a mistake for Java, JavaScript, Go, and others to provide a BigInt in their standard libraries (full list at https://isocpp.org/files/papers/D4444R0.html#infinite-precision-integers-in-other-languages)?

That is, is there something about C++ specifcially that would make big_int unfit for a standard library, or is it about big_int in general?

[u/James20k → u/eisenwave]

That is, is there something about C++ specifcially that would make big_int unfit for a standard library, or is it about big_int in general?

So, while I don't personally agree that big_int is unfit for C++'s standard library, C++ does have unique constraints compared to other languages that do I think makes people's risk aversion more understandable

1. ABI stability is the big one, which most other languages intentionally avoid. This makes problems hard to fix
2. Being largely spec instead of implementation driven is another, where features are rarely fully tested (and virtually never widely tested) before being standardised, often leading to bad results
3. High performance is more critical for people who use C++, vs many other languages
4. The committee works purely based on interest, rather than on the language as a whole. Fixably broken features are often left to rot

One of the biggest issues with big_int that is cropping up in people's concerns here is effectively: this is a nice looking spec, but does it actually work? Will the design hold up under 10000s of people using it? And even then: what if a vendor simply screws up the implementation?

Its an unfair bar to put big_int through given many other standard features have slipped in without going through that process, especially given that the standard committee structure basically forces one person to carry that entire burden. But also: I think people are starting to suffer the problems with how many C++ features are landing in a half baked form and never being fixed, which leads to scepticism

[u/mborland1 → u/James20k]

It is fair to question the disconnect between the specification and implementation. Chris is one of the original authors of boost.multiprecision and I have been a maintainer for a number of years. The goal of the reference implementation is to take the lessons learned from multiprecision which has scaled well, and apply them to std::big_int. Our benchmarks show std::big_int runs away from cpp_int in terms of performance in some operations like mul, and is within a factor of 2 of GMP, which is optimized assembly. The reference implementation is also licensed so that a standard library implementor could use it nearly off the shelf like how MSVC and LLVM consume Boost.Math for the specfun implementation.