C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::big_int

From: Jan Schultke <janschultke_at_[hidden]>
Date: Fri, 3 Apr 2026 16:05:58 +0200
On Fri, 3 Apr 2026 at 15:59, Matt Borland <matt_at_[hidden]> wrote:

> > Another thought I had when it comes to std::big_int procedurally is that
> we may want to walk before we run.
> >
>
> > Tiago's P3161R4 has been in the pipeline for a long time, and adds
> prerequisite functions such as std::mul_wide. Widening multiplication is
> necessary to implement multi-precision multiplication in std::big_int.
> Similarly, Daniel Towner provides funnel-shifting in P4010R0, which is
> necessary to implement multi-precision bit-shifting.
> >
>
>
> I'm not sure operations on std::big_int would be in scope. In the
> std::mul_wide case the function would need some manner of taking two arrays
> of limbs (since std::big_int doesn't exist), and then applying a variety of
> algorithms depending on the bit counts (e.g. Karatsuba, Toom-Cook, etc).
> P3161R4 reads to me that the goal is to provide thin wrappers around
> intrinsics rather than implement true arbitrary precision. Having
> std::add_carry would be convenient, but certainly not show stopping.
>

Yeah, P3161 provides the low-level operations that are used to implement
those higher-level algorithms such as Karatsuba. Regardless of which
high-level algorithm you choose, you reduce the instruction count
significantly if you can compute the high bits of a multiplication at the
same time as the low bits. If you didn't have the standard operation such
as std::mul_wide, you would implement that yourself in terms of __int128
multiplication or something else, so there's no way around it. It's
somewhere in the implementation of std::big_int.

Received on 2026-04-03 14:06:15