C++ Logo


Advanced search

Re: [std-proposals] 128-bit integers

From: connor horman <chorman64_at_[hidden]>
Date: Sat, 10 Feb 2024 20:26:04 -0500
`int_fast128_t` is `int_least128_t` but the fastest type that suits it -
not `int128_t`. You could (in theory) have a faster type that's larger than

On Sat, 10 Feb 2024 at 20:16, Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > IMO, fixed-width multiple precision support for any reasonable bit width
> ought to be provided automatically
> That sounds like _BitInt.
> https://eisenwave.github.io/cpp-proposals/int-least128.html#bit-precise-integers
> explains why I didn't choose to propose it this way. In short, it's a
> massive language change and doesn't even get you 128-bit integers in
> the form you want.
> > The proposal might be better refined by being a bit more specific with
> something along the lines of "int_fast128_t".
> It's unclear to me what the difference between that hypothetical
> approach and my proposal is. Mandatory int_least128_t gets you
> int128_t on the architectures we care about, and that's ultimately
> what matters. This *is* the fast 128-bit integer type.
> > That way, if there isn't a "fast" version that fits in a register (or
> has a corresponding subset of instructions), a warning would be emitted.
> A warning saying what? "You're using int_fast128_t but it's not
> fast!"? How would this be worded, and is this even in the scope of the
> standard? Quality-of-implementation diagnostics generally aren't.
> > That said, I haven't seen an implementation that provides the "least" or
> "fast" variations as anything but aliases.
> They are required to be aliases in the C++ standard. How else would
> you provide them?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2024-02-11 01:26:19