Topic: n3990: Operator >>> is a bad choice
Author: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Date: Thu, 29 May 2014 16:31:58 -0700 (PDT)
Raw View
------=_Part_19_2038745.1401406318058
Content-Type: text/plain; charset=UTF-8
n3990 proposes adding operators <<< and >>> (and <<<= and >>>=) for
circular shifts. It correctly notes that Java and JavaScript already have
an operator >>>. It fails to note, however, the critical fact that in Java
and JavaScript this operator is for unsigned (non-circular) right shift.
It would be an extremely bad idea to give this operator different semantics
in C++.
--
---
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_19_2038745.1401406318058
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">n3990 proposes adding operators <<< and >>&=
gt; (and <<<=3D and >>>=3D) for circular shifts. It=
correctly notes that Java and JavaScript already have an operator >>=
>. It fails to note, however, the critical fact that in Java and J=
avaScript this operator is for unsigned (non-circular) right shift. I=
t would be an extremely bad idea to give this operator different semantics =
in C++.<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_19_2038745.1401406318058--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 30 May 2014 08:35:51 +0800
Raw View
--Apple-Mail=_73A3FC17-2975-4128-8E9C-09C53AF2A0F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Circular shifts are seldom used and are very specialized. I think they shou=
ld be named functions.
Perhaps they should be added to the Library Fundamentals TS.
I seem to recall other common intrinsics like leading zeroes and population=
count begin added to that TS but I don't see any in there. Am I imagining =
something?
On 2014-05-30, at 7:31 AM, Jeremy Maitin-Shepard <jeremy@jeremyms.com> wrot=
e:
> n3990 proposes adding operators <<< and >>> (and <<<=3D and >>>=3D) for c=
ircular shifts. It correctly notes that Java and JavaScript already have a=
n operator >>>. It fails to note, however, the critical fact that in Java =
and JavaScript this operator is for unsigned (non-circular) right shift. I=
t would be an extremely bad idea to give this operator different semantics =
in C++.
>=20
> --=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=
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-propo=
sals/.
--=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=_73A3FC17-2975-4128-8E9C-09C53AF2A0F0
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;">Circular shifts are se=
ldom used and are very specialized. I think they should be named functions.=
<div><br></div><div>Perhaps they should be added to the Library Fundamental=
s TS.<div><br></div><div>I seem to recall other common intrinsics like lead=
ing zeroes and population count begin added to that TS but I don’t se=
e any in there. Am I imagining something?</div><div><br></div><div><br><div=
><div>On 2014–05–30, at 7:31 AM, Jeremy Maitin-Shepard <<a h=
ref=3D"mailto:jeremy@jeremyms.com">jeremy@jeremyms.com</a>> wrote:</div>=
<br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=
=3D"ltr">n3990 proposes adding operators <<< and >>> (and=
<<<=3D and >>>=3D) for circular shifts. It correct=
ly notes that Java and JavaScript already have an operator >>>.&nb=
sp; It fails to note, however, the critical fact that in Java and JavaScrip=
t this operator is for unsigned (non-circular) right shift. It would =
be an extremely bad idea to give this operator different semantics in C++.<=
br></div><div><br class=3D"webkit-block-placeholder"></div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</blockquote></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=_73A3FC17-2975-4128-8E9C-09C53AF2A0F0--
.
Author: morwenn29@gmail.com
Date: Fri, 30 May 2014 03:29:03 -0700 (PDT)
Raw View
------=_Part_267_16901727.1401445743917
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The proposal you are reffering to is N3847=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3864.html>, and=
=20
for some reason, it did not make its way to the library fundamental TS.=20
From what I recall, it was commonly viewed as a much-needed feature on this=
=20
very forum. I don't know what was the consensus after the Issaqah meeting.
Le vendredi 30 mai 2014 02:36:05 UTC+2, David Krauss a =C3=A9crit :
>
> Circular shifts are seldom used and are very specialized. I think they=20
> should be named functions.
>
> Perhaps they should be added to the Library Fundamentals TS.
>
> I seem to recall other common intrinsics like leading zeroes and=20
> population count begin added to that TS but I don=E2=80=99t see any in th=
ere. Am I=20
> imagining something?
>
>
> On 2014=E2=80=9305=E2=80=9330, at 7:31 AM, Jeremy Maitin-Shepard <jer...@=
jeremyms.com=20
> <javascript:>> wrote:
>
> n3990 proposes adding operators <<< and >>> (and <<<=3D and >>>=3D) for=
=20
> circular shifts. It correctly notes that Java and JavaScript already hav=
e=20
> an operator >>>. It fails to note, however, the critical fact that in Ja=
va=20
> and JavaScript this operator is for unsigned (non-circular) right shift. =
=20
> It would be an extremely bad idea to give this operator different semanti=
cs=20
> in C++.
>
> --=20
>
> ---=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_267_16901727.1401445743917
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The proposal you are reffering to is <a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3864.html">N3847</a>, and fo=
r some reason, it did not make its way to the library fundamental TS. From =
what I recall, it was commonly viewed as a much-needed feature on this very=
forum. I don't know what was the consensus after the Issaqah meeting.<br><=
br>Le vendredi 30 mai 2014 02:36:05 UTC+2, David Krauss a =C3=A9crit :=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-=
word">Circular shifts are seldom used and are very specialized. I think the=
y should be named functions.<div><br></div><div>Perhaps they should be adde=
d to the Library Fundamentals TS.<div><br></div><div>I seem to recall other=
common intrinsics like leading zeroes and population count begin added to =
that TS but I don=E2=80=99t see any in there. Am I imagining something?</di=
v><div><br></div><div><br><div><div>On 2014=E2=80=9305=E2=80=9330, at 7:31 =
AM, Jeremy Maitin-Shepard <<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"RrLQJddm0qIJ" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">jer...@j=
eremyms.com</a>> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"l=
tr">n3990 proposes adding operators <<< and >>> (and <=
<<=3D and >>>=3D) for circular shifts. It correctly no=
tes that Java and JavaScript already have an operator >>>. I=
t fails to note, however, the critical fact that in Java and JavaScript thi=
s operator is for unsigned (non-circular) right shift. It would be an=
extremely bad idea to give this operator different semantics in C++.<br></=
div><div><br></div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
RrLQJddm0qIJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"RrLQJddm0qIJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</blockquote></div><br></div></div></div></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_267_16901727.1401445743917--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 30 May 2014 13:53:42 +0300
Raw View
On 30 May 2014 13:29, <morwenn29@gmail.com> wrote:
> The proposal you are reffering to is N3847, and for some reason, it did not
> make its way to the library fundamental TS. From what I recall, it was
> commonly viewed as a much-needed feature on this very forum. I don't know
> what was the consensus after the Issaqah meeting.
I think you tried to write N3864 there. The numerics study group said
the following:
----snip----
We don't see the value of the shift functions over the operators. The
rotate, count, popcount and parity functions seem straightforward. We
don't see the motivation for the rightmost bit manipulation functions.
Missing motivation for range of bits manipulation Bitwise/bytewise
permutations OK. Pwr of 2 minipulation: missing log. Saturated
incomplete. Alignment...doesn't handle the lack of implicit conversion
to/from void*...also problem on machines that aren't byte-addressible.
We think that this should probably be handled by WG14 first, possibly
as type-generic macros; and WG21 could then adopt them as constexpr
functions. Bill Seymour will submit a paper to WG14.
----snap----
--
---
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: David Krauss <potswa@gmail.com>
Date: Fri, 30 May 2014 21:58:37 +0800
Raw View
--Apple-Mail=_5373A91A-0942-4939-924D-5AE5124334D0
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-30, at 6:53 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> The numerics study group said
> the following:
>
> ----snip----
> We don't see the value of the shift functions over the operators.
I'm not taking the time to review the proposal, but if there was an algebraic right shift, that *isn't* covered by the operator. Other shift functions presumably have added value in implicitly casting the LHS to e.g. unsigned type.
> The
> rotate, count, popcount and parity functions seem straightforward. We
> don't see the motivation for the rightmost bit manipulation functions.
> Missing motivation for range of bits manipulation Bitwise/bytewise
The comments seem to be missing the point that these functions are commonplace on most CPUs, yet unportable. As long as we don't have standard library facilities, compiler-specific intrinsics remain the best option.
Unportable code remains the status quo for a while more.
> permutations OK. Pwr of 2 minipulation: missing log. Saturated
> incomplete. Alignment...doesn't handle the lack of implicit conversion
> to/from void*...also problem on machines that aren't byte-addressible.
Intrinsics which may not be universally implementable should be optional. The point is to allow code to be ported and reduce language fragmentation. If that portability still isn't absolute, so be it.
> We think that this should probably be handled by WG14 first, possibly
> as type-generic macros; and WG21 could then adopt them as constexpr
> functions. Bill Seymour will submit a paper to WG14.
Is this a prejudicial judgment against WG21 initiative? Will we still have to wait for years?
--
---
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/.
--Apple-Mail=_5373A91A-0942-4939-924D-5AE5124334D0
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;05–30, at 6:53 PM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">The numeric=
s study group said<br>the following:<br><br>----snip----<br>We don't see th=
e value of the shift functions over the operators. </blockquote><div><br></=
div><div>I’m not taking the time to review the proposal, but if there=
was an algebraic right shift, that *<i>isn’t</i>* covered by the ope=
rator. Other shift functions presumably have added value in implicitly cast=
ing the LHS to e.g. unsigned type.</div><div><br></div><blockquote type=3D"=
cite">The<br>rotate, count, popcount and parity functions seem straightforw=
ard. We<br>don't see the motivation for the rightmost bit manipulation func=
tions.<br>Missing motivation for range of bits manipulation Bitwise/bytewis=
e<br></blockquote><div><br></div><div>The comments seem to be missing the p=
oint that these functions are commonplace on most CPUs, yet unportable. As =
long as we don’t have standard library facilities, compiler-specific =
intrinsics remain the best option.</div><div><br></div><div>Unportable code=
remains the status quo for a while more.</div><br><blockquote type=3D"cite=
">permutations OK. Pwr of 2 minipulation: missing log. Saturated<br>incompl=
ete. Alignment...doesn't handle the lack of implicit conversion<br>to/from =
void*...also problem on machines that aren't byte-addressible.<br></blockqu=
ote><div><br></div><div>Intrinsics which may not be universally implementab=
le should be optional. The point is to allow code to be ported and reduce l=
anguage fragmentation. If that portability still isn’t absolute, so b=
e it.</div><br><blockquote type=3D"cite">We think that this should probably=
be handled by WG14 first, possibly<br>as type-generic macros; and WG21 cou=
ld then adopt them as constexpr<br>functions. Bill Seymour will submit a pa=
per to WG14.<br></blockquote><br></div><div>Is this a prejudicial judgment =
against WG21 initiative? Will we still have to wait for years?</div><br></b=
ody></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=_5373A91A-0942-4939-924D-5AE5124334D0--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 30 May 2014 17:29:14 +0300
Raw View
On 30 May 2014 16:58, David Krauss <potswa@gmail.com> wrote:
>> We think that this should probably be handled by WG14 first, possibly
>> as type-generic macros; and WG21 could then adopt them as constexpr
>> functions. Bill Seymour will submit a paper to WG14.
> Is this a prejudicial judgment against WG21 initiative? Will we still have
> to wait for years?
I don't know. I wasn't present in the meeting. If you want to know
what the Numerics
SG means with those comments, ask them.
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 30 May 2014 13:05:22 -0700
Raw View
--20cf30334435c1c23b04faa390bd
Content-Type: text/plain; charset=UTF-8
On Thu, May 29, 2014 at 4:31 PM, Jeremy Maitin-Shepard <jeremy@jeremyms.com>
wrote:
> n3990 proposes adding operators <<< and >>> (and <<<= and >>>=) for
> circular shifts. It correctly notes that Java and JavaScript already have
> an operator >>>. It fails to note, however, the critical fact that in Java
> and JavaScript this operator is for unsigned (non-circular) right shift.
> It would be an extremely bad idea to give this operator different semantics
> in C++.
>
It also seems to be incompatible with CUDA, which uses <<< and >>> as
delimiters for kernel function call parameters.
(And I agree with other commenters that this would be better as a named
function than as an operator.)
--
---
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/.
--20cf30334435c1c23b04faa390bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, May 29, 2014 at 4:31 PM, Jeremy Maitin-Shepard <span dir=3D"ltr"><<a=
href=3D"mailto:jeremy@jeremyms.com" target=3D"_blank">jeremy@jeremyms.com<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">n3990 proposes adding opera=
tors <<< and >>> (and <<<=3D and >>>=3D=
) for circular shifts.=C2=A0 It correctly notes that Java and JavaScript al=
ready have an operator >>>.=C2=A0 It fails to note, however, the c=
ritical fact that in Java and JavaScript this operator is for unsigned (non=
-circular) right shift.=C2=A0 It would be an extremely bad idea to give thi=
s operator different semantics in C++.</div>
</blockquote><div><br></div><div>It also seems to be incompatible with CUDA=
, which uses <<< and >>> as delimiters for kernel functio=
n call parameters.</div><div><br></div><div>(And I agree with other comment=
ers that this would be better as a named function than as an operator.)</di=
v>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf30334435c1c23b04faa390bd--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 30 May 2014 22:20:56 +0200
Raw View
--089e01182e487476d904faa3c85c
Content-Type: text/plain; charset=UTF-8
On Fri, May 30, 2014 at 10:05 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> (And I agree with other commenters that this would be better as a named
> function than as an operator.)
>
> Strongly agree. ROT is not even close to being commonly used enough to
deserve its own core operator.
--
---
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/.
--089e01182e487476d904faa3c85c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 30, 2014 at 10:05 PM, Richard Smith <span dir=3D"ltr"><<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"">(And I agree with other commente=
rs that this would be better as a named function than as an operator.)<br>
</div>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p></div></div></blockquote></div>Strongly agree. =C2=A0ROT is not even=
close to being commonly used enough to deserve its own core operator.</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 />
--089e01182e487476d904faa3c85c--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sat, 14 Jun 2014 21:58:35 -0700 (PDT)
Raw View
------=_Part_711_21647854.1402808315588
Content-Type: text/plain; charset=UTF-8
I agree, this should be a function. It will almost never be used outside of
a few specialized cases. An additional operator comes with a lot of baggage
for such a rarely used opeation. However we must expose this instruction
with something.
We also need a function for right arithmetic shift, because you cannot get
at this operation portably with operator>>().
On Friday, May 30, 2014 4:20:58 PM UTC-4, Andrew Tomazos wrote:
>
> On Fri, May 30, 2014 at 10:05 PM, Richard Smith <ric...@metafoo.co.uk
> <javascript:>> wrote:
>
>> (And I agree with other commenters that this would be better as a named
>> function than as an operator.)
>>
>> Strongly agree. ROT is not even close to being commonly used enough to
> deserve its own core operator.
>
--
---
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_711_21647854.1402808315588
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree, this should be a function. It will almost never b=
e used outside of a few specialized cases. An additional operator comes wit=
h a lot of baggage for such a rarely used opeation. However we must expose =
this instruction with something.<div><br></div><div>We also need a function=
for right arithmetic shift, because you cannot get at this operation porta=
bly with operator>>().<br><br>On Friday, May 30, 2014 4:20:58 PM UTC-=
4, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, May 30, 2014 at 10:05 PM=
, Richard Smith <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"N8ZqORdNGNYJ" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">=
ric...@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><div>(And I agree with other commenters that this would be better as a=
named function than as an operator.)<br>
</div>
</div></div></div><div><div>
<p></p></div></div></blockquote></div>Strongly agree. ROT is not even=
close to being commonly used enough to deserve its own core operator.</div=
></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_711_21647854.1402808315588--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 15 Jun 2014 08:00:21 -0700
Raw View
Em s=E1b 14 jun 2014, =E0s 21:58:35, Matthew Fioravante escreveu:
> I agree, this should be a function. It will almost never be used outside =
of
> a few specialized cases. An additional operator comes with a lot of bagga=
ge
> for such a rarely used opeation. However we must expose this instruction
> with something.
>=20
> We also need a function for right arithmetic shift, because you cannot ge=
t
> at this operation portably with operator>>().
There's a reason why the standard leaves that implementation-defined: some=
=20
machines may not provide the necessary instructions to do a right arithmeti=
c=20
shift.
If the machine does not provide the instruction for that or the rotate=20
operation, should the Standard Library have a function for it? Shouldn't=20
people be aware that the operation might be very expensive? I think the ans=
wer=20
is that we should, but only as regular functions and as part of a library o=
f=20
bit operations. (see the discussion on bit scanning and population count)
Anyway, on x86, this problem is solved with intrinsics: _lrotl and _lrotr.
--=20
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
--=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/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 15 Jun 2014 17:22:55 +0200
Raw View
On Sun, Jun 15, 2014 at 5:00 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> Em s=C3=A1b 14 jun 2014, =C3=A0s 21:58:35, Matthew Fioravante escreveu:
>> I agree, this should be a function. It will almost never be used outside=
of
>> a few specialized cases. An additional operator comes with a lot of bagg=
age
>> for such a rarely used opeation. However we must expose this instruction
>> with something.
>>
>> We also need a function for right arithmetic shift, because you cannot g=
et
>> at this operation portably with operator>>().
>
> There's a reason why the standard leaves that implementation-defined: som=
e
> machines may not provide the necessary instructions to do a right arithme=
tic
> shift.
>
> If the machine does not provide the instruction for that or the rotate
> operation, should the Standard Library have a function for it? Shouldn't
> people be aware that the operation might be very expensive? I think the a=
nswer
> is that we should, but only as regular functions and as part of a library=
of
> bit operations. (see the discussion on bit scanning and population count)
>
> Anyway, on x86, this problem is solved with intrinsics: _lrotl and _lrotr=
..
We we wrote the paper, we did consider a library version. Arguments
were not that strong towards an operator, so I can also agree with
a library version, though we thought the operator version for completeness
and thought as an extension of the already existing operators
(specially when writing a new class that behaves as an integral,
such as the arbitrary length integer mpz library).
Anyway, I don't want to loose focus of the important item here. A library
version is OK, and we do need the functionality.
As an anecdote, when we wrote the paper we didn't consider the nvidia
>>> operator.
Many compilers provide built ins. We do not want that.
We want portability, and we want that -if the instructionset supports it-
it indeeds run fast. I disregard awareness of the programmer: in any case
he/she needs it, and I don't think that will write the algorithm differentl=
y
without using the rotation just in case the architecture doesn't support it=
..
On the contrary, will indeed use it in the case the arch does support it.
> --
> 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-propo=
sals/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 15 Jun 2014 08:35:55 -0700
Raw View
Em dom 15 jun 2014, =E0s 17:22:55, dgutson . escreveu:
> Many compilers provide built ins. We do not want that.
> We want portability, and we want that -if the instructionset supports it-
> it indeeds run fast. I disregard awareness of the programmer: in any case
> he/she needs it, and I don't think that will write the algorithm differen=
tly
> without using the rotation just in case the architecture doesn't support
> it. On the contrary, will indeed use it in the case the arch does support
> it.
Depending on the algorithm, there might be a different solution that can be=
=20
implemented without rotation which is slower than the operation with rotati=
on=20
instructions, but still faster than the implementation that emulates rotati=
on.
That said, I think it's really up to the developer to decide that when they=
=20
write the algorithm. The important thing is to provide the function so they=
=20
can choose to use it.
--=20
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
--=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/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sun, 15 Jun 2014 08:45:21 -0700 (PDT)
Raw View
------=_Part_177_18980089.1402847121204
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, June 15, 2014 11:00:32 AM UTC-4, Thiago Macieira wrote:
>
> Em s=C3=A1b 14 jun 2014, =C3=A0s 21:58:35, Matthew Fioravante escreveu:=
=20
> > I agree, this should be a function. It will almost never be used outsid=
e=20
> of=20
> > a few specialized cases. An additional operator comes with a lot of=20
> baggage=20
> > for such a rarely used opeation. However we must expose this instructio=
n=20
> > with something.=20
> >=20
> > We also need a function for right arithmetic shift, because you cannot=
=20
> get=20
> > at this operation portably with operator>>().=20
>
> There's a reason why the standard leaves that implementation-defined: som=
e=20
> machines may not provide the necessary instructions to do a right=20
> arithmetic=20
> shift.=20
>
That's fine, rshr() can be emulated in software for those machines. It may=
=20
run slower, but all of your algorithms depending on it will still be=20
correct and can be optimized for the platform later if need be.
> If the machine does not provide the instruction for that or the rotate=20
> operation, should the Standard Library have a function for it?=20
I would say yes, because almost every machine, modern and ancient provides=
=20
these. There may be some rarer architectures where the operation has to be=
=20
emulated, but I would argue that anyone using one of these esoteric=20
platforms would likely already know the performance implications. It would=
=20
also be documented by their implementation. At worst case, they can=20
optimize (#ifdefs/instrinsics again) their algorithms manually on that=20
platform, while the basic version using rotr(), rotl(), and/or rshr() works=
=20
optimally for 99% of systems out of the box. Its much better than what we=
=20
have now, #ifdefs/intrinsics for every platform.
=20
> Shouldn't=20
> people be aware that the operation might be very expensive? I think the=
=20
> answer=20
> is that we should, but only as regular functions and as part of a library=
=20
> of=20
> bit operations. (see the discussion on bit scanning and population count)=
=20
>
Yes, the platform specific performance implications should be documented.=
=20
Bit algorithms with different performance characteristics on different=20
platform still may require platform specific implementations of algorithms=
=20
using these. Having this interface doesn't completely solve the #ifdef=20
problem but it does reduce it dramatically.
=20
Your point about the differing performance and the fact that these may not=
=20
be primitives on the machine seems to be another point in favor of=20
functions over operators.
>
> Anyway, on x86, this problem is solved with intrinsics: _lrotl and _lrotr=
..=20
>
Similarly for many other platforms, making the implementation cost of=20
standardization almost 0.
=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=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_177_18980089.1402847121204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, June 15, 2014 11:00:32 AM UTC-4, Thiago=
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em s=C3=A1b 14=
jun 2014, =C3=A0s 21:58:35, Matthew Fioravante escreveu:
<br>> I agree, this should be a function. It will almost never be used o=
utside of
<br>> a few specialized cases. An additional operator comes with a lot o=
f baggage
<br>> for such a rarely used opeation. However we must expose this instr=
uction
<br>> with something.
<br>>=20
<br>> We also need a function for right arithmetic shift, because you ca=
nnot get
<br>> at this operation portably with operator>>().
<br>
<br>There's a reason why the standard leaves that implementation-defined: s=
ome=20
<br>machines may not provide the necessary instructions to do a right arith=
metic=20
<br>shift.
<br></blockquote><div><br></div><div>That's fine, rshr() can be emulated in=
software for those machines. It may run slower, but all of your algorithms=
depending on it will still be correct and can be optimized for the platfor=
m later if need be.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
<br>If the machine does not provide the instruction for that or the rotate=
=20
<br>operation, should the Standard Library have a function for it? </blockq=
uote><div><br></div><div>I would say yes, because almost every machine, mod=
ern and ancient provides these. There may be some rarer architectures where=
the operation has to be emulated, but I would argue that anyone using one =
of these esoteric platforms would likely already know the performance impli=
cations. It would also be documented by their implementation. At worst case=
, they can optimize (#ifdefs/instrinsics again) their algorithms manually o=
n that platform, while the basic version using rotr(), rotl(), and/or rshr(=
) works optimally for 99% of systems out of the box. Its much better than w=
hat we have now, #ifdefs/intrinsics for every platform.</div><div> </d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">Shouldn't=20
<br>people be aware that the operation might be very expensive? I think the=
answer=20
<br>is that we should, but only as regular functions and as part of a libra=
ry of=20
<br>bit operations. (see the discussion on bit scanning and population coun=
t)
<br></blockquote><div><br></div><div>Yes, the platform specific performance=
implications should be documented. Bit algorithms with different performan=
ce characteristics on different platform still may require platform specifi=
c implementations of algorithms using these. Having this interface doesn't =
completely solve the #ifdef problem but it does reduce it dramatically.</di=
v><div> </div><div>Your point about the differing performance and the =
fact that these may not be primitives on the machine seems to be another po=
int in favor of functions over operators.</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<br>Anyway, on x86, this problem is solved with intrinsics: _lrotl and _lro=
tr.
<br></blockquote><div><br></div><div>Similarly for many other platforms, ma=
king the implementation cost of standardization almost 0.</div><div> <=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">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_177_18980089.1402847121204--
.