Topic: std::intX_t for arbitrary X if supported by implementation
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 19 Jan 2016 14:57:05 -0800 (PST)
Raw View
------=_Part_3192_2064938710.1453244225590
Content-Type: multipart/alternative;
boundary="----=_Part_3193_1627975106.1453244225591"
------=_Part_3193_1627975106.1453244225591
Content-Type: text/plain; charset=UTF-8
I think that an implementation ought to be allowed to implement the
std::intX_t family of types for any X > 0, to provide for future features,
or weird architectures. For example, std::uint36_t could exist on a PDP-10.
These are what I think should be the rules:
1. It is recommended but not required that at least X = 8, 16, 32, 64 are
supported.
2. It is recommended that a value of X corresponding to the compiler's
integer types exist.
3. These types may be types that are of higher rank than std::[u]intmax_t.
4. The [U]INTX_C macros are optional even for values of X that are
supported by the implementation. (In particular, #ifdef should be false if
the macro isn't supported.)
Cooperation with the C committee would be needed, of course.
The purpose of #3 and #4 is to support the status quo of GCC and Clang for
128-bit types. __int128 on these compilers is of higher rank than
std::intmax_t. These compilers also don't support integer literals of that
size. Thus, typedef __int128 int128_t; is enough for current GCC and
Clang; the INT128_C macro would not exist.
An extension would be a template:
template <int X>
using int_t = /* unspecified */;
with int_t<X> potentially being ill-formed if X doesn't exist.
This could also be supported:
template <int X>
using int_least_t = /* unspecified */;
template <int X>
using int_fast_t = /* unspecified */;
This would support 1 >= X >= largest supported.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3193_1627975106.1453244225591
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that an implementation ought to be allowed to impl=
ement the std::intX_t family of types for any X > 0, to provide for futu=
re features, or weird architectures.=C2=A0 For example, std::uint36_t could=
exist on a PDP-10.<br><br>These are what I think should be the rules:<br><=
br>1. It is recommended but not required that at least X =3D 8, 16, 32, 64 =
are supported.<br>2. It is recommended that a value of X corresponding to t=
he compiler's integer types exist.<br>3. These types may be types that =
are of higher rank than std::[u]intmax_t.<br>4. The [U]INTX_C macros are op=
tional even for values of X that are supported by the implementation.=C2=A0=
(In particular, #ifdef should be false if the macro isn't supported.)<=
br><br>Cooperation with the C committee would be needed, of course.<br><br>=
The purpose of #3 and #4 is to support the status quo of GCC and Clang for =
128-bit types.=C2=A0 __int128 on these compilers is of higher rank than std=
::intmax_t.=C2=A0 These compilers also don't support integer literals o=
f that size.=C2=A0 Thus, typedef __int128 int128_t; is enough for current G=
CC and Clang; the INT128_C macro would not exist.<br><br>An extension would=
be a template:<br><br>template <int X><br>using int_t =3D /* unspeci=
fied */;<br><br>with int_t<X> potentially being ill-formed if X doesn=
't exist.<br><br>This could also be supported:<br><br>template <int =
X><br>using int_least_t =3D /* unspecified */;<br>template <int X>=
<br>using int_fast_t =3D /* unspecified */;<br><br>This would support 1 >=
;=3D X >=3D largest supported.<br><br>Melissa<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_3193_1627975106.1453244225591--
------=_Part_3192_2064938710.1453244225590--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Tue, 19 Jan 2016 15:35:07 -0800
Raw View
doesn't http://en.cppreference.com/w/cpp/types/integer cover most of this?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 19 Jan 2016 15:57:20 -0800 (PST)
Raw View
------=_Part_1810_920259433.1453247840442
Content-Type: multipart/alternative;
boundary="----=_Part_1811_714151040.1453247840442"
------=_Part_1811_714151040.1453247840442
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 19, 2016 at 3:35:25 PM UTC-8, Robert Ramey wrote:
>
> doesn't http://en.cppreference.com/w/cpp/types/integer cover most of
> this?
>
No, the proposal is an extension to what's on that page. For example,
supporting std::uint128_t.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1811_714151040.1453247840442
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, January 19, 2016 at 3:35:25 PM UTC-8, Robert R=
amey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">doesn't <a href=
=3D"http://en.cppreference.com/w/cpp/types/integer" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Ftypes%2Finteger\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNH4MV4TmTjXT_lXKNokXUofqQXZhA';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fen.cppref=
erence.com%2Fw%2Fcpp%2Ftypes%2Finteger\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
4MV4TmTjXT_lXKNokXUofqQXZhA';return true;">http://en.cppreference.com/w=
/<wbr>cpp/types/integer</a> cover most of this?
<br></blockquote><div><br>No, the proposal is an extension to what's on=
that page.=C2=A0 For example, supporting std::uint128_t.<br><br>Melissa<br=
></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1811_714151040.1453247840442--
------=_Part_1810_920259433.1453247840442--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 19 Jan 2016 16:00:03 -0800
Raw View
On Tuesday 19 January 2016 14:57:05 Myriachan wrote:
> I think that an implementation ought to be allowed to implement the
> std::intX_t family of types for any X > 0, to provide for future features,
> or weird architectures. For example, std::uint36_t could exist on a PDP-10.
>
> These are what I think should be the rules:
>
> 1. It is recommended but not required that at least X = 8, 16, 32, 64 are
> supported.
That is already the case. C11 7.20 Integer types says that those types are
optional. But it goes further and makes the 8, 16, 32 and 64-bit typedefs
mandatory if the implementation has those integer types elsewhere.
> 2. It is recommended that a value of X corresponding to the compiler's
> integer types exist.
That's already the case.
> 3. These types may be types that are of higher rank than std::[u]intmax_t.
That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able to
represent any value of any signed/unsigned integer type. Therefore, if
uint128_t exists, then uintmax_t needs to be able to hold all of its values.
> 4. The [U]INTX_C macros are optional even for values of X that are
> supported by the implementation. (In particular, #ifdef should be false if
> the macro isn't supported.)
C99 makes them mandatory if the type of width X exists.
> Cooperation with the C committee would be needed, of course.
>
> The purpose of #3 and #4 is to support the status quo of GCC and Clang for
> 128-bit types. __int128 on these compilers is of higher rank than
> std::intmax_t. These compilers also don't support integer literals of that
> size. Thus, typedef __int128 int128_t; is enough for current GCC and
> Clang; the INT128_C macro would not exist.
Those compilers could be changed to add an extension to the language so they
support literals of that type. 123i128 and 123ui128, for example. The
precedent for this is MSVC's __int64's own literals (i64 and ui64).
They'll also need to change their uintmax_t to be at least 128-bit wide.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Wed, 20 Jan 2016 11:38:18 +0100
Raw View
> An extension would be a template:
>
> template <int X>
> using int_t = /* unspecified */;
>
> with int_t<X> potentially being ill-formed if X doesn't exist.
>
> This could also be supported:
>
> template <int X>
> using int_least_t = /* unspecified */;
> template <int X>
> using int_fast_t = /* unspecified */;
>
> This would support 1 >= X >= largest supported.
If I understand your intention correctly, that template would be used
like this.
constexpr auto bits = get_number_of_bits_i_need();
using my_int = std::int_least_t<bits>;
auto large = my_int {1};
large <<= (bits - 2); // guaranteed not to overflow
I think that this could be highly useful. In fact, I have written
similar type metafunctions myself in the past and having them in the
standard library would be a nice thing.
The type shouldn't be "unspecified", however.
`std::int_t<X>` and `std::uint_t<X>` should be required to yield
`std::intX_t` and `std::uintX_t` respectively if such types are defined
and a substitution failure otherwise.
`std::int_least_t<X>` and `std::uint_least_t<X>` should be required to
yield `std::int_leastY_t` and `std::uint_leastY_t` for the smallest Y
such that Y >= X for which such a type is defined. If no such Y exists,
it shall be a substitution failure.
Likewise for `std::int_fast_t<X>` and `std::uint_fast_t<X>`.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Wed, 20 Jan 2016 07:05:52 -0800 (PST)
Raw View
------=_Part_462_783116875.1453302352259
Content-Type: multipart/alternative;
boundary="----=_Part_463_1841115935.1453302352259"
------=_Part_463_1841115935.1453302352259
Content-Type: text/plain; charset=UTF-8
On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrote:
>
> On Tuesday 19 January 2016 14:57:05 Myriachan wrote:
> > 3. These types may be types that are of higher rank than
> std::[u]intmax_t.
>
> That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able to
> represent any value of any signed/unsigned integer type. Therefore, if
> uint128_t exists, then uintmax_t needs to be able to hold all of its
> values.
>
the definition of uintmax_t in the standard must face the reality that
platform ABIs are continually extended but always backward compatible. Once
uintmax_t has been fixed it will never change for a platform, even if
larger integers types are added. Similarly for maxalign_t.
-- gpd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_463_1841115935.1453302352259
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday 19 J=
anuary 2016 14:57:05 Myriachan wrote:
<br>> 3. These types may be types that are of higher rank than std::[u]i=
ntmax_t.
<br>
<br>That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able =
to=20
<br>represent any value of any signed/unsigned integer type. Therefore, if=
=20
<br>uint128_t exists, then uintmax_t needs to be able to hold all of its va=
lues.
<br></blockquote><div><br>the definition of uintmax_t=C2=A0 in the standard=
must face the reality that platform ABIs are continually extended but alwa=
ys backward compatible. Once uintmax_t has been fixed it will never change =
for a platform, even if larger integers types are added. Similarly for maxa=
lign_t.<br></div><br>-- gpd<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_463_1841115935.1453302352259--
------=_Part_462_783116875.1453302352259--
.
Author: Bo Persson <bop@gmb.dk>
Date: Wed, 20 Jan 2016 18:57:24 +0100
Raw View
On 2016-01-20 16:05, Giovanni Piero Deretta wrote:
> On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrote:
>
> On Tuesday 19 January 2016 14:57:05 Myriachan wrote:
> > 3. These types may be types that are of higher rank than
> std::[u]intmax_t.
>
> That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able to
> represent any value of any signed/unsigned integer type. Therefore, if
> uint128_t exists, then uintmax_t needs to be able to hold all of its
> values.
>
>
> the definition of uintmax_t in the standard must face the reality that
> platform ABIs are continually extended but always backward compatible.
> Once uintmax_t has been fixed it will never change for a platform, even
> if larger integers types are added. Similarly for maxalign_t.
>
Yes, but...
It would be extremely hard to teach new students that intmax_t is "the
largest integer available when the compiler ABI was revised".
We might as well propose that the typedef is removed, if it is not
useful. Or add another one quite_large_int_t?
Bo Persson
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Jan 2016 10:09:47 -0800
Raw View
--001a11c3d13a6418ca0529c7e530
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 20, 2016 at 9:57 AM, Bo Persson <bop@gmb.dk> wrote:
> On 2016-01-20 16:05, Giovanni Piero Deretta wrote:
>
>> On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrote:
>>
>> On Tuesday 19 January 2016 14:57:05 Myriachan wrote:
>> > 3. These types may be types that are of higher rank than
>> std::[u]intmax_t.
>>
>> That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able to
>> represent any value of any signed/unsigned integer type. Therefore, if
>> uint128_t exists, then uintmax_t needs to be able to hold all of its
>> values.
>>
>>
>> the definition of uintmax_t in the standard must face the reality that
>> platform ABIs are continually extended but always backward compatible.
>> Once uintmax_t has been fixed it will never change for a platform, even
>> if larger integers types are added. Similarly for maxalign_t.
>>
>>
> Yes, but...
>
> It would be extremely hard to teach new students that intmax_t is "the
> largest integer available when the compiler ABI was revised".
>
> We might as well propose that the typedef is removed, if it is not useful.
> Or add another one quite_large_int_t?
>
It can't be removed either, for source compatibility. It just didn't work
the way it was intended and is now a wart.
Jeffrey
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3d13a6418ca0529c7e530
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 20, 2016 at 9:57 AM, Bo Persson <span dir=3D"ltr"><<a href=3D"ma=
ilto:bop@gmb.dk" target=3D"_blank" class=3D"cremed">bop@gmb.dk</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2016-01-20 =
16:05, Giovanni Piero Deretta wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrote:<b=
r>
<br>
=C2=A0 =C2=A0 On Tuesday 19 January 2016 14:57:05 Myriachan wrote:<br>
=C2=A0 =C2=A0 =C2=A0> 3. These types may be types that are of higher ran=
k than<br>
=C2=A0 =C2=A0 std::[u]intmax_t.<br>
<br>
=C2=A0 =C2=A0 That's contradictory. 7.20.1.5 says that [u]intmax_t shal=
l be able to<br>
=C2=A0 =C2=A0 represent any value of any signed/unsigned integer type. Ther=
efore, if<br>
=C2=A0 =C2=A0 uint128_t exists, then uintmax_t needs to be able to hold all=
of its<br>
=C2=A0 =C2=A0 values.<br>
<br>
<br>
the definition of uintmax_t=C2=A0 in the standard must face the reality tha=
t<br>
platform ABIs are continually extended but always backward compatible.<br>
Once uintmax_t has been fixed it will never change for a platform, even<br>
if larger integers types are added. Similarly for maxalign_t.<br>
<br>
</blockquote>
<br></span>
Yes, but...<br>
<br>
It would be extremely hard to teach new students that intmax_t is "the=
largest integer available when the compiler ABI was revised".<br>
<br>
We might as well propose that the typedef is removed, if it is not useful. =
Or add another one quite_large_int_t?<span class=3D"HOEnZb"><font color=3D"=
#888888"><br></font></span></blockquote><div><br></div><div>It can't be=
removed either, for source compatibility. It just didn't work the way =
it was intended and is now a wart.</div><div><br></div><div>Jeffrey</div></=
div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11c3d13a6418ca0529c7e530--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 20 Jan 2016 13:11:56 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">=E2=80=8E> <span style=3D"line-height: initial;">It can=
't be removed either, for source compatibility. It just didn't work the way=
it was intended and is now a wart.</span></div><div style=3D"width: 100%; =
font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-ser=
if; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255=
, 255, 255);"><span style=3D"line-height: initial;"><br></span></div><div s=
tyle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro',=
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; back=
ground-color: rgb(255, 255, 255);"><span style=3D"line-height: initial;">So=
unds like deprecation then. </span></div><div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);"><br></div><div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100=
%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-=
serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(=
255, 255, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);">Sent from my&n=
bsp;BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-sp=
acing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text=
-align: initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb(=
181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: T=
ahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>=
'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals</div><div><b>Sent=
: </b>Wednesday, January 20, 2016 1:10 PM</div><div><b>To: </b>std-proposal=
s@isocpp.org</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div>=
<b>Subject: </b>Re: [std-proposals] Re: std::intX_t for arbitrary X if supp=
orted by implementation</div></div></td></tr></tbody></table><div style=3D"=
border-style: solid none none; border-top-color: rgb(186, 188, 209); border=
-top-width: 1pt; font-size: initial; text-align: initial; background-color:=
rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed,=
Jan 20, 2016 at 9:57 AM, Bo Persson <span dir=3D"ltr"><<a href=3D"mailt=
o:bop@gmb.dk" target=3D"_blank" class=3D"cremed">bop@gmb.dk</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2016-01-20 16:=
05, Giovanni Piero Deretta wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrote:<b=
r>
<br>
On Tuesday 19 January 2016 14:57:05 Myriachan wrote:<br>
> 3. These types may be types that are of higher ran=
k than<br>
std::[u]intmax_t.<br>
<br>
That's contradictory. 7.20.1.5 says that [u]intmax_t shall be=
able to<br>
represent any value of any signed/unsigned integer type. Ther=
efore, if<br>
uint128_t exists, then uintmax_t needs to be able to hold all=
of its<br>
values.<br>
<br>
<br>
the definition of uintmax_t in the standard must face the reality tha=
t<br>
platform ABIs are continually extended but always backward compatible.<br>
Once uintmax_t has been fixed it will never change for a platform, even<br>
if larger integers types are added. Similarly for maxalign_t.<br>
<br>
</blockquote>
<br></span>
Yes, but...<br>
<br>
It would be extremely hard to teach new students that intmax_t is "the larg=
est integer available when the compiler ABI was revised".<br>
<br>
We might as well propose that the typedef is removed, if it is not useful. =
Or add another one quite_large_int_t?<span class=3D"HOEnZb"><font color=3D"=
#888888"><br></font></span></blockquote><div><br></div><div>It can't be rem=
oved either, for source compatibility. It just didn't work the way it was i=
ntended and is now a wart.</div><div><br></div><div>Jeffrey</div></div></di=
v></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Jan 2016 10:19:36 -0800
Raw View
--001a11c3d13a800d380529c80888
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jan 20, 2016 at 10:11 AM, Tony V E <tvaneerd@gmail.com> wrote:
> =E2=80=8E> It can't be removed either, for source compatibility. It just =
didn't
> work the way it was intended and is now a wart.
>
> Sounds like deprecation then.
>
I'd vote for that.
Sent from my BlackBerry portable Babbage Device
> *From: *'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals
> *Sent: *Wednesday, January 20, 2016 1:10 PM
> *To: *std-proposals@isocpp.org
> *Reply To: *std-proposals@isocpp.org
> *Subject: *Re: [std-proposals] Re: std::intX_t for arbitrary X if
> supported by implementation
>
> On Wed, Jan 20, 2016 at 9:57 AM, Bo Persson <bop@gmb.dk> wrote:
>
>> On 2016-01-20 16:05, Giovanni Piero Deretta wrote:
>>
>>> On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrot=
e:
>>>
>>> On Tuesday 19 January 2016 14:57:05 Myriachan wrote:
>>> > 3. These types may be types that are of higher rank than
>>> std::[u]intmax_t.
>>>
>>> That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able =
to
>>> represent any value of any signed/unsigned integer type. Therefore,
>>> if
>>> uint128_t exists, then uintmax_t needs to be able to hold all of it=
s
>>> values.
>>>
>>>
>>> the definition of uintmax_t in the standard must face the reality that
>>> platform ABIs are continually extended but always backward compatible.
>>> Once uintmax_t has been fixed it will never change for a platform, even
>>> if larger integers types are added. Similarly for maxalign_t.
>>>
>>>
>> Yes, but...
>>
>> It would be extremely hard to teach new students that intmax_t is "the
>> largest integer available when the compiler ABI was revised".
>>
>> We might as well propose that the typedef is removed, if it is not
>> useful. Or add another one quite_large_int_t?
>>
>
> It can't be removed either, for source compatibility. It just didn't work
> the way it was intended and is now a wart.
>
> Jeffrey
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a11c3d13a800d380529c80888
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 20, 2016 at 10:11 AM, Tony V E <span dir=3D"ltr"><<a href=3D"mai=
lto:tvaneerd@gmail.com" target=3D"_blank" class=3D"cremed">tvaneerd@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div lang=3D"en-US" style=3D"l=
ine-height:initial;background-color:rgb(255,255,255)"> =
<div style=
=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sa=
ns-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-colo=
r:rgb(255,255,255)">=E2=80=8E>=C2=A0<span style=3D"line-height:initial">=
It can't be removed either, for source compatibility. It just didn'=
t work the way it was intended and is now a wart.</span></div><div style=3D=
"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)"><span style=3D"line-height:initial"><br></span></div><div =
style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro=
9;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"><span style=3D"line-height:initial">Sounds like de=
precation then.</span></div></div></blockquote><div><br></div>I'd vote =
for that.<br><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div lang=3D"en-US" style=3D"l=
ine-height:initial;background-color:rgb(255,255,255)"><div style=3D"width:1=
00%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sa=
ns-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,2=
55,255)"></div> =
=
<div style=3D"f=
ont-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-se=
rif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,25=
5)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0=
Device</div> =
=
<table width=3D"100%" style=3D"bord=
er-spacing:0px;background-color:white"> <tbody><tr><td colspan=3D"2" style=
=3D"font-size:initial;text-align:initial;background-color:rgb(255,255,255)"=
> <div style=3D"border-style:solid none none;bord=
er-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in;font=
-family:Tahoma,'BB Alpha Sans','Slate Pro';font-size:10pt">=
<div><b>From: </b>'Jeffrey Yasskin' via ISO C++ Standard - Future=
Proposals</div><div><b>Sent: </b>Wednesday, January 20, 2016 1:10 PM</div>=
<div><b>To: </b><a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blan=
k" class=3D"cremed">std-proposals@isocpp.org</a></div><div><b>Reply To: </b=
><a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank" class=3D"cre=
med">std-proposals@isocpp.org</a></div><div><b>Subject: </b>Re: [std-propos=
als] Re: std::intX_t for arbitrary X if supported by implementation</div></=
div></td></tr></tbody></table><div style=3D"border-style:solid none none;bo=
rder-top-color:rgb(186,188,209);border-top-width:1pt;font-size:initial;text=
-align:initial;background-color:rgb(255,255,255)"></div><br><div><div><div =
class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote">On Wed, Jan 20, 2016 at 9:57 AM, Bo Persson <span dir=3D"ltr"><=
<a href=3D"mailto:bop@gmb.dk" target=3D"_blank" class=3D"cremed">bop@gmb.dk=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><span>On 2016-01-20 16:05, Giova=
nni Piero Deretta wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
On Wednesday, January 20, 2016 at 12:00:12 AM UTC, Thiago Macieira wrote:<b=
r>
<br>
=C2=A0 =C2=A0 On Tuesday 19 January 2016 14:57:05 Myriachan wrote:<br>
=C2=A0 =C2=A0 =C2=A0> 3. These types may be types that are of higher ran=
k than<br>
=C2=A0 =C2=A0 std::[u]intmax_t.<br>
<br>
=C2=A0 =C2=A0 That's contradictory. 7.20.1.5 says that [u]intmax_t shal=
l be able to<br>
=C2=A0 =C2=A0 represent any value of any signed/unsigned integer type. Ther=
efore, if<br>
=C2=A0 =C2=A0 uint128_t exists, then uintmax_t needs to be able to hold all=
of its<br>
=C2=A0 =C2=A0 values.<br>
<br>
<br>
the definition of uintmax_t=C2=A0 in the standard must face the reality tha=
t<br>
platform ABIs are continually extended but always backward compatible.<br>
Once uintmax_t has been fixed it will never change for a platform, even<br>
if larger integers types are added. Similarly for maxalign_t.<br>
<br>
</blockquote>
<br></span>
Yes, but...<br>
<br>
It would be extremely hard to teach new students that intmax_t is "the=
largest integer available when the compiler ABI was revised".<br>
<br>
We might as well propose that the typedef is removed, if it is not useful. =
Or add another one quite_large_int_t?<span><font color=3D"#888888"><br></fo=
nt></span></blockquote><div><br></div><div>It can't be removed either, =
for source compatibility. It just didn't work the way it was intended a=
nd is now a wart.</div><div><br></div><div>Jeffrey</div></div></div></div>
<p></p></div></div>
-- <br><span class=3D"">
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" class=3D"cremed">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"cremed">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank" class=3D"cremed">https://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
<br></span></div></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" class=3D"cremed">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"cremed">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank" class=3D"cremed">https://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11c3d13a800d380529c80888--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 20 Jan 2016 10:31:16 -0800 (PST)
Raw View
------=_Part_40_1889706065.1453314676682
Content-Type: multipart/alternative;
boundary="----=_Part_41_1565213800.1453314676682"
------=_Part_41_1565213800.1453314676682
Content-Type: text/plain; charset=UTF-8
On Wednesday, January 20, 2016 at 2:38:22 AM UTC-8, Moritz Klammler wrote:
>
> The type shouldn't be "unspecified", however.
>
> `std::int_t<X>` and `std::uint_t<X>` should be required to yield
> `std::intX_t` and `std::uintX_t` respectively if such types are defined
> and a substitution failure otherwise.
>
> `std::int_least_t<X>` and `std::uint_least_t<X>` should be required to
> yield `std::int_leastY_t` and `std::uint_leastY_t` for the smallest Y
> such that Y >= X for which such a type is defined. If no such Y exists,
> it shall be a substitution failure.
>
> Likewise for `std::int_fast_t<X>` and `std::uint_fast_t<X>`.
>
I meant "unspecified" in the sense that the implementation could choose the
primitive type, but I suppose that it's better to do like you say and
require that the type exactly match one of the others.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_41_1565213800.1453314676682
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 20, 2016 at 2:38:22 AM UTC-8, Moritz=
Klammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The type shoul=
dn't be "unspecified", however.
<br>
<br>`std::int_t<X>` and `std::uint_t<X>` should be required to =
yield
<br>`std::intX_t` and `std::uintX_t` respectively if such types are defined
<br>and a substitution failure otherwise.
<br>
<br>`std::int_least_t<X>` and `std::uint_least_t<X>` should be =
required to
<br>yield `std::int_leastY_t` and `std::uint_leastY_t` for the smallest Y
<br>such that Y >=3D X for which such a type is defined. =C2=A0If no suc=
h Y exists,
<br>it shall be a substitution failure.
<br>
<br>Likewise for `std::int_fast_t<X>` and `std::uint_fast_t<X>`=
..
<br></blockquote><div><br>I meant "unspecified" in the sense that=
the implementation could choose the primitive type, but I suppose that it&=
#39;s better to do like you say and require that the type exactly match one=
of the others.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_41_1565213800.1453314676682--
------=_Part_40_1889706065.1453314676682--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 20 Jan 2016 12:09:12 -0800 (PST)
Raw View
------=_Part_1564_1385890390.1453320553029
Content-Type: multipart/alternative;
boundary="----=_Part_1565_1285078808.1453320553029"
------=_Part_1565_1285078808.1453320553029
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 19, 2016 at 5:57:05 PM UTC-5, Myriachan wrote:
>
> I think that an implementation ought to be allowed to implement the
> std::intX_t family of types for any X > 0, to provide for future features,
> or weird architectures. For example, std::uint36_t could exist on a PDP-10.
>
>
C permits this already. C++ arguably doesn't, because [cstdint] only
depicts 8/16/32/64/max and not any other value, but this feels like a bug
in the spec.
Do standard libraries that define int{_least,_fast,}N_t for N other than
8/16/32/64 exist in the wild?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1565_1285078808.1453320553029
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, January 19, 2016 at 5:57:05 PM UTC-5, =
Myriachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">I think that an implementation ought to be allowed to implement the std:=
:intX_t family of types for any X > 0, to provide for future features, o=
r weird architectures.=C2=A0 For example, std::uint36_t could exist on a PD=
P-10.<br><br></div></blockquote><div><br></div><div>C permits this already.=
C++ arguably doesn't, because [cstdint] only depicts 8/16/32/64/max an=
d not any other value, but this feels like a bug in the spec.</div><div><br=
></div><div>Do standard libraries that define int{_least,_fast,}N_t for N o=
ther than 8/16/32/64 exist in the wild?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1565_1285078808.1453320553029--
------=_Part_1564_1385890390.1453320553029--
.
Author: Vishal Oza <vickoza@gmail.com>
Date: Wed, 20 Jan 2016 15:44:23 -0800 (PST)
Raw View
------=_Part_2166_412874011.1453333463845
Content-Type: multipart/alternative;
boundary="----=_Part_2167_994560596.1453333463845"
------=_Part_2167_994560596.1453333463845
Content-Type: text/plain; charset=UTF-8
I was thinking that this could be extended to unique hardware like tri-bits
or q-bits
template <int X, 3>
using int_least_t = /* unspecified */;
template <int X, 3>
using int_fast_t = /* unspecified */;
for tribit a bit with three values
and
template <int X, 4>
using int_least_t = /* unspecified */;
template <int X, 4>
using int_fast_t = /* unspecified */;
for qbit a bit with four values althought q-bit logic is different from
other logic
On Tuesday, January 19, 2016 at 4:57:05 PM UTC-6, Myriachan wrote:
>
> I think that an implementation ought to be allowed to implement the
> std::intX_t family of types for any X > 0, to provide for future features,
> or weird architectures. For example, std::uint36_t could exist on a PDP-10.
>
> These are what I think should be the rules:
>
> 1. It is recommended but not required that at least X = 8, 16, 32, 64 are
> supported.
> 2. It is recommended that a value of X corresponding to the compiler's
> integer types exist.
> 3. These types may be types that are of higher rank than std::[u]intmax_t.
> 4. The [U]INTX_C macros are optional even for values of X that are
> supported by the implementation. (In particular, #ifdef should be false if
> the macro isn't supported.)
>
> Cooperation with the C committee would be needed, of course.
>
> The purpose of #3 and #4 is to support the status quo of GCC and Clang for
> 128-bit types. __int128 on these compilers is of higher rank than
> std::intmax_t. These compilers also don't support integer literals of that
> size. Thus, typedef __int128 int128_t; is enough for current GCC and
> Clang; the INT128_C macro would not exist.
>
> An extension would be a template:
>
> template <int X>
> using int_t = /* unspecified */;
>
> with int_t<X> potentially being ill-formed if X doesn't exist.
>
> This could also be supported:
>
> template <int X>
> using int_least_t = /* unspecified */;
> template <int X>
> using int_fast_t = /* unspecified */;
>
> This would support 1 >= X >= largest supported.
>
> Melissa
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2167_994560596.1453333463845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was thinking that this could be extended to unique hardw=
are like tri-bits or q-bits<div><br></div><div>template <int X, 3><br=
>using int_least_t =3D /* unspecified */;<br>template <int X, 3><br>u=
sing int_fast_t =3D /* unspecified */;<br>for tribit a bit with three value=
s</div><div><br></div><div>and</div><div><br></div><div>template <int X,=
4><br>using int_least_t =3D /* unspecified */;<br>template <int X, 4=
><br>using int_fast_t =3D /* unspecified */;<br>for qbit a bit with four=
values althought q-bit logic is different from other logic<br>On Tuesday, =
January 19, 2016 at 4:57:05 PM UTC-6, Myriachan wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">I think that an implementation oug=
ht to be allowed to implement the std::intX_t family of types for any X >=
; 0, to provide for future features, or weird architectures.=C2=A0 For exam=
ple, std::uint36_t could exist on a PDP-10.<br><br>These are what I think s=
hould be the rules:<br><br>1. It is recommended but not required that at le=
ast X =3D 8, 16, 32, 64 are supported.<br>2. It is recommended that a value=
of X corresponding to the compiler's integer types exist.<br>3. These =
types may be types that are of higher rank than std::[u]intmax_t.<br>4. The=
[U]INTX_C macros are optional even for values of X that are supported by t=
he implementation.=C2=A0 (In particular, #ifdef should be false if the macr=
o isn't supported.)<br><br>Cooperation with the C committee would be ne=
eded, of course.<br><br>The purpose of #3 and #4 is to support the status q=
uo of GCC and Clang for 128-bit types.=C2=A0 __int128 on these compilers is=
of higher rank than std::intmax_t.=C2=A0 These compilers also don't su=
pport integer literals of that size.=C2=A0 Thus, typedef __int128 int128_t;=
is enough for current GCC and Clang; the INT128_C macro would not exist.<b=
r><br>An extension would be a template:<br><br>template <int X><br>us=
ing int_t =3D /* unspecified */;<br><br>with int_t<X> potentially bei=
ng ill-formed if X doesn't exist.<br><br>This could also be supported:<=
br><br>template <int X><br>using int_least_t =3D /* unspecified */;<b=
r>template <int X><br>using int_fast_t =3D /* unspecified */;<br><br>=
This would support 1 >=3D X >=3D largest supported.<br><br>Melissa<br=
></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2167_994560596.1453333463845--
------=_Part_2166_412874011.1453333463845--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Jan 2016 16:12:17 -0800
Raw View
On Wednesday 20 January 2016 12:09:12 T. C. wrote:
> Do standard libraries that define int{_least,_fast,}N_t for N other than
> 8/16/32/64 exist in the wild?
I don't know of any current or moderately outdated machine that has a native
type of a different size, which seriously limits the availability of C99-
capable libraries that support your question...
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 21 Jan 2016 12:57:09 +0800
Raw View
--Apple-Mail=_BE8DB280-1FDA-44BA-9015-407081AEC0E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9321, at 8:12 AM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> I don't know of any current or moderately outdated machine that has a nat=
ive=20
> type of a different size, which seriously limits the availability of C99-
> capable libraries that support your question=E2=80=A6
Coincidentally, I just saw a subject line in my GCC mailing list feed which=
mentions __int20. (I didn=E2=80=99t check into what <stdint.h> does with i=
t.) The platform is the TI MSP430X, apparently introduced in the late 2000=
=E2=80=99s. It=E2=80=99s a low-power DSP supporting biggish programs.
https://en.wikipedia.org/wiki/TI_MSP430#MSP430X_20-bit_extension <https://e=
n.wikipedia.org/wiki/TI_MSP430#MSP430X_20-bit_extension>
Not that this motivates a C++ extension per se, but I suppose that any C-co=
nforming <stdint.h> should work in C++, and <cstdint> should at least be al=
lowed to bring it all into std::.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_BE8DB280-1FDA-44BA-9015-407081AEC0E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9321, at 8:12 AM, Thiago Macieira <<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>> wrote:</div><div class=3D""=
><div class=3D""><br class=3D"">I don't know of any current or moderately o=
utdated machine that has a native <br class=3D"">type of a different size, =
which seriously limits the availability of C99-<br class=3D"">capable libra=
ries that support your question=E2=80=A6</div></div></blockquote></div><br =
class=3D""><div class=3D"">Coincidentally, I just saw a subject line in my =
GCC mailing list feed which mentions <font face=3D"Courier" class=3D"">__in=
t20</font>. (I didn=E2=80=99t check into what <font face=3D"Courier" class=
=3D""><stdint.h></font> does with it.) The platform is the TI MSP430X=
, apparently introduced in the late 2000=E2=80=99s. It=E2=80=99s a low-powe=
r DSP supporting biggish programs.</div><div class=3D""><br class=3D""></di=
v><div class=3D""><a href=3D"https://en.wikipedia.org/wiki/TI_MSP430#MSP430=
X_20-bit_extension" class=3D"">https://en.wikipedia.org/wiki/TI_MSP430#MSP4=
30X_20-bit_extension</a></div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">Not that this motivates a C++ extension per se, but I suppose that =
any C-conforming <font face=3D"Courier" class=3D""><stdint.h></font> =
should work in C++, and <font face=3D"Courier" class=3D""><cstdint&=
gt;</font> should at least be allowed to bring it all into <font face=3D"Co=
urier" class=3D"">std::</font>.</div><div class=3D""><br class=3D""></div><=
/body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_BE8DB280-1FDA-44BA-9015-407081AEC0E0--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 21 Jan 2016 05:45:48 -0800
Raw View
--001a114504e2f4c3ca0529d8517b
Content-Type: text/plain; charset=UTF-8
On Jan 20, 2016 1:00 AM, "Thiago Macieira" <thiago@macieira.org> wrote:
>
> On Tuesday 19 January 2016 14:57:05 Myriachan wrote:
> > I think that an implementation ought to be allowed to implement the
> > std::intX_t family of types for any X > 0, to provide for future
features,
> > or weird architectures. For example, std::uint36_t could exist on a
PDP-10.
> >
> > These are what I think should be the rules:
> >
> > 1. It is recommended but not required that at least X = 8, 16, 32, 64
are
> > supported.
>
> That is already the case. C11 7.20 Integer types says that those types are
> optional. But it goes further and makes the 8, 16, 32 and 64-bit typedefs
> mandatory if the implementation has those integer types elsewhere.
>
> > 2. It is recommended that a value of X corresponding to the compiler's
> > integer types exist.
>
> That's already the case.
>
> > 3. These types may be types that are of higher rank than
std::[u]intmax_t.
>
> That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able to
> represent any value of any signed/unsigned integer type. Therefore, if
> uint128_t exists, then uintmax_t needs to be able to hold all of its
values.
>
> > 4. The [U]INTX_C macros are optional even for values of X that are
> > supported by the implementation. (In particular, #ifdef should be
false if
> > the macro isn't supported.)
>
> C99 makes them mandatory if the type of width X exists.
>
> > Cooperation with the C committee would be needed, of course.
> >
> > The purpose of #3 and #4 is to support the status quo of GCC and Clang
for
> > 128-bit types. __int128 on these compilers is of higher rank than
> > std::intmax_t. These compilers also don't support integer literals of
that
> > size. Thus, typedef __int128 int128_t; is enough for current GCC and
> > Clang; the INT128_C macro would not exist.
>
> Those compilers could be changed to add an extension to the language so
they
> support literals of that type. 123i128 and 123ui128, for example. The
> precedent for this is MSVC's __int64's own literals (i64 and ui64).
FWIW, clang used to support this, but as far as we can tell no-one ever
used it.
> They'll also need to change their uintmax_t to be at least 128-bit wide.
We currently have no intention of doing that, because it would break ABI
(for the C standard library function imaxdiv etc). These "max" types seem
to largely be a mistake (max_align_t is even worse).
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114504e2f4c3ca0529d8517b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Jan 20, 2016 1:00 AM, "Thiago Macieira" <<a =
href=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>> wrote:<br>
><br>
> On Tuesday 19 January 2016 14:57:05 Myriachan wrote:<br>
> > I think that an implementation ought to be allowed to implement t=
he<br>
> > std::intX_t family of types for any X > 0, to provide for futu=
re features,<br>
> > or weird architectures.=C2=A0 For example, std::uint36_t could ex=
ist on a PDP-10.<br>
> ><br>
> > These are what I think should be the rules:<br>
> ><br>
> > 1. It is recommended but not required that at least X =3D 8, 16, =
32, 64 are<br>
> > supported.<br>
><br>
> That is already the case. C11 7.20 Integer types says that those types=
are<br>
> optional. But it goes further and makes the 8, 16, 32 and 64-bit typed=
efs<br>
> mandatory if the implementation has those integer types elsewhere.<br>
><br>
> > 2. It is recommended that a value of X corresponding to the compi=
ler's<br>
> > integer types exist.<br>
><br>
> That's already the case.<br>
><br>
> > 3. These types may be types that are of higher rank than std::[u]=
intmax_t.<br>
><br>
> That's contradictory. 7.20.1.5 says that [u]intmax_t shall be able=
to<br>
> represent any value of any signed/unsigned integer type. Therefore, if=
<br>
> uint128_t exists, then uintmax_t needs to be able to hold all of its v=
alues.<br>
><br>
> > 4. The [U]INTX_C macros are optional even for values of X that ar=
e<br>
> > supported by the implementation.=C2=A0 (In particular, #ifdef sho=
uld be false if<br>
> > the macro isn't supported.)<br>
><br>
> C99 makes them mandatory if the type of width X exists.<br>
><br>
> > Cooperation with the C committee would be needed, of course.<br>
> ><br>
> > The purpose of #3 and #4 is to support the status quo of GCC and =
Clang for<br>
> > 128-bit types.=C2=A0 __int128 on these compilers is of higher ran=
k than<br>
> > std::intmax_t.=C2=A0 These compilers also don't support integ=
er literals of that<br>
> > size.=C2=A0 Thus, typedef __int128 int128_t; is enough for curren=
t GCC and<br>
> > Clang; the INT128_C macro would not exist.<br>
><br>
> Those compilers could be changed to add an extension to the language s=
o they<br>
> support literals of that type. 123i128 and 123ui128, for example. The<=
br>
> precedent for this is MSVC's __int64's own literals (i64 and u=
i64).</p>
<p dir=3D"ltr">FWIW, clang used to support this, but as far as we can tell =
no-one ever used it.</p>
<p dir=3D"ltr">> They'll also need to change their uintmax_t to be a=
t least 128-bit wide.</p>
<p dir=3D"ltr">We currently have no intention of doing that, because it wou=
ld break ABI (for the C standard library function imaxdiv etc). These "=
;max" types seem to largely be a mistake (max_align_t is even worse).<=
/p>
<p dir=3D"ltr">> --<br>
> Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
> =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
> =C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
> =C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF=
4 5358<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114504e2f4c3ca0529d8517b--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 21 Jan 2016 08:41:31 -0800
Raw View
On Thursday 21 January 2016 05:45:48 Richard Smith wrote:
> We currently have no intention of doing that, because it would break ABI
> (for the C standard library function imaxdiv etc). These "max" types seem
> to largely be a mistake (max_align_t is even worse).
Agreed on uintmax_t and like others said it should be deprecated.
What are the issues you're saying about max_align_t?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 21 Jan 2016 11:23:08 -0800 (PST)
Raw View
------=_Part_1458_1691260318.1453404188440
Content-Type: multipart/alternative;
boundary="----=_Part_1459_402100941.1453404188440"
------=_Part_1459_402100941.1453404188440
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 20, 2016 at 8:57:15 PM UTC-8, David Krauss wrote:
>
> Coincidentally, I just saw a subject line in my GCC mailing list feed=20
> which mentions __int20. (I didn=E2=80=99t check into what <stdint.h> does=
with=20
> it.) The platform is the TI MSP430X, apparently introduced in the late=20
> 2000=E2=80=99s. It=E2=80=99s a low-power DSP supporting biggish programs.
>
> https://en.wikipedia.org/wiki/TI_MSP430#MSP430X_20-bit_extension
>
> Not that this motivates a C++ extension per se, but I suppose that any=20
> C-conforming <stdint.h> should work in C++, and <cstdint> should at least=
=20
> be allowed to bring it all into std::.
>
>
Yes, definitely.
An interesting question comes up when considering the "least" and "fast"=20
types. Conceptually, these types could be defined for every integer up to=
=20
the maximum supported. On a typical platform, int_least27_t could be=20
defined with no compiler support required. Having stdint.h/cstdint typedef=
=20
every positive integer up to the maximum like that seems silly from a=20
practical standpoint, but not a theoretical one.
That's one reason that I like the std::int_t<>, std::int_least_t<>, and=20
std::int_fast_t<> template concept, because it would add support for all=20
the intermediate values without requiring the header file to just add 120=
=20
typedefs. They're straightforward to implement, too.
Melissa
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_1459_402100941.1453404188440
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 20, 2016 at 8:57:15 PM UTC-8, David Krauss wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word=
">Coincidentally, I just saw a subject line in my GCC mailing list feed whi=
ch mentions <font face=3D"Courier">__int20</font>. (I didn=E2=80=99t check =
into what <font face=3D"Courier"><stdint.h></font> does with it.) The=
platform is the TI MSP430X, apparently introduced in the late 2000=E2=80=
=99s. It=E2=80=99s a low-power DSP supporting biggish programs.<div><br></d=
iv><div><a href=3D"https://en.wikipedia.org/wiki/TI_MSP430#MSP430X_20-bit_e=
xtension" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTI=
_MSP430%23MSP430X_20-bit_extension\46sa\75D\46sntz\0751\46usg\75AFQjCNEB2BE=
-7mYlXatBALo0TwJVlNzP_Q';return true;" onclick=3D"this.href=3D'http=
s://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTI_MSP43=
0%23MSP430X_20-bit_extension\46sa\75D\46sntz\0751\46usg\75AFQjCNEB2BE-7mYlX=
atBALo0TwJVlNzP_Q';return true;">https://en.wikipedia.org/wiki/<wbr>TI_=
MSP430#MSP430X_20-bit_<wbr>extension</a></div><div><br></div><div>Not that =
this motivates a C++ extension per se, but I suppose that any C-conforming =
<font face=3D"Courier"><stdint.h></font> should work in C++, and=C2=
=A0<font face=3D"Courier"><cstdint></font> should at least be allowed=
to bring it all into <font face=3D"Courier">std::</font>.</div><div><br></=
div></div></blockquote><div><br>Yes, definitely.<br><br>An interesting ques=
tion comes up when considering the "least" and "fast" t=
ypes.=C2=A0 Conceptually, these types could be defined for every integer up=
to the maximum supported.=C2=A0 On a typical platform, int_least27_t could=
be defined with no compiler support required.=C2=A0 Having stdint.h/cstdin=
t typedef every positive integer up to the maximum like that seems silly fr=
om a practical standpoint, but not a theoretical one.<br><br>That's one=
reason that I like the std::int_t<>, std::int_least_t<>, and s=
td::int_fast_t<> template concept, because it would add support for a=
ll the intermediate values without requiring the header file to just add 12=
0 typedefs.=C2=A0 They're straightforward to implement, too.<br><br>Mel=
issa<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1459_402100941.1453404188440--
------=_Part_1458_1691260318.1453404188440--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 21 Jan 2016 15:01:05 -0800
Raw View
On Thursday 21 January 2016 11:23:08 Myriachan wrote:
> That's one reason that I like the std::int_t<>, std::int_least_t<>, and
> std::int_fast_t<> template concept, because it would add support for all
> the intermediate values without requiring the header file to just add 120
> typedefs. They're straightforward to implement, too.
Pretty easy to implement, actually. For your typical implementation:
namespace std {
template <int N> struct ints;
template <> struct ints<64> { typedef int64_t Signed; typedef uint64_t
Unsigned; };
template <> struct ints<32> { typedef int32_t Signed; typedef uint32_t
Unsigned; };
template <> struct ints<16> { typedef int16_t Signed; typedef uint16_t
Unsigned; };
template <> struct ints<8> { typedef int8_t Signed; typedef uint8_t Unsigned;
};
template <int N> using int_t = typename ints<N>::Signed;
template <int N> using uint_t = typename ints<N>::Unsigned;
template <int N, bool ok> struct ints_least;
template <int N> struct ints_least<N, true> : ints_least<N + 1, N < 64> {};
template <> struct ints_least<64, true> : ints<64> {};
template <> struct ints_least<32, true> : ints<32> {};
template <> struct ints_least<16, true> : ints<16> {};
template <> struct ints_least<8, true> : ints<8> {};
template <int N> using int_least_t = typename ints_least<N, N <= 64>::Signed;
template <int N> using uint_least_t = typename ints_least<N, N <=
64>::Unsigned;
template <int N> using int_fast_t = typename ints_least<N, N <= 64>::Signed;
template <int N> using uint_fast_t = typename ints_least<N, N <=
64>::Unsigned;
}
To go to 128, just change the < and <= 64 to 128.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.