Hi,

On 2026-02-16T12:16:31+0100, Bo Persson via Std-Proposals wrote:
> On 2026-02-16 at 11:09, Tymi via Std-Proposals wrote:
> > When trying to get the smallest integral type of N bits, we either have
> > to ensure N is one of 8, 16, 32 or 64, or trust the implementation to
> > have a least/fast type for our width, which is often not the case.
> >
> > That's why I propose a way to standardise making least width integers
> > and fast size integers within the library:
> >
> > A sample interface
> > std::make_least<N> => a signed integer with at least N bits in width
> > std::make_fast<N> => a signed integer with at least N bits in width
> > that's also the fastest size for the given width
> > std::make_uleast<N> => an unsigned integer with at least N bits in width
> > std::make_ufast<N> => an unsigned integer with at least N bits in width
> > that's also the fastest size for the given width
> >
> > I'm only concerned about signed/unsigned, but that's ultimately the
> > interface design and can/should be changed.
>
> Before adding more "fast" types to the standard, we ought to define *what*
> should be fast.

Indeed. I was wondering if we should actually remove the "fast" types
we currently have in the standard. They set ABI, so they're not even
necessarily fast $today; they were the fast types at some point in the
past, for some likely-arbitrary reasons.


Have a lovely day!
Alex

>
> If you do many computations on a small number of values, that might be
> faster if you make the variables the "natural" size of the system (int?).
>
> If you store large arrays of such values, it might be more efficient to have
> them compact to reduce cache effects.
>
> Which "fast" should the standard prefer?
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
<https://www.alejandro-colomar.es>