On Sun, 23 Aug 2026 at 08:45, Nevin Liber via Liaison <
liaison_at_[hidden]> wrote:

>
>
> On Sun, Aug 23, 2026 at 12:25 AM Jan Schultke via Liaison <
> liaison_at_[hidden]> wrote:
>
>> When working on a draft of P4444 std::big_int (
>> https://isocpp.org/files/papers/D4444R0.html#std::uint_multiprecision_t),
>> we've stumbled upon the problem that C++ does not yet have a "word type"
>> that would be suitable as the "limb type" for multiprecision.
>>
>
> Given that big int libraries have existed for a while, why is there a
> pressing need now?
>

There is no "pressing need" in terms of timing. It's simply something
people have tried to standardize as early as 2004 because it has
always been and will always be immensely useful. The paper's motivation
section goes into great detail as to why std::big_int should be in the
standard.


>
>
>> That is, the largest possible unsigned integer type that has native
>> arithmetic support.
>>
>
> What keeps this from suffering the same problems as intmax_t; i.e., once
> baked into ABIs it is effectively impossible to change when the underlying
> hardware does.
>

"When the underlying hardware does" is a pretty unlikely scenario, and I'm
not sure if it has ever happened in the history of computing in a way that
would change a std::uint_maxfast_t type. This would require providing new
arithmetic instructions with greater width, on an existing architecture,
without creating a new ABI. For example, it would happen when providing
128-bit arithmetic support on x86_64. Usually, that doesn't happen, and the
historic jumps from 32-bit to 64-bit came with completely new ABIs.

The issue with std::intmax_t has always been much simpler and dumber, up
until C23 fixed it. You could not add a new __int128 extended integer type
as an implementation without also changing std::intmax_t. std::intmax_t
would force you into an ABI break even if nothing about the hardware
changed.


> I'm thus interested in standardizing a type alias in <stdint.h> that has
>> the size. In P4444, we call that uint_multiprecision_t, but that's perhaps
>> not universal enough. Names like "uint_maxfast_t" or "uint_word_t" come to
>> mind.
>>
>
> I was never really enamoured with the int_fast*N*_t types, since they
> don't guarantee, well, anything other than being at least *N* bits wide.
> This doesn't seem any different, because "fast" isn't clearly defined.
>

It is different. The wording we have in
https://isocpp.org/files/papers/D4444R0.html#big%2eint%2esyn recommends it
"should be chosen to have the greatest possible width so that an arithmetic
expression ([expr.pre]) performed on operands of the type corresponds to a
single instruction in the execution environment."

That's a lot more specific than "fast".



> What are your thoughts?
>
>
> That we are re-inventing int, badly. The original *int*ention of int was
> that it be the "fastest" type on the target, whatever that means.
>

Yeah well, that original intention was lost 20 years ago or something. I
think the idea of int being the native integer type was always destined to
fail because it's clunky to leave a hole in the standard integer types,
where short is 16-bit and int is 64-bit. Or perhaps, short would be 32-bit,
leaving no 16-bit type. It would have also made long and long long
basically useless on 64-bit and sparked a 64-bit dialect of C++ where
people use int only, avoiding any of these wider types.

On 128-bit architectures like RV128, it would have become even more
comical, with short presumably still being 16-bit and int, long, and long
long all being 128-bit.

You would inevitably need to patch the holes in the standard integers with
extended integer types or add more standard integer types, and neither
seems like a desirable outcome.