On Fri, 21 Aug 2026 at 17:14, Bjorn Reese via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

Yes, and this would bloat the std::big_int container considerably.
std::inplace_vector and std::vector make for 5 pointers of size combined,
whereas our std::big_int is only 2 pointers large.

Overall, it's pretty unclear what you stand to gain. Allocating is not the
hard part, but managing the transition between the small values and
dynamically allocated values. It would perhaps be possible to have a
std::small_vector type wrapped by std::big_int, but that still doesn't let
you do things like pack the sign bit into the size to save space, so you
would at least waste one pointer of size.

There are also domain-specific considerations like the fact that a 31-bit
size already gets you 137 billion bits, which is more than anyone will
realistically need, so it is wasteful to use a full 64-bit size.

Anyway, it's a fair and good question to ask.