Topic: Extended integer types proposal
Author: =?UTF-8?B?0JjQs9C+0YDRjCDQmtC70LXQstCw0L3QtdGG?=
Date: Tue, 10 Jan 2017 01:10:22 +0300
Raw View
This is a multi-part message in MIME format.
--------------67305E48DC31956F0B93F52F
Content-Type: text/plain; charset=UTF-8; format=flowed
Hello, everybody.
We are presenting proposal for C++ Standard Library which provides
integers with extended width: https://cerevra.github.io/int/. Possible
implementation may be found here:
https://github.com/cerevra/int/tree/master/v2.
Short description:
Working title is *wide_int*. It is the template class with the native
interface like built-in arithmetic types. Template args are *size_t
Bytes* and *bool IsSigned*. It is POD with /constexpr/ and /noexcept/ as
much as possible. Also there are some utils for comfortable work:
std::to_string(), std::hash<>, std::numeric_limits<> etc.
[Example:
constexpr int128_t c = std::numeric_limits<int128_t>::min();
static_assert(c == 0x80000000000000000000000000000000_uint128);
int256_t a = 13;
a += 0xFF;
a *= 2.0;
a -= 12_int128;
assert(a > 0);
]
Antony and I will be glad to get your comments.
Thank you and have a nice week!
--
Yandex
Klevanets Igor
cerevra@yandex-team.ru
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/43dc28cd-3aa0-5adb-aa3f-891f00ab4649%40yandex-team.ru.
--------------67305E48DC31956F0B93F52F
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Hello, everybody.<br>
<br>
We are presenting proposal for C++ Standard Library which provides
integers with extended width: <a
href=3D"https://cerevra.github.io/int/">https://cerevra.github.io/int=
/</a>.
Possible implementation may be found here: <a
href=3D"https://github.com/cerevra/int/tree/master/v2">https://github=
..com/cerevra/int/tree/master/v2</a>.<br>
<br>
Short description:<br>
Working title is <b>wide_int</b>. It is the template class with the
native interface like built-in arithmetic types. Template args are <b>s=
ize_t
Bytes</b> and <b>bool IsSigned</b>. It is POD with <i>constexpr</i>
and <i>noexcept</i> as much as possible. Also there are some utils
for comfortable work: std::to_string(), std::hash<>,
std::numeric_limits<> etc.<br>
<br>
[Example:<br>
=C2=A0=C2=A0=C2=A0 constexpr int128_t c =3D
std::numeric_limits<int128_t>::min();<br>
=C2=A0=C2=A0=C2=A0 static_assert(c =3D=3D 0x800000000000000000000000000=
00000_uint128);<br>
<br>
=C2=A0=C2=A0=C2=A0 int256_t a =3D 13;<br>
=C2=A0=C2=A0=C2=A0 a +=3D 0xFF;<br>
=C2=A0=C2=A0=C2=A0 a *=3D 2.0;<br>
=C2=A0=C2=A0=C2=A0 a -=3D 12_int128;<br>
=C2=A0=C2=A0=C2=A0 assert(a > 0);<br>
]<br>
<br>
Antony and I will be glad to get your comments.<br>
<br>
Thank you and have a nice week!<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
Yandex
Klevanets Igor
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:cerevra@yandex-team.ru=
">cerevra@yandex-team.ru</a></pre>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/43dc28cd-3aa0-5adb-aa3f-891f00ab4649%=
40yandex-team.ru?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/43dc28cd-3aa0-5adb-aa3f-891f00ab=
4649%40yandex-team.ru</a>.<br />
--------------67305E48DC31956F0B93F52F--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Jan 2017 15:31:46 -0800 (PST)
Raw View
------=_Part_1001_1596398825.1484004706230
Content-Type: multipart/alternative;
boundary="----=_Part_1002_518322644.1484004706230"
------=_Part_1002_518322644.1484004706230
Content-Type: text/plain; charset=UTF-8
It's probably best not to call them "extended integer types". That term
already exists in the standard with a well-understood definition. Extended
integer types are fundamental types implemented by the compiler; yours are
class types, implemented in the standard library.
And personally, once you get to the point where you need a standard library
type rather than a built-in one, you probably also need a variable-length
integer.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org.
------=_Part_1002_518322644.1484004706230
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's probably best not to call them "extended int=
eger types". That term already exists in the standard with a well-unde=
rstood definition. Extended integer types are fundamental types implemented=
by the compiler; yours are class types, implemented in the standard librar=
y.<br><br>And personally, once you get to the point where you need a standa=
rd library type rather than a built-in one, you probably also need a variab=
le-length integer.<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e=
%40isocpp.org</a>.<br />
------=_Part_1002_518322644.1484004706230--
------=_Part_1001_1596398825.1484004706230--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Tue, 10 Jan 2017 03:32:43 +0000
Raw View
--94eb2c1a1c1abe3fc10545b5236e
Content-Type: text/plain; charset=UTF-8
Statically-sized integer is worthwhile on its own. Calling it int128_t is
certainly a no go though. See this thread from a few months ago:
https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=email&utm_source=footer#!search/Integer$20width$20128/std-proposals/DE065XRzyl4
On Mon, Jan 9, 2017, 3:32 PM Nicol Bolas <jmckesson@gmail.com> wrote:
> It's probably best not to call them "extended integer types". That term
> already exists in the standard with a well-understood definition. Extended
> integer types are fundamental types implemented by the compiler; yours are
> class types, implemented in the standard library.
>
> And personally, once you get to the point where you need a standard
> library type rather than a built-in one, you probably also need a
> variable-length integer.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ9WNVqGKceSG_Asmbsr4%2Btf4AOEAj%3D4yyuh48EjLyhMg%40mail.gmail.com.
--94eb2c1a1c1abe3fc10545b5236e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Statically-sized integer is worthwhile on its own. Calling i=
t int128_t is certainly a no go though. See this thread from a few months a=
go:<br>
<a href=3D"https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=3Dema=
il&utm_source=3Dfooter#!search/Integer$20width$20128/std-proposals/DE06=
5XRzyl4">https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=3Demail=
&utm_source=3Dfooter#!search/Integer$20width$20128/std-proposals/DE065X=
Rzyl4</a><br>
</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Jan 9, 2017, 3:32 P=
M Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.co=
m</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" c=
lass=3D"gmail_msg">It's probably best not to call them "extended i=
nteger types". That term already exists in the standard with a well-un=
derstood definition. Extended integer types are fundamental types implement=
ed by the compiler; yours are class types, implemented in the standard libr=
ary.<br class=3D"gmail_msg"><br class=3D"gmail_msg">And personally, once yo=
u get to the point where you need a standard library type rather than a bui=
lt-in one, you probably also need a variable-length integer.<br class=3D"gm=
ail_msg"></div>
<p class=3D"gmail_msg"></p>
-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ9WNVqGKceSG_Asmbsr4%2Btf4AOEA=
j%3D4yyuh48EjLyhMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ9WNVq=
GKceSG_Asmbsr4%2Btf4AOEAj%3D4yyuh48EjLyhMg%40mail.gmail.com</a>.<br />
--94eb2c1a1c1abe3fc10545b5236e--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Tue, 10 Jan 2017 06:42:03 +0000
Raw View
--001a114b1628d34ee10545b7c87a
Content-Type: text/plain; charset=UTF-8
Oops. Here's a working link:
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/DE065XRzyl4/discussion
On Mon, Jan 9, 2017 at 7:32 PM John McFarlane <john@mcfarlane.name> wrote:
> Statically-sized integer is worthwhile on its own. Calling it int128_t is
> certainly a no go though. See this thread from a few months ago:
>
> https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=email&utm_source=footer#!search/Integer$20width$20128/std-proposals/DE065XRzyl4
>
> On Mon, Jan 9, 2017, 3:32 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
> It's probably best not to call them "extended integer types". That term
> already exists in the standard with a well-understood definition. Extended
> integer types are fundamental types implemented by the compiler; yours are
> class types, implemented in the standard library.
>
> And personally, once you get to the point where you need a standard
> library type rather than a built-in one, you probably also need a
> variable-length integer.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRMYvc9dGBreY33m7ZrixP2t%3DuyX%2BuHTP5-KXJF9eByWQ%40mail.gmail.com.
--001a114b1628d34ee10545b7c87a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Oops. Here's a working link: <a href=3D"https://groups=
..google.com/a/isocpp.org/d/topic/std-proposals/DE065XRzyl4/discussion">http=
s://groups.google.com/a/isocpp.org/d/topic/std-proposals/DE065XRzyl4/discus=
sion</a></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Jan 9=
, 2017 at 7:32 PM John McFarlane <<a href=3D"mailto:john@mcfarlane.name"=
>john@mcfarlane.name</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><p dir=3D"ltr" class=3D"gmail_msg">Statically-sized integer is worthwhile =
on its own. Calling it int128_t is certainly a no go though. See this threa=
d from a few months ago:<br class=3D"gmail_msg">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=3Dema=
il&utm_source=3Dfooter#!search/Integer$20width$20128/std-proposals/DE06=
5XRzyl4" class=3D"gmail_msg" target=3D"_blank">https://groups.google.com/a/=
isocpp.org/forum/m/?utm_medium=3Demail&utm_source=3Dfooter#!search/Inte=
ger$20width$20128/std-proposals/DE065XRzyl4</a><br class=3D"gmail_msg">
</p>
<br class=3D"gmail_msg"><div class=3D"gmail_quote gmail_msg"><div dir=3D"lt=
r" class=3D"gmail_msg">On Mon, Jan 9, 2017, 3:32 PM Nicol Bolas <<a href=
=3D"mailto:jmckesson@gmail.com" class=3D"gmail_msg" target=3D"_blank">jmcke=
sson@gmail.com</a>> wrote:<br class=3D"gmail_msg"></div><blockquote clas=
s=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg">It's prob=
ably best not to call them "extended integer types". That term al=
ready exists in the standard with a well-understood definition. Extended in=
teger types are fundamental types implemented by the compiler; yours are cl=
ass types, implemented in the standard library.<br class=3D"gmail_msg"><br =
class=3D"gmail_msg">And personally, once you get to the point where you nee=
d a standard library type rather than a built-in one, you probably also nee=
d a variable-length integer.<br class=3D"gmail_msg"></div>
<p class=3D"gmail_msg"></p>
-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnRMYvc9dGBreY33m7ZrixP2t%3DuyX%=
2BuHTP5-KXJF9eByWQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRMYvc9=
dGBreY33m7ZrixP2t%3DuyX%2BuHTP5-KXJF9eByWQ%40mail.gmail.com</a>.<br />
--001a114b1628d34ee10545b7c87a--
.
Author: =?UTF-8?B?0JjQs9C+0YDRjCDQmtC70LXQstCw0L3QtdGG?=
Date: Tue, 10 Jan 2017 11:48:42 +0300
Raw View
This is a multi-part message in MIME format.
--------------FA3CD9755D336B0D4B2BEF50
Content-Type: text/plain; charset=UTF-8; format=flowed
Yeah, Antony Polukhin and I are co-authors of this proposal.
We considered your note: power of 2 is dropped (*int128*, *int256*,..),
but it is not any number. Now it is multiply of 8 (*int128*, *int136*,
*int144*,..) - using full bytes of number. *size_t Bits* -> *size_t Bytes*.
We can't find any use case when we need *int65*. Usually when I use
*int64_t* instead of *int32_t *I need bigger
*std::numeric_limits<>::max()*. *uint72_t* or *int1024_t* will solve
this problem.
Of cause it is possible to make solution for *int65*. But system will
allocate whole bytes, so in library it will be necessary to make a lot
of checks. We can imagine existing of the need in *int65*, but it seems
to us that it's very rare case.
"Not pay for what you don't use".
template arg *bool IsSigned *makes interface easier to understand. If it
is not critical, we would like to keep it.
"class Archetype" is discussable point. Now in prove of concept
underlying type is *uint8_t*. At the very beginning it was *uint64_t*.
Actually template stores array of*uint8_t* or *uint64_t*. Ok. We can
make third arg of template. But what does it mean for user of library?
How he should understand it? What he will get on changing one to another
type? May be performance... For *uint128_t*, operations for 2 *uint64_t*
may be faster then operations for 16 *uint8_t*. Have I correct
understood your point?
About aliasing like '*int128_t*': this proposal provides only some
aliases: *int128_t, int256_t, int512_t, uint128_t, uint256_t,
uint512_t*. That's all. This aliases are chosen because they continue
trend of built-in names. Probably they will be the most popular
instances of template. Users of library probably will make aliases
theirselves.
We don't afraid to use this names because this proposal is flexible
solution on library side. In another words, we trying to solve problem
of wide ints via only library instead of touching language core. In any
way library will by improved to interact with core-side solution.
We can touch "core and library" or "only library". "Only library" looks
for me a little easier.
May be we are wrong, but this solution looks workable and efficient.
On 10.01.2017 09:42, John McFarlane wrote:
> Oops. Here's a working link:
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/DE065XRzyl4/discussion
>
> On Mon, Jan 9, 2017 at 7:32 PM John McFarlane <john@mcfarlane.name
> <mailto:john@mcfarlane.name>> wrote:
>
> Statically-sized integer is worthwhile on its own. Calling it
> int128_t is certainly a no go though. See this thread from a few
> months ago:
> https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=email&utm_source=footer#!search/Integer$20width$20128/std-proposals/DE065XRzyl4
> <https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=email&utm_source=footer#%21search/Integer$20width$20128/std-proposals/DE065XRzyl4>
>
>
> On Mon, Jan 9, 2017, 3:32 PM Nicol Bolas <jmckesson@gmail.com
> <mailto:jmckesson@gmail.com>> wrote:
>
> It's probably best not to call them "extended integer types".
> That term already exists in the standard with a
> well-understood definition. Extended integer types are
> fundamental types implemented by the compiler; yours are class
> types, implemented in the standard library.
>
> And personally, once you get to the point where you need a
> standard library type rather than a built-in one, you probably
> also need a variable-length integer.
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7e%40isocpp.org?utm_medium=email&utm_source=footer>.
>
--
Yandex
Klevanets Igor
cerevra@yandex-team.ru
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a4d663b-b314-df71-a13a-d74a06e7ef9b%40yandex-team.ru.
--------------FA3CD9755D336B0D4B2BEF50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Yeah, Antony Polukhin and I are co-authors of this proposal.<br>
<br>
We considered your note: power of 2 is dropped (<b>int128</b>, <b>int25=
6</b>,..),
but it is not any number. Now it is multiply of 8 (<b>int128</b>, <b>in=
t136</b>,
<b>int144</b>,..) - using full bytes of number. <b>size_t Bits</b>
-> <b>size_t Bytes</b>.<br>
We can't find any use case when we need <b>int65</b>. Usually when
I use <b>int64_t</b> instead of <b>int32_t </b>I need bigger <b>std::nu=
meric_limits<>::max()</b>.
<b>uint72_t</b> or <b>int1024_t</b> will solve this problem.<br>
Of cause it is possible to make solution for <b>int65</b>.
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
But system will allocate whole bytes, so in library it will be
necessary to make a lot of checks. We can imagine existing of the
need in <b>int65</b>, but it seems to us that it's very rare case.<br>
"Not pay for what you don't use".<br>
<br>
template arg <b>bool IsSigned </b>makes interface easier to
understand. If it is not critical, we would like to keep it.<br>
"class Archetype" is discussable point. Now in prove of concept
underlying type is <b>uint8_t</b>. At the very beginning it was <b>uint=
64_t</b>.
Actually template stores array of<b> uint8_t</b> or <b>uint64_t</b>.
Ok. We can make third arg of template. But what does it mean for
user of library? How he should understand it? What he will get on
changing one to another type? May be performance... For <b>uint128_t</b=
>,
operations for 2 <b>uint64_t</b> may be faster then operations for
16 <b>uint8_t</b>. Have I correct understood your point?<br>
<br>
About aliasing like '<b>int128_t</b>': this proposal provides only
some aliases: <b>int128_t, int256_t, int512_t, uint128_t,
uint256_t, uint512_t</b>. That's all. This aliases are chosen
because they continue trend of built-in names. Probably they will be
the most popular instances of template. Users of library probably
will make aliases theirselves.<br>
We don't afraid to use this names because this proposal is flexible
solution on library side. In another words, we trying to solve
problem of wide ints via only library instead of touching language
core. In any way library will by improved to interact with core-side
solution.<br>
We can touch "core and library" or "only library". "Only library"
looks for me a little easier.<br>
May be we are wrong, but this solution looks workable and efficient.<br=
>
<br>
<div class=3D"moz-cite-prefix">On 10.01.2017 09:42, John McFarlane
wrote:<br>
</div>
<blockquote
cite=3D"mid:CABPJVnRMYvc9dGBreY33m7ZrixP2t=3DuyX+uHTP5-KXJF9eByWQ@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">Oops. Here's a working link: <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/DE065X=
Rzyl4/discussion">https://groups.google.com/a/isocpp.org/d/topic/std-propos=
als/DE065XRzyl4/discussion</a></div>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Mon, Jan 9, 2017 at 7:32 PM John McFarlane
<<a moz-do-not-send=3D"true"
href=3D"mailto:john@mcfarlane.name">john@mcfarlane.name</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr" class=3D"gmail_msg">Statically-sized integer is
worthwhile on its own. Calling it int128_t is certainly a no
go though. See this thread from a few months ago:<br
class=3D"gmail_msg">
<a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/forum/m/?utm_medium=3Demail&=
amp;utm_source=3Dfooter#%21search/Integer$20width$20128/std-proposals/DE065=
XRzyl4"
class=3D"gmail_msg" target=3D"_blank">https://groups.google.c=
om/a/isocpp.org/forum/m/?utm_medium=3Demail&utm_source=3Dfooter#!search=
/Integer$20width$20128/std-proposals/DE065XRzyl4</a><br
class=3D"gmail_msg">
</p>
<br class=3D"gmail_msg">
<div class=3D"gmail_quote gmail_msg">
<div dir=3D"ltr" class=3D"gmail_msg">On Mon, Jan 9, 2017, 3:32
PM Nicol Bolas <<a moz-do-not-send=3D"true"
href=3D"mailto:jmckesson@gmail.com" class=3D"gmail_msg"
target=3D"_blank">jmckesson@gmail.com</a>> wrote:<br
class=3D"gmail_msg">
</div>
<blockquote class=3D"gmail_quote gmail_msg" style=3D"margin:0 0
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr" class=3D"gmail_msg">It's probably best not t=
o
call them "extended integer types". That term already
exists in the standard with a well-understood
definition. Extended integer types are fundamental types
implemented by the compiler; yours are class types,
implemented in the standard library.<br
class=3D"gmail_msg">
<br class=3D"gmail_msg">
And personally, once you get to the point where you need
a standard library type rather than a built-in one, you
probably also need a variable-length integer.<br
class=3D"gmail_msg">
</div>
-- <br class=3D"gmail_msg">
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br class=3D"gmail_msg">
To unsubscribe from this group and stop receiving emails
from it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
class=3D"gmail_msg" target=3D"_blank">std-proposals+unsubsc=
ribe@isocpp.org</a>.<br
class=3D"gmail_msg">
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" class=3D"gmail_msg=
"
target=3D"_blank">std-proposals@isocpp.org</a>.<br
class=3D"gmail_msg">
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a445c=
4c-cd01-4293-af18-00f967c7de7e%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter"
class=3D"gmail_msg" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/2a445c4c-cd01-4293-af18-00f967c7de7=
e%40isocpp.org</a>.<br
class=3D"gmail_msg">
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
Yandex
Klevanets Igor
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:cerevra@yandex-team.ru=
">cerevra@yandex-team.ru</a>
</pre>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a4d663b-b314-df71-a13a-d74a06e7ef9b%=
40yandex-team.ru?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/2a4d663b-b314-df71-a13a-d74a06e7=
ef9b%40yandex-team.ru</a>.<br />
--------------FA3CD9755D336B0D4B2BEF50--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 10 Jan 2017 07:37:27 -0800
Raw View
Em ter=C3=A7a-feira, 10 de janeiro de 2017, =C3=A0s 11:48:42 PST, =D0=98=D0=
=B3=D0=BE=D1=80=D1=8C =D0=9A=D0=BB=D0=B5=D0=B2=D0=B0=D0=BD=D0=B5=D1=86=20
escreveu:
> About aliasing like '*int128_t*': this proposal provides only some
> aliases: *int128_t, int256_t, int512_t, uint128_t, uint256_t,
> uint512_t*. That's all. This aliases are chosen because they continue
> trend of built-in names. Probably they will be the most popular
> instances of template. Users of library probably will make aliases
> theirselves.
Which is exactly why they shouldn't be aliases. These names should be reser=
ved=20
for future extension of the primitive types.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/11506955.V3HVI6baia%40tjmaciei-mobl1.
.
Author: John McFarlane <john@mcfarlane.name>
Date: Tue, 10 Jan 2017 17:02:06 +0000
Raw View
--94eb2c1cbd544d95000545c07263
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 10, 2017 at 12:48 AM =D0=98=D0=B3=D0=BE=D1=80=D1=8C =D0=9A=D0=
=BB=D0=B5=D0=B2=D0=B0=D0=BD=D0=B5=D1=86 <cerevra@yandex-team.ru>
wrote:
> We can't find any use case when we need *int65*. Usually when I use
> *int64_t* instead of *int32_t *I need bigger
> *std::numeric_limits<>::max()*. *uint72_t* or *int1024_t* will solve this
> problem.
>
Of cause it is possible to make solution for *int65*. But system will
> allocate whole bytes, so in library it will be necessary to make a lot of
> checks. We can imagine existing of the need in *int65*, but it seems to
> us that it's very rare case.
>
A use case for int65 is converting a uint64 to a signed type. Leaving it up
to the user to guess whether this means they should ask for a wide_int<72>
or wide_int<128> in order to avoid compiler error is not too friendly.
"Not pay for what you don't use".
>
Not paying for extra bytes is of relatively little interest compared to not
paying for extra clock cycles. I'd like to be able to say wide_int<65> and
on most platforms, I'd expect back a type that was 128-bits wide.
>
> template arg *bool IsSigned *makes interface easier to understand. If it
> is not critical, we would like to keep it.
> "class Archetype" is discussable point. Now in prove of concept underlyin=
g
> type is *uint8_t*. At the very beginning it was *uint64_t*. Actually
> template stores array of* uint8_t* or *uint64_t*. Ok. We can make third
> arg of template. But what does it mean for user of library? How he should
> understand it? What he will get on changing one to another type? May be
> performance... For *uint128_t*, operations for 2 *uint64_t* may be faster
> then operations for 16 *uint8_t*. Have I correct understood your point?
>
That's one possible reason. There may also be a case for providing a custom
type. At the very least, smallest versus fastest is likely to be a desired
choice.
May be we are wrong, but this solution looks workable and efficient.
>
Is it as efficient as built-in types? Ideally it should provide no overhead
in situations where a built-in type could be used instead. In some cases,
I'm concerned it would lose out to an int.
John
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CABPJVnRWiYqGC6xJ-JbqfMfBpDhju5A1Ofn5_rASdftNCQ1=
YfQ%40mail.gmail.com.
--94eb2c1cbd544d95000545c07263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jan 10, 2017 at 12:48 AM =D0=98=D0=B3=D0=BE=D1=80=
=D1=8C =D0=9A=D0=BB=D0=B5=D0=B2=D0=B0=D0=BD=D0=B5=D1=86 <<a href=3D"mail=
to:cerevra@yandex-team.ru">cerevra@yandex-team.ru</a>> wrote:<br><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"gmail_msg">We can'=
t find any use case when we need <b class=3D"gmail_msg">int65</b>. Usually =
when
I use <b class=3D"gmail_msg">int64_t</b> instead of <b class=3D"gmail_m=
sg">int32_t </b>I need bigger <b class=3D"gmail_msg">std::numeric_limits<=
;>::max()</b>.
<b class=3D"gmail_msg">uint72_t</b> or <b class=3D"gmail_msg">int1024_t=
</b> will solve this problem.<br class=3D"gmail_msg"></div></blockquote><di=
v></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#00=
0000" class=3D"gmail_msg">
Of cause it is possible to make solution for <b class=3D"gmail_msg">int=
65</b>.
=20
But system will allocate whole bytes, so in library it will be
necessary to make a lot of checks. We can imagine existing of the
need in <b class=3D"gmail_msg">int65</b>, but it seems to us that it=
9;s very rare case.<br class=3D"gmail_msg"></div></blockquote><div><br>A us=
e case for int65 is converting a uint64 to a signed type. Leaving it up to =
the user to guess whether this means they should ask for a wide_int<72&g=
t; or wide_int<128> in order to avoid compiler error is not too frien=
dly.=C2=A0 <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FF=
FFFF" text=3D"#000000" class=3D"gmail_msg">
"Not pay for what you don't use".<br class=3D"gmail_msg">=
</div></blockquote><div><br>Not paying for extra bytes is of relatively lit=
tle interest compared to not paying for extra clock cycles. I'd like to=
be able to say wide_int<65> and on most platforms, I'd
expect back a type that was 128-bits wide.<br> </div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"gmail_msg">
<br class=3D"gmail_msg">
template arg <b class=3D"gmail_msg">bool IsSigned </b>makes interface e=
asier to
understand. If it is not critical, we would like to keep it.<br class=
=3D"gmail_msg">
"class Archetype" is discussable point. Now in prove of conce=
pt
underlying type is <b class=3D"gmail_msg">uint8_t</b>. At the very begi=
nning it was <b class=3D"gmail_msg">uint64_t</b>.
Actually template stores array of<b class=3D"gmail_msg"> uint8_t</b> or=
<b class=3D"gmail_msg">uint64_t</b>.
Ok. We can make third arg of template. But what does it mean for
user of library? How he should understand it? What he will get on
changing one to another type? May be performance... For <b class=3D"gma=
il_msg">uint128_t</b>,
operations for 2 <b class=3D"gmail_msg">uint64_t</b> may be faster then=
operations for
16 <b class=3D"gmail_msg">uint8_t</b>. Have I correct understood your p=
oint?<br class=3D"gmail_msg"></div></blockquote><div><br>That's one pos=
sible reason. There may also be a case for providing a custom type. At the =
very least, smallest versus fastest is likely to be a desired choice.<br></=
div><br class=3D"gmail_msg"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"=
#FFFFFF" text=3D"#000000" class=3D"gmail_msg">
May be we are wrong, but this solution looks workable and efficient.</d=
iv></blockquote><div>=C2=A0</div><div>Is it as efficient as built-in types?=
Ideally it should provide no overhead in situations where a built-in type =
could be used instead. In some cases, I'm concerned it would lose out t=
o an int.<br><br></div><div>John</div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnRWiYqGC6xJ-JbqfMfBpDhju5A1Ofn5=
_rASdftNCQ1YfQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRWiYqGC6xJ=
-JbqfMfBpDhju5A1Ofn5_rASdftNCQ1YfQ%40mail.gmail.com</a>.<br />
--94eb2c1cbd544d95000545c07263--
.