Topic: User defined literal for size_t
Author: morwenn29@gmail.com
Date: Fri, 18 Jul 2014 16:03:36 -0700 (PDT)
Raw View
------=_Part_773_918015669.1405724616176
Content-Type: text/plain; charset=UTF-8
It would be great to have a standard user-defined literal for std::size_t.
I often want to be able to pass a std::size_t constant to some generic
functions, and since the type is implementation-defined, I generally have
to use a full static_cast in order to do so. It would probably make sense
to have a UDL for std::size_t, which is arguably one of the most used
standard integer types. It would be z if we follow the printf format
specifier for size_t. Example:
for (auto i: irange(2z, 12z))
{
// whatever
}
I don't think that the other specifiers which printf has format specifiers
for are used enough to deserve an UDL though.
Your thoughts?
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_773_918015669.1405724616176
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It would be great to have a standard user-defined literal =
for std::size_t. I often want to be able to pass a std::size_t constant to =
some generic functions, and since the type is implementation-defined, I gen=
erally have to use a full static_cast in order to do so. It would probably =
make sense to have a UDL for std::size_t, which is arguably one of the most=
used standard integer types. It would be z if we follow the printf format =
specifier for size_t. Example:<br><br><div style=3D"margin-left: 40px;"><sp=
an style=3D"font-family: courier new,monospace;">for (auto i: irange(2z, 12=
z))<br>{<br> // whatever<br>}</span><br></div><br>I don't=
think that the other specifiers which printf has format specifiers for are=
used enough to deserve an UDL though.<br><br>Your thoughts?<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_773_918015669.1405724616176--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 19 Jul 2014 07:18:13 +0800
Raw View
--Apple-Mail=_BF6FAC70-1A77-4D4A-A8D5-BBF2651DEB26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-19, at 7:03 AM, morwenn29@gmail.com wrote:
> It would be great to have a standard user-defined literal for std::size_t=
.. I often want to be able to pass a std::size_t constant to some generic fu=
nctions, and since the type is implementation-defined, I generally have to =
use a full static_cast in order to do so. It would probably make sense to h=
ave a UDL for std::size_t, which is arguably one of the most used standard =
integer types. It would be z if we follow the printf format specifier for s=
ize_t. Example:
>=20
> for (auto i: irange(2z, 12z))
> {
> // whatever
> }
>=20
> I don't think that the other specifiers which printf has format specifier=
s for are used enough to deserve an UDL though.
>=20
> Your thoughts?
I agree, but given use of the U suffix, how often do you have a literal val=
ue that actually overflows unsigned int? And even if it does, it will bump =
up to long unsigned int automatically. If you specifically need size_t for =
metaprogramming (template argument sensitivity), then it's better to:
a) explicitly cast or specify type (in this case, declare std::size_t i)
b) pass an explicit template argument
c) change the metaprogram (is boost::irange behavior really sensitive to th=
is difference?)
There's no reason in principle we shouldn't have suffixes for various typed=
efs, particularly fixed-size types like uint32_t, but suffixes shouldn't be=
encouraged where better stylistic choices exist.
Also, if lowercase z is added, uppercase Z should do the same thing.
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_BF6FAC70-1A77-4D4A-A8D5-BBF2651DEB26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–19, at 7:03 AM, <a href=3D"mailto:morwenn29@gmail.com">morwe=
nn29@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr">It would be great to have a standard=
user-defined literal for std::size_t. I often want to be able to pass a st=
d::size_t constant to some generic functions, and since the type is impleme=
ntation-defined, I generally have to use a full static_cast in order to do =
so. It would probably make sense to have a UDL for std::size_t, which is ar=
guably one of the most used standard integer types. It would be z if we fol=
low the printf format specifier for size_t. Example:<br><br><div style=3D"m=
argin-left: 40px;"><span style=3D"font-family: courier new,monospace;">for =
(auto i: irange(2z, 12z))<br>{<br> // whatever<br>}</span=
><br></div><br>I don't think that the other specifiers which printf has for=
mat specifiers for are used enough to deserve an UDL though.<br><br>Your th=
oughts?<br></div></blockquote><div><br></div><div>I agree, but given use of=
the <font face=3D"Courier">U</font> suffix, how often do you have a l=
iteral value that actually overflows <font face=3D"Courier">unsigned int</f=
ont>? And even if it does, it will bump up to <font face=3D"Courier">long u=
nsigned int</font> automatically. If you specifically need <font face=3D"Co=
urier">size_t</font> for metaprogramming (template argument sensitivit=
y), then it’s better to:</div><div><br></div><div>a) explicitly cast =
or specify type (in this case, declare <font face=3D"Courier">std::size_t i=
</font>)</div><div>b) pass an explicit template argument</div><div>c) chang=
e the metaprogram (is <font face=3D"Courier">boost::irange</font> beha=
vior really sensitive to this difference?)</div></div><br><div>There’=
s no reason in principle we shouldn’t have suffixes for various typed=
efs, particularly fixed-size types like <font face=3D"Courier">uint32_t</fo=
nt>, but suffixes shouldn’t be encouraged where better stylistic choi=
ces exist.</div><div><br></div><div>Also, if lowercase <font face=3D"Courie=
r">z</font> is added, uppercase <font face=3D"Courier">Z</font> should do t=
he same thing.</div><div><br></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_BF6FAC70-1A77-4D4A-A8D5-BBF2651DEB26--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Sat, 19 Jul 2014 09:03:22 -0700 (PDT)
Raw View
------=_Part_209_10234991.1405785802992
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014. j=C3=BAlius 19., szombat 1:18:18 UTC+2 id=C5=91pontban David Krauss a=
=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>
> it=E2=80=99s better to:
>
> a) explicitly cast or specify type (in this case, declare std::size_t i)
> b) pass an explicit template argument
> c) change the metaprogram (is boost::irange behavior really sensitive to=
=20
> this difference?)
>
> (...)
>
> suffixes shouldn=E2=80=99t be encouraged where better stylistic choices e=
xist.=20
>
I'm not convinced if these are better stylistic choices. Consider:
vector<int> vals{1,2,3,4,5,6,7,8,9,10,11,12,13};
auto product =3D accumulate(begin(vals), end(vals), 1, multiplies<>); //Pro=
bably=20
undefined behavior!
Because accumulate will use int for calculation from 3rd parameter's type ,=
=20
and 13! =3D 6 227 020 800, whereas 32 bit int max is just 2 147 483 648.=20
Signed integer overflow is undefined behavior.
To solve this, option b) and c) is not really feasible: the return /=20
calculation type is the second template parameter so I can't explicitly=20
pass it without defining the iterator's type as well, and I don't think it=
=20
is ever good suggestion to avoid a standard algorithm.
Option a) will now look like this:
auto product =3D accumulate(begin(vals), end(vals), (unsigned long long)1,=
=20
multiplies<>);
Provided there is a postfix for unsigned long longs, I can just write:
auto product =3D accumulate(begin(vals), end(vals), 1ull, multiplies<>);
But unsigned long long is not a 'well defined' type, what if I want=20
explicitly 64 bit calculations?
auto product =3D accumulate(begin(vals), end(vals), (uint64_t)1, multiplies
<>);
...but I don't have the second option now :(
Robert
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_209_10234991.1405785802992
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>2014. j=C3=BAlius 19., szombat 1:18:18 UTC+2 id=C5=
=91pontban David Krauss a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div>it=
=E2=80=99s better to:<div><br></div><div>a) explicitly cast or specify type=
(in this case, declare <font face=3D"Courier">std::size_t i</font>)</div><=
div>b) pass an explicit template argument</div><div>c) change the metaprogr=
am (is <font face=3D"Courier">boost::irange</font> behavior really sen=
sitive to this difference?)<br><br>(...)<br><br>suffixes shouldn=E2=80=99t =
be encouraged where better stylistic choices exist. </div></div></div></blo=
ckquote><div><br>I'm not convinced if these are better stylistic choices. C=
onsider:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
vector</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><=
int></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> va=
ls</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">6</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">7</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">8</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #066;" class=3D"styled-by-prettify">9</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">11</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">12</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1=
3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> product </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> accumulate</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">vals</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">end</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">vals</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> multiplies</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><>);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//Probably undefined behavior!</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div>Because accumulate=
will use int for calculation from 3rd parameter's type , and 13! =3D 6&nbs=
p;227 020 800, whereas 32 bit int max is just 2 147 483=
648. Signed integer overflow is undefined behavior.<br><br>To solve t=
his, option b) and c) is not really feasible: the return / calculation type=
is the second template parameter so I can't explicitly pass it without def=
ining the iterator's type as well, and I don't think it is ever good sugges=
tion to avoid a standard algorithm.<br><br>Option a) will now look like thi=
s:<br><code class=3D"prettyprint"><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> product </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> accumulate</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">begin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">vals</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vals</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">long</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">long</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> multiplies</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><>);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><span style=3D"color: #000;" class=
=3D"styled-by-prettify"></span></code>Provided there is a postfix for unsig=
ned long longs, I can just write:<br><code class=3D"prettyprint"><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> product </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> accumulate</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">vals</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">end</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">vals</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">1ull</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> multiplies</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><>);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div></code><br>But unsigned long=
long is not a 'well defined' type, what if I want explicitly 64 bit calcul=
ations?<br><code class=3D"prettyprint"><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> product </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> accumulate</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">begin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vals</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">vals</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">uint6=
4_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> multiplies</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><>);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"></span></code>..but =
I don't have the second option now :(<br><br>Robert<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_209_10234991.1405785802992--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 20 Jul 2014 09:48:47 +0800
Raw View
--Apple-Mail=_582AD707-0B55-424A-9DEB-E17B3F282C17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-20, at 12:03 AM, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> But unsigned long long is not a 'well defined' type, what if I want expli=
citly 64 bit calculations?
> auto product =3D accumulate(begin(vals), end(vals), (uint64_t)1, multipli=
es<>);
> ..but I don't have the second option now :(
What second option? Can you elaborate what's wrong with this line of code?
The three alternatives I gave are in general order of preference, though th=
ey express completely different approaches, so I don't think it's a cause f=
or concern that (b) and (c) don't apply.
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_582AD707-0B55-424A-9DEB-E17B3F282C17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–20, at 12:03 AM, R=F3bert D=E1vid <<a href=3D"mailto:lrdx=
gm@gmail.com">lrdxgm@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><blockquote type=3D"cite"><div dir=3D"ltr">But unsigned lon=
g long is not a 'well defined' type, what if I want explicitly 64 bit calcu=
lations?<br><div><code class=3D"prettyprint"><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187,=
187); word-wrap: break-word; position: static; z-index: auto;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">auto</span><span style=3D"" class=3D"styled-b=
y-prettify"> product </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"" class=3D"styled-by-prettify"> accumul=
ate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"" class=3D"styled-by-prettify">vals</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">),</span><span style=3D"" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
end</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"" class=3D"styled-by-prettify">vals</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">),</span><span style=3D"" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"" class=3D"styled-by-prettify">uint64_t<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"" cla=
ss=3D"styled-by-prettify"> multiplies</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><>);</span><span style=3D"" class=3D"style=
d-by-prettify"><br></span></div></code></div><span style=3D"" class=3D"styl=
ed-by-prettify"></span></code>..but I don't have the second option now :(<b=
r></div></div></blockquote><div><br></div><div>What second option? Can you =
elaborate what’s wrong with this line of code?</div><div><br></div><d=
iv>The three alternatives I gave are in general order of preference, though=
they express completely different approaches, so I don’t think it&rs=
quo;s a cause for concern that (b) and (c) don’t apply.</div><div><br=
></div></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_582AD707-0B55-424A-9DEB-E17B3F282C17--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Sun, 20 Jul 2014 03:43:46 -0700 (PDT)
Raw View
------=_Part_1448_1477657767.1405853026438
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014. j=C3=BAlius 20., vas=C3=A1rnap 3:48:54 UTC+2 id=C5=91pontban David Kr=
auss a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> What second option? Can you elaborate what=E2=80=99s wrong with this line=
of code?
>
=20
The one with a(n uint64_t) literal. There is nothing wrong with it, it's=20
just nothing better than the one using casting to unsigned long long, but=
=20
there the programmer has given a less verbose choice to write a literal,=20
making unsigned long long a.. "more equal" citizen than uint64_t.
As a totally unlikely alternative, if it *is* actually an intention to use=
=20
(unsigned long long)1 instead of 1ull, why not remove/deprecate the literal=
=20
suffixes?
Robert
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1448_1477657767.1405853026438
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>2014. j=C3=BAlius 20., vas=C3=A1rnap 3:48:54 UTC+2 id=
=C5=91pontban David Krauss a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote cla=
ss=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"><div><div=
>What second option? Can you elaborate what=E2=80=99s wrong with this line =
of code?</div></div></div></blockquote><div> </div><div>The one with a=
(n uint64_t) literal. There is nothing wrong with it, it's just nothing bet=
ter than the one using casting to unsigned long long, but there the program=
mer has given a less verbose choice to write a literal, making unsigned lon=
g long a.. "more equal" citizen than uint64_t.<br><br>As a totally unlikely=
alternative, if it <i>is</i> actually an intention to use (unsigned long l=
ong)1 instead of 1ull, why not remove/deprecate the literal suffixes?<br></=
div><br>Robert<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1448_1477657767.1405853026438--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 20 Jul 2014 19:48:19 +0800
Raw View
--Apple-Mail=_3D19DEC0-75CB-4F14-AD53-634FEC48419C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On 2014=E2=80=9307=E2=80=9320, at 6:43 PM, R=C3=B3bert D=C3=A1vid <lrdxgm@g=
mail.com> wrote:
>=20
> 2014. j=C3=BAlius 20., vas=C3=A1rnap 3:48:54 UTC+2 id=C5=91pontban David =
Krauss a k=C3=B6vetkez=C5=91t =C3=ADrta:
> What second option? Can you elaborate what=E2=80=99s wrong with this line=
of code?
> =20
> The one with a(n uint64_t) literal. There is nothing wrong with it, it's =
just nothing better than the one using casting to unsigned long long, but t=
here the programmer has given a less verbose choice to write a literal, mak=
ing unsigned long long a.. "more equal" citizen than uint64_t.
OK. You=E2=80=99re not arguing for the suffix(es) at all. Thanks for clarif=
ying.
> As a totally unlikely alternative, if it is actually an intention to use =
(unsigned long long)1 instead of 1ull, why not remove/deprecate the literal=
suffixes?
The literal suffixes are not harmful enough to deprecate, and they can be u=
seful when precise specification of a type isn=E2=80=99t desired. For float=
ing point types in particular, no format-specific typedefs exist, for bette=
r or worse, and floating point =E2=80=9Cmagic numbers=E2=80=9D are much mor=
e common (per variable of applicable type) than integers.
I=E2=80=99d generally agree though that integer type-suffixes are poor styl=
e. There are only a few cases where there=E2=80=99s no substitute, such as =
in preprocessing conditional control expressions. Otherwise, any programmer=
good enough to know that safety and explicit meaning are worth a little ex=
tra verboseness will seldom be tempted to use them in the first place.
Most practical ud-literal suffixes likewise have more verbose names than ju=
st Z or _Z. Usage of ud-literals is more about emphasizing the argument val=
ue over the function call, and expressing the constexpr semantic at the cal=
l site, than merely saving keystrokes.
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_3D19DEC0-75CB-4F14-AD53-634FEC48419C
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;"><br><div><div>On 2014=E2=80=
=9307=E2=80=9320, at 6:43 PM, R=C3=B3bert D=C3=A1vid <<a href=3D"mailto:=
lrdxgm@gmail.com">lrdxgm@gmail.com</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><br>2014. j=
=C3=BAlius 20., vas=C3=A1rnap 3:48:54 UTC+2 id=C5=91pontban David Krauss a =
k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div style=3D"word-wrap:break-word">What second option? Can you elaborate =
what=E2=80=99s wrong with this line of code?</div></blockquote><div> <=
/div><div>The one with a(n uint64_t) literal. There is nothing wrong with i=
t, it's just nothing better than the one using casting to unsigned long lon=
g, but there the programmer has given a less verbose choice to write a lite=
ral, making unsigned long long a.. "more equal" citizen than uint64_t.<br><=
/div></div></blockquote><div><br></div><div>OK. You=E2=80=99re not arguing =
for the suffix(es) at all. Thanks for clarifying.</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr"><div>As a totally unlikely alternative, if it <i=
>is</i> actually an intention to use (unsigned long long)1 instead of 1ull,=
why not remove/deprecate the literal suffixes?<br></div></div></blockquote=
><div><br></div><div>The literal suffixes are not harmful enough to depreca=
te, and they can be useful when precise specification of a type isn=E2=80=
=99t desired. For floating point types in particular, no format-specific ty=
pedefs exist, for better or worse, and floating point =E2=80=9Cmagic number=
s=E2=80=9D are much more common (per variable of applicable type) than inte=
gers.</div></div><br><div>I=E2=80=99d generally agree though that integer t=
ype-suffixes are poor style. There are only a few cases where there=E2=80=
=99s no substitute, such as in preprocessing conditional control expression=
s. Otherwise, any programmer good enough to know that safety and explicit m=
eaning are worth a little extra verboseness will seldom be tempted to use t=
hem in the first place.</div><div><br></div><div>Most practical ud-literal =
suffixes likewise have more verbose names than just Z or _Z. Usage of ud-li=
terals is more about emphasizing the argument value over the function call,=
and expressing the constexpr semantic at the call site, than merely saving=
keystrokes.</div><div><br></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_3D19DEC0-75CB-4F14-AD53-634FEC48419C--
.
Author: rhalbersma@gmail.com
Date: Tue, 21 Oct 2014 12:58:59 -0700 (PDT)
Raw View
------=_Part_890_2027196153.1413921539985
Content-Type: text/plain; charset=UTF-8
On Saturday, July 19, 2014 1:03:36 AM UTC+2, morw...@gmail.com wrote:
>
> It would be great to have a standard user-defined literal for std::size_t.
> I often want to be able to pass a std::size_t constant to some generic
> functions, and since the type is implementation-defined, I generally have
> to use a full static_cast in order to do so. It would probably make sense
> to have a UDL for std::size_t, which is arguably one of the most used
> standard integer types. It would be z if we follow the printf format
> specifier for size_t. Example:
>
> for (auto i: irange(2z, 12z))
> {
> // whatever
> }
>
> I don't think that the other specifiers which printf has format specifiers
> for are used enough to deserve an UDL though.
>
> Your thoughts?
>
I like the idea, and use it in my own code (with an underscore of course).
I typed up a proposal but didn't manage to get it done before the Urbana
deadline, so it will have to wait until 2015. Here's the draft proposal
http://goo.gl/KlYUCY
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_890_2027196153.1413921539985
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 19, 2014 1:03:36 AM UTC+2, morw...@gmail=
..com 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"ltr">It=
would be great to have a standard user-defined literal for std::size_t. I =
often want to be able to pass a std::size_t constant to some generic functi=
ons, and since the type is implementation-defined, I generally have to use =
a full static_cast in order to do so. It would probably make sense to have =
a UDL for std::size_t, which is arguably one of the most used standard inte=
ger types. It would be z if we follow the printf format specifier for size_=
t. Example:<br><br><div style=3D"margin-left:40px"><span style=3D"font-fami=
ly:courier new,monospace">for (auto i: irange(2z, 12z))<br>{<br>  =
; // whatever<br>}</span><br></div><br>I don't think that the other s=
pecifiers which printf has format specifiers for are used enough to deserve=
an UDL though.<br><br>Your thoughts?<br></div></blockquote><div><br></div>=
<div>I like the idea, and use it in my own code (with an underscore of cour=
se). I typed up a proposal but didn't manage to get it done before the Urba=
na deadline, so it will have to wait until 2015. Here's the draft proposal<=
/div><div>http://goo.gl/KlYUCY<span style=3D"font-size: 13px;"> </span=
></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_890_2027196153.1413921539985--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 21 Oct 2014 13:30:08 -0700 (PDT)
Raw View
------=_Part_429_1491410414.1413923408906
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 21, 2014 12:59:00 PM UTC-7, rhalb...@gmail.com wrote:
>
>
> I like the idea, and use it in my own code (with an underscore of course).
> I typed up a proposal but didn't manage to get it done before the Urbana
> deadline, so it will have to wait until 2015. Here's the draft proposal
> http://goo.gl/KlYUCY
>
What if an architecture defines extended-precision integers, and std::size_t
is defined by that architecture to be a size larger than unsigned long long?
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_429_1491410414.1413923408906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 21, 2014 12:59:00 PM UTC-7, rhalb...@g=
mail.com 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"ltr=
"><br><div>I like the idea, and use it in my own code (with an underscore o=
f course). I typed up a proposal but didn't manage to get it done before th=
e Urbana deadline, so it will have to wait until 2015. Here's the draft pro=
posal</div><div><a href=3D"http://goo.gl/KlYUCY" target=3D"_blank" onmoused=
own=3D"this.href=3D'http://goo.gl/KlYUCY';return true;" onclick=3D"this.hre=
f=3D'http://goo.gl/KlYUCY';return true;">http://goo.gl/KlYUCY</a><span styl=
e=3D"font-size:13px"> </span></div></div></blockquote><div><br>What if=
an architecture defines extended-precision integers, and <span style=3D"fo=
nt-family: courier new,monospace;">std::size_t</span> is defined by that ar=
chitecture to be a size larger than <span style=3D"font-family: courier new=
,monospace;">unsigned long long</span>?<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_429_1491410414.1413923408906--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 21 Oct 2014 23:36:16 +0200
Raw View
2014-10-21 22:30 GMT+02:00 Myriachan <myriachan@gmail.com>:
> What if an architecture defines extended-precision integers, and std::size_t
> is defined by that architecture to be a size larger than unsigned long long?
While this is a valid argument, it also is actually a possible
defective restriction of user-defined literals. There already exists a
core language related to that:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266
My recommendation for the proposal is to refer to this CWG issue as well.
- Daniel
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: rhalbersma@gmail.com
Date: Tue, 21 Oct 2014 16:19:49 -0700 (PDT)
Raw View
------=_Part_3037_358724269.1413933589763
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=C3=BCgler wrote:
>
> 2014-10-21 22:30 GMT+02:00 Myriachan <myri...@gmail.com <javascript:>>:=
=20
> > What if an architecture defines extended-precision integers, and=20
> std::size_t=20
> > is defined by that architecture to be a size larger than unsigned long=
=20
> long?=20
>
> While this is a valid argument, it also is actually a possible=20
> defective restriction of user-defined literals. There already exists a=20
> core language related to that:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266=20
>
> My recommendation for the proposal is to refer to this CWG issue as well.=
=20
>
Thanks for the guidance. Interestingly, [c.files]/4 contains perhaps a way=
=20
of resolving this:=20
if and only if the type intmax_t designates an extended integer type=20
(3.9.1), the following function
signatures are added:
intmax_t abs(intmax_t);
imaxdiv_t div(intmax_t, intmax_t);=20
Would it be feasible also add an operator"" z(size_t) that takes priority=
=20
in the overload set iff size_t is an extended integer type?
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3037_358724269.1413933589763
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2014-10-21 22=
:30 GMT+02:00 Myriachan <<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"EbwKnStnxGAJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gm=
ail.com</a>>:
<br>> What if an architecture defines extended-precision integers, and s=
td::size_t
<br>> is defined by that architecture to be a size larger than unsigned =
long long?
<br>
<br>While this is a valid argument, it also is actually a possible
<br>defective restriction of user-defined literals. There already exists a
<br>core language related to that:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#=
1266" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_acti=
ve.html%231266\46sa\75D\46sntz\0751\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk=
1Qw';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%2=
31266\46sa\75D\46sntz\0751\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk1Qw';retu=
rn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>=
html#1266</a>
<br>
<br>My recommendation for the proposal is to refer to this CWG issue as wel=
l.
<br></blockquote><div><br></div><div>Thanks for the guidance. Interestingly=
, [c.files]/4 contains perhaps a way of resolving this: </div><div><br=
></div><div>if and only if the type intmax_t designates an extended integer=
type (3.9.1), the following function</div><div>signatures are added:</div>=
<div><br></div><div>intmax_t abs(intmax_t);</div><div>imaxdiv_t div(intmax_=
t, intmax_t); </div><div><br></div><div>Would it be feasible also add =
an operator"" z(size_t) that takes priority in the overload set iff size_t =
is an extended integer type?</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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3037_358724269.1413933589763--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 21 Oct 2014 19:14:31 -0700 (PDT)
Raw View
------=_Part_744_1974207528.1413944071520
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, October 21, 2014 2:36:18 PM UTC-7, Daniel Kr=C3=BCgler wrote:
>
> 2014-10-21 22:30 GMT+02:00 Myriachan <myri...@gmail.com <javascript:>>:=
=20
> > What if an architecture defines extended-precision integers, and=20
> std::size_t=20
> > is defined by that architecture to be a size larger than unsigned long=
=20
> long?=20
>
> While this is a valid argument, it also is actually a possible=20
> defective restriction of user-defined literals. There already exists a=20
> core language related to that:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266=20
>
> My recommendation for the proposal is to refer to this CWG issue as well.=
=20
>
>
I don't really understand the argument in the text of CWG 1266, but the=20
point definitely remains that requiring "unsigned long long" is a bit=20
silly. Paragraph 3 of [lex.ext] implies that if you want to use very long=
=20
literals, don't provide operator ""(unsigned long long) and use one of the=
=20
two raw literal forms instead.
CWG 1266 is nontrivial to solve. Consider GCC's type unsigned __int128. =
=20
Though not formally "extended-precision integer" as defined by the Standard=
=20
due to bad design of std::uintmax_t, GCC and clang support 128-bit integers=
=20
in the form of __int128 for calculations, but do not support integer=20
literals of that size. Requiring supporting extended-precision integers=20
for user-defined literals could be problematic for that reason: the=20
compiler may not have code actually capable of converting such strings to=
=20
the extended-precision types.
(That said, the Standard I don't think supports extended-precision integers=
=20
that do not have built-in literal forms.)
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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_744_1974207528.1413944071520
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 21, 2014 2:36:18 PM UTC-7, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2014-10-21 22=
:30 GMT+02:00 Myriachan <<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"EbwKnStnxGAJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gm=
ail.com</a>>:
<br>> What if an architecture defines extended-precision integers, and s=
td::size_t
<br>> is defined by that architecture to be a size larger than unsigned =
long long?
<br>
<br>While this is a valid argument, it also is actually a possible
<br>defective restriction of user-defined literals. There already exists a
<br>core language related to that:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#=
1266" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_acti=
ve.html%231266\46sa\75D\46sntz\0751\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk=
1Qw';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%2=
31266\46sa\75D\46sntz\0751\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk1Qw';retu=
rn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>=
html#1266</a>
<br>
<br>My recommendation for the proposal is to refer to this CWG issue as wel=
l.
<br>
<br></blockquote><div><br>I don't really understand the argument in the tex=
t of CWG 1266, but the point definitely remains that requiring "unsigned lo=
ng long" is a bit silly. Paragraph 3 of [lex.ext] implies that if you=
want to use very long literals, don't provide operator ""(unsigned long lo=
ng) and use one of the two raw literal forms instead.<br><br>CWG 1266 is no=
ntrivial to solve. Consider GCC's type unsigned __int128. Thoug=
h not formally "extended-precision integer" as defined by the Standard due =
to bad design of std::uintmax_t, GCC and clang support 128-bit integers in =
the form of __int128 for calculations, but do not support integer literals =
of that size. Requiring supporting extended-precision integers for us=
er-defined literals could be problematic for that reason: the compiler may =
not have code actually capable of converting such strings to the extended-p=
recision types.<br><br>(That said, the Standard I don't think supports exte=
nded-precision integers that do not have built-in literal forms.)<br><br>Me=
lissa<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_744_1974207528.1413944071520--
.
Author: rhalbersma@gmail.com
Date: Thu, 23 Oct 2014 01:04:35 -0700 (PDT)
Raw View
------=_Part_379_1599956323.1414051475791
Content-Type: multipart/alternative;
boundary="----=_Part_380_1823176574.1414051475791"
------=_Part_380_1823176574.1414051475791
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=C3=BCgler wrote:
>
> 2014-10-21 22:30 GMT+02:00 Myriachan <myri...@gmail.com <javascript:>>:=
=20
> > What if an architecture defines extended-precision integers, and=20
> std::size_t=20
> > is defined by that architecture to be a size larger than unsigned long=
=20
> long?=20
>
> While this is a valid argument, it also is actually a possible=20
> defective restriction of user-defined literals. There already exists a=20
> core language related to that:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266=20
>
> My recommendation for the proposal is to refer to this CWG issue as well.=
=20
>
> - Daniel=20
>
I spotted two more issues (1620 and 1735). Attached an updated draft=20
proposal.=20
--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_380_1823176574.1414051475791
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2014-10-21 22=
:30 GMT+02:00 Myriachan <<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"EbwKnStnxGAJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gm=
ail.com</a>>:
<br>> What if an architecture defines extended-precision integers, and s=
td::size_t
<br>> is defined by that architecture to be a size larger than unsigned =
long long?
<br>
<br>While this is a valid argument, it also is actually a possible
<br>defective restriction of user-defined literals. There already exists a
<br>core language related to that:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#=
1266" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_acti=
ve.html%231266\46sa\75D\46sntz\0751\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk=
1Qw';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%2=
31266\46sa\75D\46sntz\0751\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk1Qw';retu=
rn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>=
html#1266</a>
<br>
<br>My recommendation for the proposal is to refer to this CWG issue as wel=
l.
<br>
<br>- Daniel
<br></blockquote><div><br></div><div>I spotted two more issues (1620 and 17=
35). Attached an updated draft proposal. </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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_380_1823176574.1414051475791--
------=_Part_379_1599956323.1414051475791
Content-Type: text/html; charset=UTF-8; name=Dxxxx.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=Dxxxx.html
X-Attachment-Id: 494aa235-7903-4ea0-9cf1-19fde92f6938
Content-ID: <494aa235-7903-4ea0-9cf1-19fde92f6938>
<pre><code>Document number: Dxxxx=3D14-xxxx
Date: 2014-10-23
Project: Programming Language C++, Library Evolution Working Group
Reply-to: Rein Halbersma <rhalbersma@gmail.com>
</code></pre>
<h1>User-Defined Literals for <code>size_t</code> (and <code>ptrdiff_t</cod=
e>)</h1>
<h2>Introduction</h2>
<p>Following earlier <a href=3D"https://groups.google.com/a/isocpp.org/foru=
m/#!topic/std-proposals/tGoPjUeHlKo">discussion</a> on <code>std-proposals<=
/code>, we propose the user-defined suffix <code>z</code> for <code>size_t<=
/code> literals. This allows writing code in <a href=3D"http://herbsutter.c=
om/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/">Almost Always=
Auto style</a></p>
<pre><code>for (auto i =3D 0z; i < a.size(); ++i) { /* use i and a[i] */=
}
</code></pre>
<p>that will let the loop variable <code>i</code> be of type <code>size_t</=
code>. Similarly, we propose the suffix <code>t</code> for <code>ptrdiff_t<=
/code> literals. </p>
<h2>Motivation and Scope</h2>
<p>The main motivations for this proposal are:</p>
<ul>
<li><code>int</code> is the default type deduced from integer literals;</li=
>
<li><code>size_t</code> is almost unavoidable when using the Standard Libra=
ry;</li>
<li><code>ptrdiff_t</code> is significantly less ubiquitous, but still hard=
to avoid when doing iterator related manipulations;</li>
<li>comparisons and arithmetic with integer types of mixed signs or differe=
nt conversion ranks can lead to surprises;</li>
<li>surprises range from (pedantic) compiler warnings, value conversions, o=
r even undefined behavior;</li>
<li>eliminating these surprises by explicitly typing <code>size_t</code> an=
d <code>ptrdiff_t</code> literals is rather verbose;</li>
<li>user-defined literals are a type-safe and succinct way to express codin=
g intent;</li>
<li>the suffixes <code>z</code> and <code>t</code> are consisent with the l=
ength modifiers for formatted I/O in the C standard library. </li>
</ul>
<h2>Impact On the Standard</h2>
<p>This proposal does not depend on other library components, and nothing d=
epends on it. It is a pure extension, but does require additions (though no=
modifications) to the standard header <code><cstddef></code>, as out=
lined in the section <strong>Proposed Wording</strong> below. It can be imp=
lemented using C++11 compilers and libraries, and it does not require langu=
age or library features that are not part of C++11.</p>
<p>There are, however, three active CWG issues (<a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266">cwg#1266</a>, <a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1620">cwg#1620<=
/a> and <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.h=
tml#1735">cwg#1735</a>) that could impact this proposal. All three issues n=
ote that in implementations with extended integer types, the decimal-litera=
l in a user-defined-integer-literal might be too large for an <code>unsigne=
d long long</code> to represent. Suggestions (but no formal proposals) were=
made to either fall back to a raw literal operator or a literal operator t=
emplate, or to allow a parameter of an extended integer type. The latter su=
ggestion would be easiest to incorporate into this proposal.</p>
<h2>Design Decisions</h2>
<p>The chosen naming of the literal suffixes <code>z</code> and <code>t</co=
de> was motivated by the corresponding length modifiers for formatted I/O i=
n the C standard library header <code><stdio.h></code>. See 7.21.6.1/=
7 for <code>fprintf</code> and 7.21.6.2/11 <code>fscanf</code>, numbered re=
lative to <a href=3D"http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.=
pdf">WG14/N1539</a>.</p>
<p>The consequences of adopting the proposed literal suffixes into the Stan=
dard are:</p>
<ul>
<li>both novices and occasional programmers, as well as experienced library=
implementors, can use left-to-right <code>auto</code> variable initializat=
ions with <code>size_t</code> and <code>ptrdiff_t</code> literals, without =
having to define their own literal suffixes with leading underscores <code>=
_z</code> and <code>_t</code> in order to do so;</li>
<li>other existing or future Standard Library types are prevented from adop=
ting the same literal suffixes, unless they use overloads of the correspond=
ing <code>operator""</code> that take arguments other than <code>unsigned l=
ong long</code>. </li>
</ul>
<p>This proposal follows the existing practice established in <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3642.pdf">WG21/N3642=
</a> with respect to the <code>constexpr</code> (present) and <code>noexcep=
t</code> (absent) specifiers, as well as the usage of an appropriately name=
d <code>inline namespace std::literals::support_literals</code>.</p>
<p>There are no decisions left up to implementers, because the suggested wo=
rding below fully specifies the proposed functionality. We are not aware of=
similar libraries in use. There is a <a href=3D"https://bitbucket.org/rhal=
bersma/xstd/src/bd4212118116a8b28d97b69d30472e2f1e80f322/include/xstd/cstdd=
ef.hpp?at=3Ddefault">reference implementation</a> and small <a href=3D"http=
s://bitbucket.org/rhalbersma/xstd/src/608b4257b4ec980272edd0876be45a9391d83=
274/test/src/cstddef.cpp?at=3Ddefault">test suite</a> available for inspect=
ion. Note that the reference implementation uses <code>namespace xstd</code=
> and underscored suffixes <code>_t</code> and <code>_z</code> because the =
tested compiler <code>clang</code> will enforce the restriction from <code>=
[lex.ext]/10</code> that a program containing a user-defined suffix without=
an underscore is ill-formed, no diagnostic required. </p>
<h2>Proposed Wording</h2>
<p>Insert in subclause <code>[support.types]/1</code> in the synopsis of he=
ader <code><cstddef></code> at the appropriate place the namespace <c=
ode>std::literals::support_literals</code>: </p>
<pre><code> namespace std {
inline namespace literals {
inline namespace support_literals {
constexpr size_t operator "" z(unsigned long long); =20
constexpr ptrdiff_t operator "" t(unsigned long long); =
=20
}
}
}
</code></pre>
<p>Insert a new subclause <code>[support.literals]</code> between <code>[su=
pport.types]</code> and <code>[support.limits]</code> as follows (numered r=
elative to <a href=3D"https://github.com/cplusplus/draft/blob/master/papers=
/n4140.pdf">WG21/N4140</a>):</p>
<blockquote>
<p><strong>18.3 Suffixes for support types [support.literals]</strong></p=
>
<p>1 This section describes literal suffixes for constructing <code>size_t<=
/code> and <code>ptrdiff_t</code> literals. The suffixes <code>z</code> and=
<code>t</code> create numbers of the types <code>size_t</code> and <code>p=
trdiff_t</code>, respectively. </p>
<pre><code>constexpr size_t operator "" z(unsigned long long u);
</code></pre>
<p>2 Returns: <code>static_cast<size_t>(u)</code>.</p>
<pre><code>constexpr ptrdiff_t operator "" t(unsigned long long u);
</code></pre>
<p>3 Returns: <code>static_cast<ptrdiff_t>(u)</code>.</p>
</blockquote>
<h2>Acknowledgments</h2>
<p>We gratefully acknowledge feedback from Jerry Coffin and Andy Prowl on <=
code><Lounge C++></code> and from Daniel Kr=C3=BCgler and Melissa Myr=
iachan on <code>std-proposals</code>.</p>
<h2>References</h2>
<p><code>[std-proposals]</code>: Morwenn Edrahir, <em>User defined literal =
for size_t</em> <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!t=
opic/std-proposals/tGoPjUeHlKo">https://groups.google.com/a/isocpp.org/foru=
m/#!topic/std-proposals/tGoPjUeHlKo</a> </p>
<p><code>[N3642]</code>: Peter Sommerlad, <em>User-defined Literals for Sta=
ndard Library Types (part 1 - version 4)</em> <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2013/n3642.pdf">http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2013/n3642.pdf</a></p>
<p><code>[GotW #94]</code>: Herb Sutter, <em>AAA Style (Almost Always Auto)=
</em> <a href=3D"http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-styl=
e-almost-always-auto/">http://herbsutter.com/2013/08/12/gotw-94-solution-aa=
a-style-almost-always-auto/</a></p>
------=_Part_379_1599956323.1414051475791--
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 24 Oct 2014 00:22:52 -0700 (PDT)
Raw View
------=_Part_1178_194910878.1414135372192
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, October 23, 2014 1:04:35 AM UTC-7, rhalb...@gmail.com wrote:
>
> On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=C3=BCgler wrote=
:
>>
>> 2014-10-21 22:30 GMT+02:00 Myriachan <myri...@gmail.com>:=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266=20
>> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fcwg_active.html%231266&sa=3DD&sntz=3D1&usg=3DAFQjCNF-0ia=
ERa-5kLOXUJA-2zl-0Dk1Qw>=20
>>
>> My recommendation for the proposal is to refer to this CWG issue as well=
..=20
>>
>> - Daniel=20
>>
>
> I spotted two more issues (1620 and 1735). Attached an updated draft=20
> proposal.=20
>
Perhaps a proposal could fix the 1620, 1723 and 1735 issues? Here are some=
=20
things I think user-defined literals need:
1. An operator "" function may take a single parameter of=20
non-enumeration non-bool integral type, or floating-point type(*). =20
(Don't permit cv-qualification; it's pointless.) Having more than one f=
or=20
a given suffix is ill-formed.
=20
2. Signed types are allowed, but programmers ought to be aware that=20
negative "literals" are actually a unary minus operator applied to a=20
literal, and thus negative values never actually get passed to operator=
=20
"" functions taking a signed type as a parameter.
=20
3. Use of a numeric literal with an operator "" function taking numeric=
=20
type such that that literal overflows the numeric type is ill-formed.
=20
4. Integral and floating-point literals passed to operator "" functions=
=20
of the two signatures:
=20
*T* operator "" *X*(const *[volatile]* char *)
template <*some nonzero or variable number of chars*> *T* operator "" *X=
*
()
=20
for type T and *ud-suffix* X would take a string of arbitrary length of=
=20
the general grammar of a numeric literal, but possibly exceeding the=20
maximum length of a literal of any standard or extended-precision type,=
=20
optionally up to an implementation-defined limit. This=20
implementation-defined limit would be at least sufficient to express any=
=20
nonnegative value of integral type T, or the same length as supported=20
for ordinary floating-point literals of floating-point type T.
=20
5. operator "" for string literals may have a new template form roughly=
=20
corresponding to that available with numeric literals:
=20
template <class C, *zero or more, or variable number, non-type template=
=20
parameters of type C*>
T operator "" X()
=20
where C is one of char, char16_t, char32_t or wchar_t, T is arbitrary,=
=20
and X is the *ud-suffix*. The characters of the concatenated=20
([lex.ext]/6) string literal would become non-type template parameters o=
f=20
type C to this function. (This I believe is already a paper. This one=
=20
is actually considered undesirable for some reason...?)
=20
6. Make multi-character character constants legal for user-defined=20
literals; such literals would work like string literals, except that a) =
a=20
character literal of exactly one character can call the old style (both=
=20
existing would be ill-formed) b) an unused "int" parameter is added to =
the=20
function parameters to distinguish character literals from string=20
literals. Concatenation of character literals would be supported, but o=
nly=20
for user-defined literals. Same for empty character literals. =20
Concatenation of character literals for built-in multi-character charact=
er=20
literals would be conditionally supported; an implementation supporting=
=20
multi-character character literals would have to support concatenation f=
or=20
built-in characters.
=20
Does what I wrote seem reasonable?
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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1178_194910878.1414135372192
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 23, 2014 1:04:35 AM UTC-7, rhalb...@g=
mail.com 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"ltr=
">On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=C3=BCgler wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">2014-10-21 22:30 GMT+02:00 Myriach=
an <<a>myri...@gmail.com</a>>:
<br><a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%231266&sa=3DD&sntz=3D=
1&usg=3DAFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk1Qw" target=3D"_blank" onmousedo=
wn=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%231266\46sa\75D\46sntz\07=
51\46usg\75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk1Qw';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%231266\46sa\75D\46sntz\0751\46usg\=
75AFQjCNF-0iaERa-5kLOXUJA-2zl-0Dk1Qw';return true;">http://www.open-std.org=
/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>html#1266</a>
<br>
<br>My recommendation for the proposal is to refer to this CWG issue as wel=
l.
<br>
<br>- Daniel
<br></blockquote><div><br></div><div>I spotted two more issues (1620 and 17=
35). Attached an updated draft proposal. </div></div></blockquote><div=
><br><br>Perhaps a proposal could fix the 1620, 1723 and 1735 issues? =
Here are some things I think user-defined literals need:<br><br><ol><li>An=
<span style=3D"font-family: courier new,monospace;">operator ""</span> fun=
ction may take a single parameter of non-enumeration non-<span style=3D"fon=
t-family: courier new,monospace;">bool</span> integral type, or floating-po=
int type(*). (Don't permit cv-qualification; it's pointless.) H=
aving more than one for a given suffix is ill-formed.<br><br></li><li>Signe=
d types are allowed, but programmers ought to be aware that negative "liter=
als" are actually a unary minus operator applied to a literal, and thus neg=
ative values never actually get passed to <span style=3D"font-family: couri=
er new,monospace;">operator ""</span> functions taking a signed type as a p=
arameter.<br><br></li><li>Use of a numeric literal with an operator "" func=
tion taking numeric type such that that literal overflows the numeric type =
is ill-formed.<br><br></li><li>Integral and floating-point literals passed =
to operator "" functions of the two signatures:<br><br><span style=3D"font-=
family: courier new,monospace;"><i>T</i> operator "" <i>X</i>(const <i><spa=
n style=3D"font-family: arial,sans-serif;">[</span>volatile<span style=3D"f=
ont-family: arial,sans-serif;">]</span></i> char *)<br>template <</span>=
<i>some nonzero or variable number of <span style=3D"font-family: courier n=
ew,monospace;">char</span>s</i><span style=3D"font-family: courier new,mono=
space;">> <i>T</i> operator "" <i>X</i>()</span><br><br>for type <span s=
tyle=3D"font-family: courier new,monospace;">T</span> and <i>ud-suffix</i> =
<span style=3D"font-family: courier new,monospace;">X</span><font face=3D"a=
rial,sans-serif"> would take a string of arbitrary length of the general gr=
ammar of a numeric literal, but possibly exceeding the maximum length of </=
font>a literal of any standard or extended-precision type, optionally up to=
an implementation-defined limit. This implementation-defined limit w=
ould be at least sufficient to express any nonnegative value of integral ty=
pe <span style=3D"font-family: courier new,monospace;">T</span>, or the sam=
e length as supported for ordinary floating-point literals of floating-poin=
t type <span style=3D"font-family: courier new,monospace;">T</span>.<br><br=
></li><li><span style=3D"font-family: courier new,monospace;">operator ""</=
span> for string literals may have a new template form roughly correspondin=
g to that available with numeric literals:<br><br><span style=3D"font-famil=
y: courier new,monospace;">template <class C,</span> <i>zero or more, or=
variable number, non-type template parameters of type <span style=3D"font-=
family: courier new,monospace;">C</span></i><span style=3D"font-family: cou=
rier new,monospace;">></span><br><span style=3D"font-family: courier new=
,monospace;">T operator "" X()<br></span><br>where C is one of <span style=
=3D"font-family: courier new,monospace;">char</span>, <span style=3D"font-f=
amily: courier new,monospace;">char16_t</span>, <span style=3D"font-family:=
courier new,monospace;">char32_t</span> or <span style=3D"font-family: cou=
rier new,monospace;">wchar_t</span>, T is arbitrary, and X is the <i>ud-suf=
fix</i>. The characters of the concatenated ([lex.ext]/6) string lite=
ral would become non-type template parameters of type <span style=3D"font-f=
amily: courier new,monospace;">C</span> to this function. (This I bel=
ieve is already a paper. This one is actually considered undesirable =
for some reason...?)<br><br></li><li>Make multi-character character constan=
ts legal for user-defined literals; such literals would work like string li=
terals, except that a) a character literal of exactly one character can cal=
l the old style (both existing would be ill-formed) b) an unused "int=
" parameter is added to the function parameters to distinguish character li=
terals from string literals. Concatenation of character literals woul=
d be supported, but only for user-defined literals. Same for empty ch=
aracter literals. Concatenation of character literals for built-in mu=
lti-character character literals would be conditionally supported; an imple=
mentation supporting multi-character character literals would have to suppo=
rt concatenation for built-in characters.<br></li></ol><p><br><br>Does what=
I wrote seem reasonable?</p><p>Melissa<br></p></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1178_194910878.1414135372192--
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Wed, 19 Nov 2014 23:49:31 +0100
Raw View
--001a11c3749e6137e905083e067f
Content-Type: multipart/alternative; boundary=001a11c3749e6137e505083e067d
--001a11c3749e6137e505083e067d
Content-Type: text/plain; charset=UTF-8
Please find attached an updated but not yet final version of an upcoming
proposal for user-defined literals for size_t (and ptrdiff_t). Any feedback
will be appreciated!
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3749e6137e505083e067d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br>Please find attached an upd=
ated but not yet final version of an upcoming proposal for user-defined lit=
erals for size_t (and ptrdiff_t). Any feedback will be appreciated!</div><d=
iv class=3D"gmail_extra"><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3749e6137e505083e067d--
--001a11c3749e6137e905083e067f
Content-Type: text/html; charset=UTF-8; name="D4254.html"
Content-Disposition: attachment; filename="D4254.html"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i2pa6fyr1
PHByZT48Y29kZT5Eb2N1bWVudCBudW1iZXI6IEQ0MjU0CkRhdGU6ICAgICAgICAgICAgMjAxNC0x
MS0xOQpQcm9qZWN0OiAgICAgICAgIFByb2dyYW1taW5nIExhbmd1YWdlIEMrKywgTGlicmFyeSBF
dm9sdXRpb24gV29ya2luZyBHcm91cApSZXBseS10bzogICAgICAgIFJlaW4gSGFsYmVyc21hICZs
dDtyaGFsYmVyc21hIGF0IGdtYWlsIGRvdCBjb20mZ3Q7CjwvY29kZT48L3ByZT4KCjxoMT5Vc2Vy
LURlZmluZWQgTGl0ZXJhbHMgZm9yIDxjb2RlPnNpemVfdDwvY29kZT4gKGFuZCA8Y29kZT5wdHJk
aWZmX3Q8L2NvZGU+KTwvaDE+Cgo8aDI+SW50cm9kdWN0aW9uPC9oMj4KCjxwPkZvbGxvd2luZyBl
YXJsaWVyIDxhIGhyZWY9Imh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9pc29jcHAub3JnL2Zv
cnVtLyMhdG9waWMvc3RkLXByb3Bvc2Fscy90R29QalVlSGxLbyI+ZGlzY3Vzc2lvbjwvYT4gb24g
PGNvZGU+c3RkLXByb3Bvc2FsczwvY29kZT4sIHdlIHByb3Bvc2UgdGhlIHVzZXItZGVmaW5lZCBz
dWZmaXggPGNvZGU+ejwvY29kZT4gZm9yIDxjb2RlPnNpemVfdDwvY29kZT4gbGl0ZXJhbHMuIFRo
aXMgYWxsb3dzIDxjb2RlPmZvcjwvY29kZT4gbG9vcHMgb3ZlciBTdGFuZGFyZCBDb250YWluZXJz
IHdpdGggPGNvZGU+c2l6ZV90PC9jb2RlPiBpbmRleCB2YXJpYWJsZXMgdGhhdCBhcmUgaW5pdGlh
bGl6ZWQgaW4gYSBsZWZ0LXRvLXJpZ2h0IDxjb2RlPmF1dG88L2NvZGU+IHN0eWxlOjwvcD4KCjxw
cmU+PGNvZGU+I2luY2x1ZGUgJmx0O2NzdGRkZWYmZ3Q7CnVzaW5nIG5hbWVzcGFjZSBzdGQ6OnN1
cHBvcnRfbGl0ZXJhbHM7Cgpmb3IgKGF1dG8gaSA9IDB6LCBzID0gdi5zaXplKCk7IGkgJmx0OyBz
OyArK2kpIHsgCiAgLyogdXNlIGkgYW5kIGFbaV0gKi8gCn0KPC9jb2RlPjwvcHJlPgoKPHA+TW9z
dGx5IGZvciByZWFzb25zIG9mIGNvbXBsZXRlbmVzcywgd2UgYWxzbyBwcm9wb3NlIHRoZSBzdWZm
aXggPGNvZGU+dDwvY29kZT4gZm9yIDxjb2RlPnB0cmRpZmZfdDwvY29kZT4gbGl0ZXJhbHMuIDwv
cD4KCjxoMj5Nb3RpdmF0aW9uIGFuZCBTY29wZTwvaDI+Cgo8cD5UaGUgbWFpbiBtb3RpdmF0aW9u
cyBmb3IgdGhpcyBwcm9wb3NhbCBhcmU6PC9wPgoKPHVsPgo8bGk+PGNvZGU+aW50PC9jb2RlPiBp
cyB0aGUgZGVmYXVsdCB0eXBlIGRlZHVjZWQgZnJvbSBpbnRlZ2VyIGxpdGVyYWxzIHdpdGhvdXQg
c3VmZml4OzwvbGk+CjxsaT48Y29kZT5zaXplX3Q8L2NvZGU+IGlzIGFsbW9zdCB1bmF2b2lkYWJs
ZSB3aGVuIHVzaW5nIHRoZSBTdGFuZGFyZCBMaWJyYXJ5OzwvbGk+CjxsaT48Y29kZT5wdHJkaWZm
X3Q8L2NvZGU+IGlzIHNpZ25pZmljYW50bHkgbGVzcyB1YmlxdWl0b3VzLCBidXQgc3RpbGwgaGFy
ZCB0byBhdm9pZCB3aGVuIGRvaW5nIGl0ZXJhdG9yIHJlbGF0ZWQgbWFuaXB1bGF0aW9uczs8L2xp
Pgo8bGk+Y29tcGFyaXNvbnMgYW5kIGFyaXRobWV0aWMgd2l0aCBpbnRlZ2VyIHR5cGVzIG9mIG1p
eGVkIHNpZ25zIG9yIGRpZmZlcmVudCBjb252ZXJzaW9uIHJhbmtzIGNhbiBsZWFkIHRvIHN1cnBy
aXNlczs8L2xpPgo8bGk+c3VycHJpc2VzIHJhbmdlIGZyb20gKHBlZGFudGljKSBjb21waWxlciB3
YXJuaW5ncywgdmFsdWUgY29udmVyc2lvbnMsIG9yIGV2ZW4gdW5kZWZpbmVkIGJlaGF2aW9yOzwv
bGk+CjxsaT5lbGltaW5hdGluZyB0aGVzZSBzdXJwcmlzZXMgYnkgZXhwbGljaXRseSB0eXBpbmcg
PGNvZGU+c2l6ZV90PC9jb2RlPiBhbmQgPGNvZGU+cHRyZGlmZl90PC9jb2RlPiBsaXRlcmFscyBp
cyByYXRoZXIgdmVyYm9zZTs8L2xpPgo8bGk+dXNlci1kZWZpbmVkIGxpdGVyYWxzIGFyZSBhIHR5
cGUtc2FmZSBhbmQgc3VjY2luY3Qgd2F5IHRvIGV4cHJlc3MgY29kaW5nIGludGVudDs8L2xpPgo8
bGk+dGhlIHN1ZmZpeGVzIDxjb2RlPno8L2NvZGU+IGFuZCA8Y29kZT50PC9jb2RlPiBhcmUgY29u
c2lzZW50IHdpdGggdGhlIGxlbmd0aCBtb2RpZmllcnMgZm9yIGZvcm1hdHRlZCBJL08gaW4gdGhl
IEMgc3RhbmRhcmQgbGlicmFyeS48L2xpPgo8L3VsPgoKPGgyPkV4YW1wbGU8L2gyPgoKPHA+QWdh
aW4gY29uc2lkZXIgdGhlIHByb3Bvc2VkIHN5bnRheCBmcm9tIHRoZSBJbnRyb2R1Y3Rpb248L3A+
Cgo8cHJlPjxjb2RlPmZvciAoYXV0byBpID0gMHosIHMgPSB2LnNpemUoKTsgaSAmbHQ7IHM7ICsr
aSkgeyAvKiAuLi4gKi8gfQo8L2NvZGU+PC9wcmU+Cgo8cD5UaGlzIGNvZGUgc3R5bGUgc3VjY2lu
Y3RseSBhbmQgc2FmZWx5IGNhY2hlcyB0aGUgdmVjdG9yJ3Mgc2l6ZSwgc2ltaWxhciB0byAgdGhl
IDxjb2RlPmVuZCgpPC9jb2RlPiBpdGVyYXRvcidzIGNhY2hpbmcgaW4gYSByYW5nZS1iYXNlZCA8
Y29kZT5mb3I8L2NvZGU+IHN0YXRlbWVudC4gVGhpcyBhbHNvIGZpdHMgbmljZWx5IHdpdGggdGhl
IGVhcmxpZXIgbWVudGlvbiBvZiBhIGxlZnQtdG8tcmlnaHQgPGNvZGU+YXV0bzwvY29kZT4gdmFy
aWFibGUgaW5pdGlhbGl6YXRpb24sIGFzIGlzIHN0cm9uZ2x5IHJlY29tbWVkZWQgaW4gPGEgaHJl
Zj0iaHR0cDovL2hlcmJzdXR0ZXIuY29tLzIwMTMvMDgvMTIvZ290dy05NC1zb2x1dGlvbi1hYWEt
c3R5bGUtYWxtb3N0LWFsd2F5cy1hdXRvLyI+R290VyAjOTQ8L2E+IGFuZCA8YSBocmVmPSJodHRw
Oi8vc2hvcC5vcmVpbGx5LmNvbS9wcm9kdWN0LzA2MzY5MjAwMzM3MDcuZG8iPkVmZmVjdGl2ZSBN
b2Rlcm4gQysrLCBJdGVtIDU8L2E+LjwvcD4KCjxwPkluIHRoZSB1bmxpa2VseSBldmVudCB0aGF0
IHRoZSB2ZWN0b3IncyA8Y29kZT5zaXplX3R5cGU8L2NvZGU+IGlzIG5vdCBlcXVhbCB0byA8Y29k
ZT5zaXplX3Q8L2NvZGU+IChlLmcuIGJlY2F1c2Ugb2YgYSB1c2VyLWRlZmluZWQgYWxsb2NhdG9y
KSwgY29tcGlsYXRpb24gd2lsbCBzaW1wbHkgZmFpbC4gVW5kZXIgdGhlc2UgY2lyY3Vtc3RhbmNl
cyAoYXMgd2VsbCBhcyBpbiBmdWxseSBnZW5lcmljIGNvZGUpLCBvbmUgaGFzIHRvIHJlbHkgb24g
dGhlIHJhdGhlciB2ZXJib3NlPC9wPgoKPHByZT48Y29kZT5mb3IgKGRlY2x0eXBlKHYuc2l6ZSgp
KSBpID0gMCwgcyA9IHYuc2l6ZSgpOyBpICZsdDsgczsgKytpKSB7IC8qIC4uLiAqLyB9CjwvY29k
ZT48L3ByZT4KCjxwPk5vdGUgdGhhdCBhbiA8Y29kZT5hdXRvPC9jb2RlPiB2ZXJzaW9uIHdpdGhv
dXQgYW55IGxpdGVyYWwgc3VmZml4IGNvbWVzIHdpdGggYSBsb3Qgb2YgdGhvcm55IGlzc3Vlczwv
cD4KCjxwcmU+PGNvZGU+Zm9yIChhdXRvIGkgPSAwOyBpICZsdDsgdi5zaXplKCk7ICsraSkgeyAg
ICAgLy8gLVdzaWduLWNvbXBhcmUKICBzdGQ6OmNvdXQgJmx0OyZsdDsgaSAmbHQ7Jmx0OyAiOiAi
ICZsdDsmbHQ7IHZbaV0gJmx0OyZsdDsgJ1xuJzsgLy8gLVdzaWduLWNvbnZlcnNpb24KfQo8L2Nv
ZGU+PC9wcmU+Cgo8cD5GaXJzdCwgdGhlIGFib3ZlIGNvZGUgZGVkdWNlcyA8Y29kZT5pPC9jb2Rl
PiB0byBiZSBvZiB0eXBlIDxjb2RlPmludDwvY29kZT4sIHdoaWNoIG1lYW5zIHdlIGNhbm5vdCBj
YWNoZSB0aGUgdmVjdG9yJ3Mgc2l6ZSAod2hpY2ggaXMgZ3VhcmFudGVlZCBvZiB1bnNpZ25lZCBp
bnRlZ2VyIHR5cGUpIGluc2lkZSB0aGUgbG9vcCdzIGluaXQtc3RhdGVtZW50LiBTZWNvbmQsIHRo
ZSBhYm92ZSB0cmlnZ2VycyBjb21tb24gY29tcGlsZXJzIHdhcm5pbmdzIChzaG93biBmb3IgQ2xh
bmcgYW5kIGcrKykuIEFkbWl0dGVkbHksIHRob3NlIHdhcm5pbmdzIGFyZSByYXRoZXIgc3RyaW5n
ZW50LCBidXQgdGhleSBhcmUgbm90IGluIGdlbmVyYWwgaGFybWxlc3MuIEZ1cnRoZXJtb3JlLCBp
biBtYW55IHBsYWNlcywgZGV2ZWxvcGVycyBhcmUgbm90IGZyZWUgdG8gYWRqdXN0IHByb2plY3Qt
d2lkZSBtYW5kYXRvcnkgd2FybmluZyBsZXZlbHMuPC9wPgoKPHA+SXQgaXMgdGVtcHRpbmcgdG8g
YXNzdW1lIHRoYXQgdGhlIGZvbGxvd2luZyBjb2RlIGlzIGEgc2FmZSBhbHRlcm5hdGl2ZSA8L3A+
Cgo8cHJlPjxjb2RlPmZvciAoYXV0byBpID0gMHU7IGkgJmx0OyB2LnNpemUoKTsgKytpKSB7IC8q
IC4uLiAqLyB9CjwvY29kZT48L3ByZT4KCjxwPkhlcmUsIHRoZSBzdWZmaXhlZCBsaXRlcmFsIDxj
b2RlPjB1PC9jb2RlPiB3aWxsIHNpbGVuY2UgYW55IHNpZ24tcmVsYXRlZCB3YXJuaW5ncy4gSG93
ZXZlciwgdGhlIGFib3ZlIG1pZ2h0IGVudGFpbCB1bmRlZmluZWQgYmVoYXZpb3IgKHdpdGggbm8g
ZGlhZ25vc3RpYyByZXF1aXJlZCEpIHdoZW5ldmVyIDxjb2RlPnYuc2l6ZSgpPC9jb2RlPiBpcyBi
ZXlvbmQgdGhlIHJhbmdlIG9mIGFuIDxjb2RlPnVuc2lnbmVkPC9jb2RlPiAoZS5nLiBtb3JlIHRo
YW4gPGNvZGU+Ml4zMjwvY29kZT4gZWxlbWVudHMgb24gbW9zdCA2NC1iaXQgc3lzdGVtcykgc2lu
Y2UgdGhlbiB0aGUgbG9vcCB2YXJpYWJsZSA8Y29kZT5pPC9jb2RlPiB3aWxsIHdyYXAtYXJvdW5k
LCBuZXZlciBhY3R1YWxseSByZWFjaGluZyB0aGUgYm91bmQuIFByZWxpbWluYXJ5IHRlc3RzIHdp
dGggQ2xhbmcgYW5kIGcrKyBpbmRpY2F0ZSB0aGF0IGluIHByYWN0aWNlIG5vIGRpYWdub3N0aWNz
IHdpbGwgYmUgZ2l2ZW4gdW5sZXNzIHRoZSBsb29wJ3MgYm91bmQgY29tZXMgZnJvbSBhIDxjb2Rl
PmNvbnN0ZXhwciBzaXplKCk8L2NvZGU+IG1lbWJlciBmdW5jdGlvbiBmcm9tIGEgPGNvZGU+Y29u
c3RleHByPC9jb2RlPiBjb250YWluZXIgb2JqZWN0LCB3aGljaCBjYW4gb25seSBiZSBzYXRpc2Zp
ZWQgYnkgPGNvZGU+c3RkOjphcnJheTwvY29kZT4uPC9wPgoKPHA+VGhlIGNsb3Nlc3QgYWx0ZXJu
YXRpdmUgdG8gdGhpcyBwcm9wb3NhbCBpcyB0byB3cml0ZSAob3Iga2VlcCB3cml0aW5nKTwvcD4K
CjxwcmU+PGNvZGU+Zm9yIChzdGQ6OnNpemVfdCBpID0gMCwgcyA9IHYuc2l6ZSgpOyBpICZsdDsg
czsgKytpKSB7IC8qIC4uLiAqLyB9CjwvY29kZT48L3ByZT4KCjxwPlRoaXMgd29ya3MgdW5kZXIg
dGhlIHNhbWUgY2lyY3Vtc3RhbmNlcyBhcyB0aGlzIHByb3Bvc2FsICh3aXRoIGEgZmFsbGJhY2sg
dG8gPGNvZGU+ZGVjbHR5cGUodi5zaXplKCkpPC9jb2RlPiBmb3IgZXhvdGljIGNvbnRhaW5lcnMg
b3IgZnVsbHkgZ2VuZXJpYyBjb2RlKS4gSXRzIGRyYXdiYWNrIGlzIHRoYXQgaXQgaXMgc2xpZ2h0
bHkgbW9yZSB2ZXJib3NlLCBhbmQgdGhhdCBpdCBmb3JtcyBhbiBleGNlcHRpb24gb24gdGhlIGNv
bnZlbmllbnQgbGVmdC10by1yaWdodCA8Y29kZT5hdXRvPC9jb2RlPiB2YXJpYWJsZSBpbml0aWFs
aXphdGlvbiB0aGF0IGlzIGF2YWlsYWJsZSBmb3IgYm90aCBzaWduZWQgYW5kIHVuc2lnbmVkIGlu
dGVnZXJzLiBBZG1pdHRlZGx5LCB0aGlzIGlzIGEgbWF0dGVyIG9mIGNvZGluZyBzdHlsZSwgYnV0
IHRoaXMgcHJvcG9zYWwgZG9lcyBub3QgPGVtPmVuZm9yY2U8L2VtPiB0aGUgdXNlIG9mIDxjb2Rl
PnNpemVfdDwvY29kZT4gbGl0ZXJhbHMsIGl0IG1lcmVseSA8ZW0+ZW5hYmxlczwvZW0+IChhcyB3
ZWxsIGFzIGVuY291cmFnZXMpIHRoZW0uPC9wPgoKPGgyPkltcGFjdCBPbiB0aGUgU3RhbmRhcmQ8
L2gyPgoKPHA+VGhpcyBwcm9wb3NhbCBkb2VzIG5vdCBkZXBlbmQgb24gb3RoZXIgbGlicmFyeSBj
b21wb25lbnRzLCBhbmQgbm90aGluZyBkZXBlbmRzIG9uIGl0LiBJdCBpcyBhIHB1cmUgZXh0ZW5z
aW9uLCBidXQgZG9lcyByZXF1aXJlIGFkZGl0aW9ucyAodGhvdWdoIG5vIG1vZGlmaWNhdGlvbnMp
IHRvIHRoZSBzdGFuZGFyZCBoZWFkZXIgPGNvZGU+Jmx0O2NzdGRkZWYmZ3Q7PC9jb2RlPiwgYXMg
b3V0bGluZWQgaW4gdGhlIHNlY3Rpb24gUHJvcG9zZWQgV29yZGluZyBiZWxvdy4gSXQgY2FuIGJl
IGltcGxlbWVudGVkIHVzaW5nIEMrKzE0IGNvbXBpbGVycyBhbmQgbGlicmFyaWVzLCBhbmQgaXQg
ZG9lcyBub3QgcmVxdWlyZSBsYW5ndWFnZSBvciBsaWJyYXJ5IGZlYXR1cmVzIHRoYXQgYXJlIG5v
dCBwYXJ0IG9mIEMrKzE0LiBJbiBmYWN0LCB0aGlzIHByb3Bvc2FsIGlzIGVudGlyZWx5IGltcGxl
bWVudGFibGUgdXNpbmcgb25seSBDKysxMSBsYW5ndWFnZSBmZWF0dXJlcy48L3A+Cgo8cD5UaGVy
ZSBhcmUsIGhvd2V2ZXIsIHRocmVlIGFjdGl2ZSBDV0cgaXNzdWVzICg8YSBocmVmPSJodHRwOi8v
d3d3Lm9wZW4tc3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL2N3Z19hY3RpdmUuaHRtbCMxMjY2
Ij5jd2cjMTI2NjwvYT4sIDxhIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2My
Mi93ZzIxL2RvY3MvY3dnX2FjdGl2ZS5odG1sIzE2MjAiPmN3ZyMxNjIwPC9hPiBhbmQgPGEgaHJl
Zj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMjEvZG9jcy9jd2dfYWN0aXZl
Lmh0bWwjMTczNSI+Y3dnIzE3MzU8L2E+KSB0aGF0IGNvdWxkIGltcGFjdCB0aGlzIHByb3Bvc2Fs
LiBBbGwgdGhyZWUgaXNzdWVzIG5vdGUgdGhhdCBpbiBpbXBsZW1lbnRhdGlvbnMgd2l0aCBleHRl
bmRlZCBpbnRlZ2VyIHR5cGVzLCB0aGUgZGVjaW1hbC1saXRlcmFsIGluIGEgdXNlci1kZWZpbmVk
LWludGVnZXItbGl0ZXJhbCBtaWdodCBiZSB0b28gbGFyZ2UgZm9yIGFuIDxjb2RlPnVuc2lnbmVk
IGxvbmcgbG9uZzwvY29kZT4gdG8gcmVwcmVzZW50LiBTdWdnZXN0aW9ucyAoYnV0IG5vIGZvcm1h
bCBwcm9wb3NhbHMpIHdlcmUgbWFkZSB0byBlaXRoZXIgZmFsbCBiYWNrIHRvIGEgcmF3IGxpdGVy
YWwgb3BlcmF0b3Igb3IgYSBsaXRlcmFsIG9wZXJhdG9yIHRlbXBsYXRlLCBvciB0byBhbGxvdyBh
IHBhcmFtZXRlciBvZiBhbiBleHRlbmRlZCBpbnRlZ2VyIHR5cGUuIFRoZSBsYXR0ZXIgc3VnZ2Vz
dGlvbiB3b3VsZCBiZSBlYXNpZXN0IHRvIGluY29ycG9yYXRlIGludG8gdGhpcyBwcm9wb3NhbC48
L3A+Cgo8aDI+RGVzaWduIERlY2lzaW9uczwvaDI+Cgo8cD5UaGUgY2hvc2VuIG5hbWluZyBvZiB0
aGUgbGl0ZXJhbCBzdWZmaXhlcyA8Y29kZT56PC9jb2RlPiBhbmQgPGNvZGU+dDwvY29kZT4gd2Fz
IG1vdGl2YXRlZCBieSB0aGUgY29ycmVzcG9uZGluZyBsZW5ndGggbW9kaWZpZXJzIGZvciBmb3Jt
YXR0ZWQgSS9PIGluIHRoZSBDIHN0YW5kYXJkIGxpYnJhcnkgaGVhZGVyIDxjb2RlPiZsdDtzdGRp
by5oJmd0OzwvY29kZT4uIFNlZSA3LjIxLjYuMS83IGZvciA8Y29kZT5mcHJpbnRmPC9jb2RlPiBh
bmQgNy4yMS42LjIvMTEgPGNvZGU+ZnNjYW5mPC9jb2RlPiwgbnVtYmVyZWQgcmVsYXRpdmUgdG8g
PGEgaHJlZj0iaHR0cDovL3d3dy5vcGVuLXN0ZC5vcmcvanRjMS9zYzIyL3dnMTQvd3d3L2RvY3Mv
bjE1MzkucGRmIj5XRzE0L04xNTM5PC9hPi48L3A+Cgo8cD5UaGUgY29uc2VxdWVuY2VzIG9mIGFk
b3B0aW5nIHRoZSBwcm9wb3NlZCBsaXRlcmFsIHN1ZmZpeGVzIGludG8gdGhlIFN0YW5kYXJkIGFy
ZTo8L3A+Cgo8dWw+CjxsaT5ib3RoIG5vdmljZXMgYW5kIG9jY2FzaW9uYWwgcHJvZ3JhbW1lcnMs
IGFzIHdlbGwgYXMgZXhwZXJpZW5jZWQgbGlicmFyeSBpbXBsZW1lbnRvcnMsIGNhbiB1c2UgbGVm
dC10by1yaWdodCA8Y29kZT5hdXRvPC9jb2RlPiB2YXJpYWJsZSBpbml0aWFsaXphdGlvbnMgd2l0
aCA8Y29kZT5zaXplX3Q8L2NvZGU+IGFuZCA8Y29kZT5wdHJkaWZmX3Q8L2NvZGU+IGxpdGVyYWxz
LCB3aXRob3V0IGhhdmluZyB0byBkZWZpbmUgdGhlaXIgb3duIGxpdGVyYWwgc3VmZml4ZXMgd2l0
aCBsZWFkaW5nIHVuZGVyc2NvcmVzIDxjb2RlPl96PC9jb2RlPiBhbmQgPGNvZGU+X3Q8L2NvZGU+
IGluIG9yZGVyIHRvIGRvIHNvOzwvbGk+CjxsaT5vdGhlciBleGlzdGluZyBvciBmdXR1cmUgU3Rh
bmRhcmQgTGlicmFyeSB0eXBlcyBhcmUgcHJldmVudGVkIGZyb20gYWRvcHRpbmcgdGhlIHNhbWUg
bGl0ZXJhbCBzdWZmaXhlcywgdW5sZXNzIHRoZXkgdXNlIG92ZXJsb2FkcyBvZiB0aGUgY29ycmVz
cG9uZGluZyA8Y29kZT5vcGVyYXRvciAiIjwvY29kZT4gdGhhdCB0YWtlIGFyZ3VtZW50cyBvdGhl
ciB0aGFuIDxjb2RlPnVuc2lnbmVkIGxvbmcgbG9uZzwvY29kZT4uIDwvbGk+CjwvdWw+Cgo8cD5U
aGlzIHByb3Bvc2FsIGZvbGxvd3MgdGhlIGV4aXN0aW5nIHByYWN0aWNlIGVzdGFibGlzaGVkIGlu
IDxhIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0YzEvc2MyMi93ZzIxL2RvY3MvcGFw
ZXJzLzIwMTMvbjM2NDIucGRmIj5XRzIxL04zNjQyPC9hPiB3aXRoIHJlc3BlY3QgdG8gdGhlIDxj
b2RlPmNvbnN0ZXhwcjwvY29kZT4gKHByZXNlbnQpIGFuZCA8Y29kZT5ub2V4Y2VwdDwvY29kZT4g
KGFic2VudCkgc3BlY2lmaWVycywgYXMgd2VsbCBhcyB0aGUgdXNhZ2Ugb2YgYW4gYXBwcm9wcmlh
dGVseSBuYW1lZCA8Y29kZT5pbmxpbmUgbmFtZXNwYWNlIHN0ZDo6bGl0ZXJhbHM6OnN1cHBvcnRf
bGl0ZXJhbHM8L2NvZGU+LjwvcD4KCjxwPlRoZXJlIGFyZSBubyBkZWNpc2lvbnMgbGVmdCB1cCB0
byBpbXBsZW1lbnRlcnMsIGJlY2F1c2UgdGhlIHN1Z2dlc3RlZCB3b3JkaW5nIGJlbG93IGZ1bGx5
IHNwZWNpZmllcyB0aGUgcHJvcG9zZWQgZnVuY3Rpb25hbGl0eS4gV2UgYXJlIG5vdCBhd2FyZSBv
ZiBzaW1pbGFyIGxpYnJhcmllcyBpbiB1c2UuIFRoZXJlIGlzIGEgPGEgaHJlZj0iaHR0cHM6Ly9i
aXRidWNrZXQub3JnL3JoYWxiZXJzbWEveHN0ZC9zcmMvM2RkZmE4ZTlkMjRhMDM0OWI4NzU3MDll
N2I2MDk1NjhkNzY4NGQ5ZC9pbmNsdWRlL3hzdGQvY3N0ZGRlZi5ocHA/YXQ9ZGVmYXVsdCI+cmVm
ZXJlbmNlIGltcGxlbWVudGF0aW9uPC9hPiBhbmQgc21hbGwgPGEgaHJlZj0iaHR0cHM6Ly9iaXRi
dWNrZXQub3JnL3JoYWxiZXJzbWEveHN0ZC9zcmMvM2RkZmE4ZTlkMjRhMDM0OWI4NzU3MDllN2I2
MDk1NjhkNzY4NGQ5ZC90ZXN0L3NyYy9jc3RkZGVmLmNwcD9hdD1kZWZhdWx0Ij50ZXN0IHN1aXRl
PC9hPiBhdmFpbGFibGUgZm9yIGluc3BlY3Rpb24uIE5vdGUgdGhhdCB0aGUgcmVmZXJlbmNlIGlt
cGxlbWVudGF0aW9uIHVzZXMgPGNvZGU+bmFtZXNwYWNlIHhzdGQ8L2NvZGU+IGFuZCB1bmRlcnNj
b3JlZCBzdWZmaXhlcyA8Y29kZT5fejwvY29kZT4gYW5kIDxjb2RlPl90PC9jb2RlPiBiZWNhdXNl
IHRoZSB0ZXN0ZWQgY29tcGlsZXIgPGNvZGU+Q2xhbmc8L2NvZGU+IHdpbGwgZW5mb3JjZSB0aGUg
cmVzdHJpY3Rpb24gZnJvbSA8Y29kZT5bbGV4LmV4dF0vMTA8L2NvZGU+IHRoYXQgYSBwcm9ncmFt
IGNvbnRhaW5pbmcgYSB1c2VyLWRlZmluZWQgc3VmZml4IHdpdGhvdXQgYW4gdW5kZXJzY29yZSBp
cyBpbGwtZm9ybWVkLCBubyBkaWFnbm9zdGljIHJlcXVpcmVkLiAgIDwvcD4KCjxoMj5Qcm9wb3Nl
ZCBXb3JkaW5nPC9oMj4KCjxwPkluc2VydCBpbiBzdWJjbGF1c2UgPGNvZGU+W3N1cHBvcnQudHlw
ZXNdLzE8L2NvZGU+IGluIHRoZSBzeW5vcHNpcyBvZiBoZWFkZXIgPGNvZGU+Jmx0O2NzdGRkZWYm
Z3Q7PC9jb2RlPiBhdCB0aGUgYXBwcm9wcmlhdGUgcGxhY2UgdGhlIG5hbWVzcGFjZSA8Y29kZT5z
dGQ6OmxpdGVyYWxzOjpzdXBwb3J0X2xpdGVyYWxzPC9jb2RlPjogPC9wPgoKPHByZT48Y29kZT4g
ICAgICAgIG5hbWVzcGFjZSBzdGQgewogICAgICAgICAgaW5saW5lIG5hbWVzcGFjZSBsaXRlcmFs
cyB7CiAgICAgICAgICAgIGlubGluZSBuYW1lc3BhY2Ugc3VwcG9ydF9saXRlcmFscyB7CiAgICAg
ICAgICAgICAgY29uc3RleHByIHNpemVfdCBvcGVyYXRvciAiIiB6KHVuc2lnbmVkIGxvbmcgbG9u
Zyk7ICAgICAgIAogICAgICAgICAgICAgIGNvbnN0ZXhwciBwdHJkaWZmX3Qgb3BlcmF0b3IgIiIg
dCh1bnNpZ25lZCBsb25nIGxvbmcpOyAgICAgICAgCiAgICAgICAgICAgIH0KICAgICAgICAgIH0K
ICAgICAgICB9CjwvY29kZT48L3ByZT4KCjxwPkluc2VydCBhIG5ldyBzdWJjbGF1c2UgPGNvZGU+
W3N1cHBvcnQubGl0ZXJhbHNdPC9jb2RlPiBiZXR3ZWVuIDxjb2RlPltzdXBwb3J0LnR5cGVzXTwv
Y29kZT4gYW5kIDxjb2RlPltzdXBwb3J0LmxpbWl0c108L2NvZGU+IGFzIGZvbGxvd3MgKG51bWVy
ZWQgcmVsYXRpdmUgdG8gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NwbHVzcGx1cy9kcmFm
dC9ibG9iL21hc3Rlci9wYXBlcnMvbjQxNDAucGRmIj5XRzIxL040MTQwPC9hPik6PC9wPgoKPGJs
b2NrcXVvdGU+CiAgPHA+PHN0cm9uZz4xOC4zIFN1ZmZpeGVzIGZvciBzdXBwb3J0IHR5cGVzIFtz
dXBwb3J0LmxpdGVyYWxzXTwvc3Ryb25nPjwvcD4KCjxwPjEgVGhpcyBzZWN0aW9uIGRlc2NyaWJl
cyBsaXRlcmFsIHN1ZmZpeGVzIGZvciBjb25zdHJ1Y3RpbmcgPGNvZGU+c2l6ZV90PC9jb2RlPiBh
bmQgPGNvZGU+cHRyZGlmZl90PC9jb2RlPiBsaXRlcmFscy4gVGhlIHN1ZmZpeGVzIDxjb2RlPno8
L2NvZGU+IGFuZCA8Y29kZT50PC9jb2RlPiBjcmVhdGUgbnVtYmVycyBvZiB0aGUgdHlwZXMgPGNv
ZGU+c2l6ZV90PC9jb2RlPiBhbmQgPGNvZGU+cHRyZGlmZl90PC9jb2RlPiwgcmVzcGVjdGl2ZWx5
LiA8L3A+Cgo8cHJlPjxjb2RlPmNvbnN0ZXhwciBzaXplX3Qgb3BlcmF0b3IgIiIgeih1bnNpZ25l
ZCBsb25nIGxvbmcgdSk7CjwvY29kZT48L3ByZT4KCjxwPjIgUmV0dXJuczogPGNvZGU+c3RhdGlj
X2Nhc3QmbHQ7c2l6ZV90Jmd0Oyh1KTwvY29kZT4uPC9wPgoKPHByZT48Y29kZT5jb25zdGV4cHIg
cHRyZGlmZl90IG9wZXJhdG9yICIiIHQodW5zaWduZWQgbG9uZyBsb25nIHUpOwo8L2NvZGU+PC9w
cmU+Cgo8cD4zIFJldHVybnM6IDxjb2RlPnN0YXRpY19jYXN0Jmx0O3B0cmRpZmZfdCZndDsodSk8
L2NvZGU+LjwvcD4KPC9ibG9ja3F1b3RlPgoKPGgyPkFja25vd2xlZGdtZW50czwvaDI+Cgo8cD5X
ZSBncmF0ZWZ1bGx5IGFja25vd2xlZGdlIGZlZWRiYWNrIGZyb20gSmVycnkgQ29mZmluIGFuZCBB
bmR5IFByb3dsIG9uIDxjb2RlPiZsdDtMb3VuZ2UgQysrJmd0OzwvY29kZT4gYW5kIGZyb20gRGFu
aWVsIEtyw7xnbGVyIGFuZCBNZWxpc3NhIE1lYXJzIG9uIDxjb2RlPnN0ZC1wcm9wb3NhbHM8L2Nv
ZGU+LjwvcD4KCjxoMj5SZWZlcmVuY2VzPC9oMj4KCjxwPjxjb2RlPltzdGQtcHJvcG9zYWxzXTwv
Y29kZT46IE1vcndlbm4gRWRyYWhpciwgPGVtPlVzZXIgZGVmaW5lZCBsaXRlcmFsIGZvciBzaXpl
X3Q8L2VtPiA8YSBocmVmPSJodHRwczovL2dyb3Vwcy5nb29nbGUuY29tL2EvaXNvY3BwLm9yZy9m
b3J1bS8jIXRvcGljL3N0ZC1wcm9wb3NhbHMvdEdvUGpVZUhsS28iPmh0dHBzOi8vZ3JvdXBzLmdv
b2dsZS5jb20vYS9pc29jcHAub3JnL2ZvcnVtLyMhdG9waWMvc3RkLXByb3Bvc2Fscy90R29QalVl
SGxLbzwvYT4gPC9wPgoKPHA+PGNvZGU+W04zNjQyXTwvY29kZT46IFBldGVyIFNvbW1lcmxhZCwg
PGVtPlVzZXItZGVmaW5lZCBMaXRlcmFscyBmb3IgU3RhbmRhcmQgTGlicmFyeSBUeXBlcyAocGFy
dCAxIC0gdmVyc2lvbiA0KTwvZW0+IDxhIGhyZWY9Imh0dHA6Ly93d3cub3Blbi1zdGQub3JnL2p0
YzEvc2MyMi93ZzIxL2RvY3MvcGFwZXJzLzIwMTMvbjM2NDIucGRmIj5odHRwOi8vd3d3Lm9wZW4t
c3RkLm9yZy9qdGMxL3NjMjIvd2cyMS9kb2NzL3BhcGVycy8yMDEzL24zNjQyLnBkZjwvYT48L3A+
Cgo8cD48Y29kZT5bR290VyAjOTRdPC9jb2RlPjogSGVyYiBTdXR0ZXIsIDxlbT5BQUEgU3R5bGUg
KEFsbW9zdCBBbHdheXMgQXV0byk8L2VtPiA8YSBocmVmPSJodHRwOi8vaGVyYnN1dHRlci5jb20v
MjAxMy8wOC8xMi9nb3R3LTk0LXNvbHV0aW9uLWFhYS1zdHlsZS1hbG1vc3QtYWx3YXlzLWF1dG8v
Ij5odHRwOi8vaGVyYnN1dHRlci5jb20vMjAxMy8wOC8xMi9nb3R3LTk0LXNvbHV0aW9uLWFhYS1z
dHlsZS1hbG1vc3QtYWx3YXlzLWF1dG8vPC9hPjwvcD4KCjxwPjxjb2RlPltFZmZlY3RpdmUgTW9k
ZXJuIEMrK108L2NvZGU+OiBTY290dCBNZXllcnMsIDxlbT40MiBTcGVjaWZpYyBXYXlzIHRvIElt
cHJvdmUgWW91ciBVc2Ugb2YgQysrMTEgYW5kIEMrKzE0PC9lbT4gKDxlbT5JdGVtIDU64oCCUHJl
ZmVyIGF1dG8gdG8gZXhwbGljaXQgdHlwZSBkZWNsYXJhdGlvbnMuPC9lbT4pIDxhIGhyZWY9Imh0
dHA6Ly9zaG9wLm9yZWlsbHkuY29tL3Byb2R1Y3QvMDYzNjkyMDAzMzcwNy5kbyI+aHR0cDovL3No
b3Aub3JlaWxseS5jb20vcHJvZHVjdC8wNjM2OTIwMDMzNzA3LmRvPC9hPjwvcD4K
--001a11c3749e6137e905083e067f--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 19 Nov 2014 18:18:51 -0500
Raw View
On 2014-11-19 17:49, Rein Halbersma wrote:
> Please find attached an updated but not yet final version of an upcoming
> proposal for user-defined literals for size_t (and ptrdiff_t).
While I'm not against this in general...
> for (auto i = 0z, s = v.size(); i < s; ++i) {
> /* use i and a[i] */
> }
....I don't think this is a good motivating example. I would always write
this like 'i = decltype(v.size()){0}', because the point of 'auto' here
is that I don't want to be bothered with having to know the return type
of 'v.size()'. Using a literal suffix here defeats that purpose.
(What if I replace 'v' with a QVector? Then 'decltype(v.size())' is
'int', and all sorts of bad - the specific bad you're looking to avoid,
in fact, but in the opposite direction - happens if I used '0z'.)
And anyway this particular example is *MUCH* better written:
for (auto i : bikeshed(v.size())
(...for whatever 'bikeshed' ends up being called.)
:-)
I could come up with better motivating examples, however. For instance:
static constexpr auto NUM_COEFFICIENTS = 4z;
std::array<double, NUM_COEFFICIENTS> cubic_polynomial;
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 19 Nov 2014 15:43:18 -0800
Raw View
On Wednesday 19 November 2014 18:18:51 Matthew Woehlke wrote:
> On 2014-11-19 17:49, Rein Halbersma wrote:
> > Please find attached an updated but not yet final version of an upcoming
> > proposal for user-defined literals for size_t (and ptrdiff_t).
>
> While I'm not against this in general...
>
> > for (auto i = 0z, s = v.size(); i < s; ++i) {
> >
> > /* use i and a[i] */
> >
> > }
>
> ...I don't think this is a good motivating example. I would always write
> this like 'i = decltype(v.size()){0}', because the point of 'auto' here
> is that I don't want to be bothered with having to know the return type
> of 'v.size()'. Using a literal suffix here defeats that purpose.
You can also write:
for (auto s = v.size(), i = s * 0; i < s; ++i)
And the problem is solved, as the type of the first variable applies to the
second one. Unless, of course, s were of lower rank than int.
> (What if I replace 'v' with a QVector? Then 'decltype(v.size())' is
> 'int', and all sorts of bad - the specific bad you're looking to avoid,
> in fact, but in the opposite direction - happens if I used '0z'.)
>
> And anyway this particular example is *MUCH* better written:
>
> for (auto i : bikeshed(v.size())
>
> (...for whatever 'bikeshed' ends up being called.)
Agreed.
--
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 19 Nov 2014 18:40:10 -0800 (PST)
Raw View
------=_Part_78_63560258.1416451210447
Content-Type: multipart/alternative;
boundary="----=_Part_79_957883647.1416451210447"
------=_Part_79_957883647.1416451210447
Content-Type: text/plain; charset=UTF-8
Why don't we also have "i8", "i32", "ui64" for std::int8_t, std::int32_t
and std::uint64 respectively, if we get literals for std::size_t and
std::ptrdiff_t? (Reserving uXXX and iXXX for any fixed types.)
"i16least", "ui8fast" I suppose could be others.
This would be doubly convenient considering that Visual Studio already
interprets i32 and ui64 as such suffixes, though directly.
On Wednesday, November 19, 2014 3:43:41 PM UTC-8, Thiago Macieira wrote:
>
> And the problem is solved, as the type of the first variable applies to
> the
> second one. Unless, of course, s were of lower rank than int.
>
>
Why in the world is it permissible for an implementation to have a size_t
smaller in rank than "unsigned"? Let's blow up everyone's code with
undefined behavior by making size arithmetic signed!
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_79_957883647.1416451210447
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why don't we also have "i8", "i32", "ui64" for std::int8_t=
, std::int32_t and std::uint64 respectively, if we get literals for std::si=
ze_t and std::ptrdiff_t? (Reserving uXXX and iXXX for any fixed types=
..) "i16least", "ui8fast" I suppose could be others.<br><br>This would=
be doubly convenient considering that Visual Studio already interprets i32=
and ui64 as such suffixes, though directly.<br><br>On Wednesday, November =
19, 2014 3:43:41 PM UTC-8, Thiago Macieira wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">And the problem is solved, as the type of the first vari=
able applies to the=20
<br>second one. Unless, of course, s were of lower rank than int.
<br>
<br></blockquote><div><br>Why in the world is it permissible for an impleme=
ntation to have a size_t smaller in rank than "unsigned"? Let's blow =
up everyone's code with undefined behavior by making size arithmetic signed=
!<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_79_957883647.1416451210447--
------=_Part_78_63560258.1416451210447--
.
Author: gmisocpp@gmail.com
Date: Wed, 19 Nov 2014 19:31:10 -0800 (PST)
Raw View
------=_Part_101_1965679480.1416454270695
Content-Type: multipart/alternative;
boundary="----=_Part_102_286594912.1416454270695"
------=_Part_102_286594912.1416454270695
Content-Type: text/plain; charset=UTF-8
On Thursday, November 20, 2014 12:43:41 PM UTC+13, Thiago Macieira wrote:
>
> On Wednesday 19 November 2014 18:18:51 Matthew Woehlke wrote:
> > On 2014-11-19 17:49, Rein Halbersma wrote:
> > > Please find attached an updated but not yet final version of an
> upcoming
> > > proposal for user-defined literals for size_t (and ptrdiff_t).
> >
> > While I'm not against this in general...
> >
> > > for (auto i = 0z, s = v.size(); i < s; ++i) {
> > >
> > > /* use i and a[i] */
> > >
> > > }
> >
> > ...I don't think this is a good motivating example. I would always write
> > this like 'i = decltype(v.size()){0}', because the point of 'auto' here
> > is that I don't want to be bothered with having to know the return type
> > of 'v.size()'. Using a literal suffix here defeats that purpose.
>
> You can also write:
>
> for (auto s = v.size(), i = s * 0; i < s; ++i)
>
> And the problem is solved, as the type of the first variable applies to
> the
> second one. Unless, of course, s were of lower rank than int.
>
Solved says who, If we have to write this, we should just stop using C++.
>
> > (What if I replace 'v' with a QVector? Then 'decltype(v.size())' is
> > 'int', and all sorts of bad - the specific bad you're looking to avoid,
> > in fact, but in the opposite direction - happens if I used '0z'.)
> >
> > And anyway this particular example is *MUCH* better written:
> >
> > for (auto i : bikeshed(v.size())
> >
> > (...for whatever 'bikeshed' ends up being called.)
>
> Agreed.
>
>
> --
> 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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_102_286594912.1416454270695
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, November 20, 2014 12:43:41 PM UTC+13,=
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
border-left-width: 1px; border-left-style: solid;">On Wednesday 19 Novembe=
r 2014 18:18:51 Matthew Woehlke wrote:
<br>> On 2014-11-19 17:49, Rein Halbersma wrote:
<br>> > Please find attached an updated but not yet final version of =
an upcoming
<br>> > proposal for user-defined literals for size_t (and ptrdiff_t)=
..
<br>>=20
<br>> While I'm not against this in general...
<br>>=20
<br>> > for (auto i =3D 0z, s =3D v.size(); i < s; ++i) {
<br>> >=20
<br>> > /* use i and a[i] */
<br>> >=20
<br>> > }
<br>>=20
<br>> ...I don't think this is a good motivating example. I would always=
write
<br>> this like 'i =3D decltype(v.size()){0}', because the point of 'aut=
o' here
<br>> is that I don't want to be bothered with having to know the return=
type
<br>> of 'v.size()'. Using a literal suffix here defeats that purpose.
<br>
<br>You can also write:
<br>
<br> for (auto s =3D v.size(=
), i =3D s * 0; i < s; ++i)
<br>
<br>And the problem is solved, as the type of the first variable applies to=
the=20
<br>second one. Unless, of course, s were of lower rank than int.
<br></blockquote><div><br></div><div>Solved says who, If we have =
to write this, we should just stop using C++. </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">
<br>> (What if I replace 'v' with a QVector? Then 'decltype(v.size())' i=
s
<br>> 'int', and all sorts of bad - the specific bad you're looking to a=
void,
<br>> in fact, but in the opposite direction - happens if I used '0z'.)
<br>>=20
<br>> And anyway this particular example is *MUCH* better written:
<br>>=20
<br>> for (auto i : bikeshed(v.size())
<br>>=20
<br>> (...for whatever 'bikeshed' ends up being called.)
<br>
<br>Agreed.
<br>
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_102_286594912.1416454270695--
------=_Part_101_1965679480.1416454270695--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 19 Nov 2014 20:48:43 -0800
Raw View
On Wednesday 19 November 2014 18:40:10 Myriachan wrote:
> > And the problem is solved, as the type of the first variable applies to
> > the
> > second one. Unless, of course, s were of lower rank than int.
>
> Why in the world is it permissible for an implementation to have a size_t
> smaller in rank than "unsigned"? Let's blow up everyone's code with
> undefined behavior by making size arithmetic signed!
That's not size_t that is smaller than unsigned. It's the return type of
size() that could be smaller than int.
--
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 20 Nov 2014 03:44:01 -0800 (PST)
Raw View
------=_Part_6399_1033918983.1416483841878
Content-Type: multipart/alternative;
boundary="----=_Part_6400_1786159404.1416483841878"
------=_Part_6400_1786159404.1416483841878
Content-Type: text/plain; charset=UTF-8
Just a couple of corrections to your draft:
1) In the first code fragment, you use namespace std::support_literals,
whereas you use namespace std::literals::support_literals further down, and
2) r/consisent/consistent/
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6400_1786159404.1416483841878
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><DIV>Just a couple of corrections to your draft:</DIV>
<DIV> </DIV>
<DIV>1) In the first code fragment, you use namespace std::support_literals, whereas you use namespace std::literals::support_literals further down, and</DIV>
<DIV>2) r/consisent/consistent/</DIV></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_6400_1786159404.1416483841878--
------=_Part_6399_1033918983.1416483841878--
.
Author: rhalbersma@gmail.com
Date: Thu, 20 Nov 2014 05:51:43 -0800 (PST)
Raw View
------=_Part_103_1006900569.1416491503260
Content-Type: multipart/alternative;
boundary="----=_Part_104_806724823.1416491503260"
------=_Part_104_806724823.1416491503260
Content-Type: text/plain; charset=UTF-8
On Thursday, November 20, 2014 12:44:01 PM UTC+1, Douglas Boffey wrote:
>
> Just a couple of corrections to your draft:
>
> 1) In the first code fragment, you use namespace std::support_literals,
> whereas you use namespace std::literals::support_literals further down, and
>
This works because both namespaces are inline. The quoted N3642 uses the
same mechanism, e.g. with std::literals::chrono_literals.
using namespace xstd::support_literals;
auto v = std::vector<int> { 98, 03, 11, 14, 17 };
for (auto i = 0z, s = v.size(); i < s; ++i)
std::cout << i << ": " << v[i] << '\n';
Live example at: http://coliru.stacked-crooked.com/a/1e0f576e96ab8983
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_104_806724823.1416491503260
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, November 20, 2014 12:44:01 PM UTC+1, Douglas =
Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Just a couple of corrections to your draft:</div>
<div> </div>
<div>1) In the first code fragment, you use namespace std::support_literals=
, whereas you use namespace std::literals::support_<wbr>literals further do=
wn, and</div></div></blockquote><div><br></div><div><span style=3D"font-fam=
ily: arial, sans-serif;">This works because both namespaces are inline. The=
quoted N3642 uses the same mechanism, e.g. with std::literals::chrono_</sp=
an><wbr style=3D"font-family: arial, sans-serif;"><span style=3D"font-famil=
y: arial, sans-serif;">literals. </span><br></div><div><br></div><div>=
<div><font face=3D"courier new, monospace" color=3D"#0000ff"> =
using namespace xstd::support_literals;</font></div><div><font face=3D"cour=
ier new, monospace" color=3D"#0000ff"><br></font></div><div><font face=3D"c=
ourier new, monospace" color=3D"#0000ff"> auto v =3D std::vect=
or<int> { 98, 03, 11, 14, 17 };</font></div><div><font face=3D"courie=
r new, monospace" color=3D"#0000ff"> for (auto i =3D 0z, s =3D=
v.size(); i < s; ++i) </font></div><div><font face=3D"courier new,=
monospace" color=3D"#0000ff"> std::cout <<=
; i << ": " << v[i] << '\n';</font></div></div><div><br><=
/div><div>Live example at: http://coliru.stacked-crooked.com/a/1e0f576e96ab=
8983 <br></div><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_104_806724823.1416491503260--
------=_Part_103_1006900569.1416491503260--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 20 Nov 2014 14:29:43 +0000
Raw View
Sorry about that. Thanks for correcting me :)
On 11/20/14, rhalbersma@gmail.com <rhalbersma@gmail.com> wrote:
> On Thursday, November 20, 2014 12:44:01 PM UTC+1, Douglas Boffey wrote:
>>
>> Just a couple of corrections to your draft:
>>
>> 1) In the first code fragment, you use namespace std::support_literals,
>> whereas you use namespace std::literals::support_literals further down,
>> and
>>
>
> This works because both namespaces are inline. The quoted N3642 uses the
> same mechanism, e.g. with std::literals::chrono_literals.
>
> using namespace xstd::support_literals;
>
> auto v = std::vector<int> { 98, 03, 11, 14, 17 };
> for (auto i = 0z, s = v.size(); i < s; ++i)
> std::cout << i << ": " << v[i] << '\n';
>
> Live example at: http://coliru.stacked-crooked.com/a/1e0f576e96ab8983
>
> --
>
> ---
> 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
> http://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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: rhalbersma@gmail.com
Date: Thu, 20 Nov 2014 14:57:41 -0800 (PST)
Raw View
------=_Part_6609_790928098.1416524261825
Content-Type: multipart/alternative;
boundary="----=_Part_6610_204768156.1416524261825"
------=_Part_6610_204768156.1416524261825
Content-Type: text/plain; charset=UTF-8
On Thursday, November 20, 2014 12:19:08 AM UTC+1, Matthew Woehlke wrote:
>
> On 2014-11-19 17:49, Rein Halbersma wrote:
> > Please find attached an updated but not yet final version of an upcoming
> > proposal for user-defined literals for size_t (and ptrdiff_t).
>
> While I'm not against this in general...
>
> > for (auto i = 0z, s = v.size(); i < s; ++i) {
> > /* use i and a[i] */
> > }
>
> ...I don't think this is a good motivating example. I would always write
> this like 'i = decltype(v.size()){0}', because the point of 'auto' here
> is that I don't want to be bothered with having to know the return type
> of 'v.size()'. Using a literal suffix here defeats that purpose.
>
I haven't got any statistics on this to back it up, but my guess is that
std::size_t is the return type of size() for the vast majority of code
using std::vector. Using 0z is just much more convenient to type, and it
exotic containers will be caught at compile-time.
> (What if I replace 'v' with a QVector? Then 'decltype(v.size())' is
> 'int', and all sorts of bad - the specific bad you're looking to avoid,
> in fact, but in the opposite direction - happens if I used '0z'.)
>
In non-generic code, knowing that I loop over a QVector, I can simply drop
the z suffix and use for (auto i = 0, s = qv.size(); ++i) { /* ... */ }
> And anyway this particular example is *MUCH* better written:
>
> for (auto i : bikeshed(v.size())
>
> (...for whatever 'bikeshed' ends up being called.)
>
> :-)
>
Agreed in principle, but here bikeshed is enforcing 0 as the starting
index. What if you want to loop from 1 to v.size()? Then you have the same
deduction problem, unless you can use for (auto i : bike_shed(1z,
v.size()).
> I could come up with better motivating examples, however. For instance:
>
> static constexpr auto NUM_COEFFICIENTS = 4z;
> std::array<double, NUM_COEFFICIENTS> cubic_polynomial;
>
Again agreed in principle that 4z has benefits for initalization. However,
for non-type template parameters, the program is ill-formed if the
arguments cannot be narrowed to the parameter's type size_t, e.g. if
NUM_COEFFICIENTS would be set to -1.
> --
> Matthew
>
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6610_204768156.1416524261825
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, November 20, 2014 12:19:08 AM UTC+1, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-11-19 17=
:49, Rein Halbersma wrote:
<br>> Please find attached an updated but not yet final version of an up=
coming
<br>> proposal for user-defined literals for size_t (and ptrdiff_t).
<br>
<br>While I'm not against this in general...
<br>
<br>> for (auto i =3D 0z, s =3D v.size(); i < s; ++i) {
<br>> /* use i and a[i] */
<br>> }
<br>
<br>...I don't think this is a good motivating example. I would always writ=
e
<br>this like 'i =3D decltype(v.size()){0}', because the point of 'auto' he=
re
<br>is that I don't want to be bothered with having to know the return type
<br>of 'v.size()'. Using a literal suffix here defeats that purpose.
<br></blockquote><div><br></div><div>I haven't got any statistics on this t=
o back it up, but my guess is that std::size_t is the return type of size()=
for the vast majority of code using std::vector. Using 0z is just much mor=
e convenient to type, and it exotic containers will be caught at compile-ti=
me. </div><div> </div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">(What if I replace 'v' with a QVector? Then 'decltype(v.size())' is
<br>'int', and all sorts of bad - the specific bad you're looking to avoid,
<br>in fact, but in the opposite direction - happens if I used '0z'.)
<br></blockquote><div><br></div><div>In non-generic code, knowing that I lo=
op over a QVector, I can simply drop the z suffix and use for (auto i =3D 0=
, s =3D qv.size(); ++i) { /* ... */ }</div><div> </div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">And anyway this particular example is *MUCH* =
better written:
<br>
<br> for (auto i : bikeshed(v.size())
<br>
<br>(...for whatever 'bikeshed' ends up being called.)
<br>
<br>:-)
<br></blockquote><div><br></div><div>Agreed in principle, but here bikeshed=
is enforcing 0 as the starting index. What if you want to loop from 1 to v=
..size()? Then you have the same deduction problem, unless you can use for (=
auto i : bike_shed(1z, v.size()). </div><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">I could come up with better motivating exa=
mples, however. For instance:
<br>
<br> static constexpr auto NUM_COEFFICIENTS =3D 4z;
<br> std::array<double, NUM_COEFFICIENTS> cubic_polynomial;
<br></blockquote><div><br></div><div>Again agreed in principle that 4z has =
benefits for initalization. However, for non-type template parameters, the =
program is ill-formed if the arguments cannot be narrowed to the parameter'=
s type size_t, e.g. if NUM_COEFFICIENTS would be set to -1. </div><div=
> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Matthew
<br>
<br></blockquote></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6610_204768156.1416524261825--
------=_Part_6609_790928098.1416524261825--
.