Date: Thu, 30 Mar 2023 12:18:33 +0100
On Thu, 30 Mar 2023 at 10:26, Alejandro Colomar via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On 3/30/23 10:58, David Brown via Std-Proposals wrote:
> > On 29/03/2023 17:18, Arthur O'Dwyer via Std-Proposals wrote:
> >
> >> A new `uintmax_extended_t` (or whatever) can communicate properly from
> >> the get-go: "Hey! This type will change in the future! Don't build it
> >> into your APIs!"
> >> But then, if you aren't using this type in APIs, then where /*are*/ you
> >> using it, and why does it need to exist in the standard library at all?
> >>
> > That, I think, is the key point - /why/ would you want a "maximum size
> > integer type" ?
>
> For example to printf(3) an off_t variable.
>
That already works.
#include <iostream>
#include <print>
void print_off(off_t o)
{
std::cout << o << '\n';
std::print("{}", o);
}
Or to write a [[gnu::always_inline]] function that accepts any integer.
>
Just write a template, no need for always_inline, that's irrelevant.
Or to write a type-generic macro that handles any integer.
>
Just write a template.
This is the isocpp.org list remember, none of those are good reasons for
C++.
>
> The addition of functions that handle [u]intmax_t was the design mistake.
> If they had been added as macros, we wouldn't be discussing ABI issues,
>
We'd be discussing what a horrible mistake it was to define them as macros,
so you can't use those names ever, in any scope.
> because macros don't have ABI. Of course, the problem is that _Generic(3)
> was only added in C11, but intmax_t was added in C99, so they had to do it
> as functions. History sucks.
>
> Still, I think the reform that has been done to make intmax_t be the
> widest standard integral type (or however they call it technically) (as
> opposed to the widest integral type including extended ones) is that it
> should be optimal for printing most libc variables of weird types such as
> id_t or off_t. And that can have a fixed ABI, because anyway, I don't
>
Like I said earlier in the thread, intmax_t is the maximum width integer
that is supported by libc APIs like std::div and printf conversion
specifiers. It's not the maximum width integer type that exists on the
platform (because that might change, depending on the compiler flags, the
target CPU, the compiler release, etc.)
std-proposals_at_[hidden]> wrote:
>
>
> On 3/30/23 10:58, David Brown via Std-Proposals wrote:
> > On 29/03/2023 17:18, Arthur O'Dwyer via Std-Proposals wrote:
> >
> >> A new `uintmax_extended_t` (or whatever) can communicate properly from
> >> the get-go: "Hey! This type will change in the future! Don't build it
> >> into your APIs!"
> >> But then, if you aren't using this type in APIs, then where /*are*/ you
> >> using it, and why does it need to exist in the standard library at all?
> >>
> > That, I think, is the key point - /why/ would you want a "maximum size
> > integer type" ?
>
> For example to printf(3) an off_t variable.
>
That already works.
#include <iostream>
#include <print>
void print_off(off_t o)
{
std::cout << o << '\n';
std::print("{}", o);
}
Or to write a [[gnu::always_inline]] function that accepts any integer.
>
Just write a template, no need for always_inline, that's irrelevant.
Or to write a type-generic macro that handles any integer.
>
Just write a template.
This is the isocpp.org list remember, none of those are good reasons for
C++.
>
> The addition of functions that handle [u]intmax_t was the design mistake.
> If they had been added as macros, we wouldn't be discussing ABI issues,
>
We'd be discussing what a horrible mistake it was to define them as macros,
so you can't use those names ever, in any scope.
> because macros don't have ABI. Of course, the problem is that _Generic(3)
> was only added in C11, but intmax_t was added in C99, so they had to do it
> as functions. History sucks.
>
> Still, I think the reform that has been done to make intmax_t be the
> widest standard integral type (or however they call it technically) (as
> opposed to the widest integral type including extended ones) is that it
> should be optimal for printing most libc variables of weird types such as
> id_t or off_t. And that can have a fixed ABI, because anyway, I don't
>
Like I said earlier in the thread, intmax_t is the maximum width integer
that is supported by libc APIs like std::div and printf conversion
specifiers. It's not the maximum width integer type that exists on the
platform (because that might change, depending on the compiler flags, the
target CPU, the compiler release, etc.)
Received on 2023-03-30 11:18:49