> On 8/19/26 11:23, Jan Schultke via Std-Proposals wrote:
>

> > 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
>

> The design of basic_bit_int uses an allocator and small object
> optimization.
>

> Have you considered a design where basic_big_int takes a container
> instead? The allocator can then be replaced by std::vector, and the
> small object optimization by std::inplace_vector.
>


Even if the user provided a container of std::vector<limb_type> they would also need to provide the scratch pads for multiplication and division. For medium size values (400-4500 limbs) Toom-Cook algorithms [1] we use a scratchpad of up to 6x the size of the operands, but these operations are at least done in terms of limb_type. For large numbers (4500+ limbs) we use a variant of the Schönhage-Strassen algorithm [2] which needs scratch workspaces for both doubles and uint64_t, not just limb_types. Right now we implement this all using rebind_alloc on the user provided allocator for our bump allocated scratch pads. I'm not sure how we would work around this besides asking the user to provide a number of different containers, which would be rather unergonomic, or providing an allocator anyway in addition to the container(s).

Matt

[1] https://en.wikipedia.org/wiki/Toom–Cook_multiplication
[2] https://en.wikipedia.org/wiki/Schönhage–Strassen_algorithm