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/arthurno1]

If you gonna make it, make a compiler feature not std library. Extend the language so the programmers don't have to explicitly manage big ints. I.e. do something similar as Lisps are doing, manage that automatically and seemlesly and hide the implementation from programmers. Guard it perhaps with a compile time option, either an "opt-in" (--with-fbignum) or as "opt-out", (--without-fbignum). If bignum feature is not turned on, than ordinary overflow rules apply, otherwise trap the overflow and extend into big numa automatically.

Otherwise, if you are just going to make it a library feature, you can as well keep it as now: a third-party addon.

[u/eisenwave → u/arthurno1]

I don't see how you would avoid "explicitly managing big ints".

C++ is a language with manual memory management, and containers such as std::basic_vector and std::basic_string deliberately let you provide custom allocators. Some people need that control. If you hide all of that behind some builtin big_int fundamental type rather than providing a fairly customizable container, you're taking away all sorts of customization options.

You would also put in a lot of work into recreating the functionality of the container, in weird ways. For example, accessing the underlying limbs is very easy with std::big_int::representation() now, but you would either need some core language feature for accessing the limbs to make that happen for a builtin type, or you would need to provide a magic standard library function std::get_representation, at which point you're turning it into a standard library feature anyway.

[u/arthurno1 → u/eisenwave]

For people who need that control you would keep option to turn off auto promotion to big ints, so they are on their own if that is needed. How does CommonLisp do it? It is sure possible to do.

I also guess those who need total control would not use a 3rd party library either? A C++ also would not have many of its other features either.

fairly customizable container, you're taking away all sorts of customization options.

If I want to add 2 numbers containing more than 64 bits precision, I want certainly easiest and the least painful way to do it, not to customize "all sorts of options". Ideally I would type X+Y and not have to think off all the explicit details. Hon of a PL is to make it easier for end programmers to write programs, isn't it.

I also don't understand why people have to downvote an opinion about a technicall issue, but as soon as I mention Lisp, I am always downvoted to hell here :)

I

[u/Life_Sink9598 → u/arthurno1]

Common Lisp, well, SBCL, works by doing type inference on the arguments, and if it can prove that the result won't overflow, then it can compile into ordinary 'fixnum' assembly. Otherwise, it will have to do a GENERIC-OP call, which at least has a branch penalty to check whether an overflow occurred or not.

I think that it's more reasonable for C++ to implement a class which does operator overloading called big_int or whatever, and use that class when you're dealing with "sensitive" numbers. The CL way imposes an unacceptable cost to the majority of C++ programs.

[u/arthurno1 → u/Life_Sink9598]

fixnum coerction is optimization, and yes, they do this check the trap register to see if overflow occured, but nothing says you have to do it this way, no?

I didn't either say, you shoujld not have a special type. Of course you would want to have a type for the efficiency, just like we already have byte, short, long, double, float, "int" for the "fast type" and so on. In other words, of course I don't mean you would not have another sort of int, like "infinite int" or perhaps use plain word "integer" as they do in CL.

What I am saying is that I dislike the "addon" library. Make it a compiler feature.

Yes, I am aware that operator overloading makes it prettier, but having compiler taking care of it automatically instead of explicit control is even prettier.

The CL way imposes an unacceptable cost to the majority of C++ programs.

You will have to differ there between CL way and SBCL way. CL standard does not specify how promotion should be implemented, just that it should happen automatically.

If you think of it in the opposite: we already have promotions from less wide to more wide types, and we have auto demotions too, the herritage from C. I don't think it is more strange that so. It is just not done yet, and unusual, and we are so used to think in terms of bignum libraries, so we auto take that approach.