Date: Sun, 30 Mar 2025 09:29:12 +0100
On Sun, 30 Mar 2025, 04:41 Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> On Saturday, 29 March 2025 17:04:46 Eastern Daylight Time Jonathan Wakely
> via
> Std-Proposals wrote:
> > On what platform in existence today does a type that's at least 32 bits
> > promote?
>
> None. It would need to be a platform with an int probably of 64 bits,
> which
> doesn't exist. A 36-bit int platform *probably* uses the 36-bit integer as
> the
> "fast 32-bit" - if it has an exact 32-bit type, it's probably slower than
> the
> native 36-bit.
>
> However, maybe Frederick is being fooled by the fact that the
> uint_fast32_t on
> x86-64 Linux is "unsigned long" - that is, the same type as uint64_t and
> uint_fast64_t. Someone decided that 64-bit on x86-64 was "faster" than
> 32-bit
> and now we're stuck with that ABI.
>
Right, that's why I consider them mostly useless.
But I don't see why that would have anything to do with promotion.
They're is certainly rationale for integer types that don't promote (C23
_BitInt types don't promote, for example, so C realised the need) but the
over-engineered typedef in the original post is not rationale.
> A gotcha with this is that std::mt19937, which is required by the standard
> to
> use uint_fast32_t, is actually twice as big as it needs to be.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> On Saturday, 29 March 2025 17:04:46 Eastern Daylight Time Jonathan Wakely
> via
> Std-Proposals wrote:
> > On what platform in existence today does a type that's at least 32 bits
> > promote?
>
> None. It would need to be a platform with an int probably of 64 bits,
> which
> doesn't exist. A 36-bit int platform *probably* uses the 36-bit integer as
> the
> "fast 32-bit" - if it has an exact 32-bit type, it's probably slower than
> the
> native 36-bit.
>
> However, maybe Frederick is being fooled by the fact that the
> uint_fast32_t on
> x86-64 Linux is "unsigned long" - that is, the same type as uint64_t and
> uint_fast64_t. Someone decided that 64-bit on x86-64 was "faster" than
> 32-bit
> and now we're stuck with that ABI.
>
Right, that's why I consider them mostly useless.
But I don't see why that would have anything to do with promotion.
They're is certainly rationale for integer types that don't promote (C23
_BitInt types don't promote, for example, so C realised the need) but the
over-engineered typedef in the original post is not rationale.
> A gotcha with this is that std::mt19937, which is required by the standard
> to
> use uint_fast32_t, is actually twice as big as it needs to be.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-03-30 08:29:29