------=_Part_417_1268873489.1475803540119
Content-Type: multipart/alternative;
 boundary="----=_Part_418_1353320959.1475803540119"

------=_Part_418_1353320959.1475803540119
Content-Type: text/plain; charset=UTF-8

So there is this long standing question of integer representations. C++
tries to support as many theoretical hardware platforms as possible but
sometimes hardware converges to one solution which is adopted for all
practical purposes universally.

This seems to be the case with the fact that as far as I know every modern
architecture represents signed integers using 2's complement and has been
doing so for decades.
The practical consequence is the fact that the result of right shifting a
signed integer is implementation defined.

int x = -937;
x >> 6; //Implementation defined result

Technically this means you cannot portably right shift a signed integer in
C++ and to add insult to injury the standard library doesn't provide any
alternative inline function to do a portable right arithmetic shift. Some
people have been saying we should drop support for other integer
representations and base the C++ standard on 2's complement. I'd be onboard
with that but there is also a compromise that effectively gives everyone
what they want.

Instead of removing theoretical support for other integer representations
for the standard, I think as first step we should just define such
operations on all 2's complement platforms that implement C++.

In other words, the rule should be:

"If your platform represents signed integers using 2's complement, then
operator>>(signed integral, int) is defined to perform a right arithmetic
shift. If your platform does not use 2's complement, the result of
operator>>(signed integral, int) is implementation defined"

This compromise still allows theoretical support for other integer
representations while giving all of us living in the real world the
portable behavior that all compilers already implement anyway. It does not
preclude later removing support for other integer representations from the
standard.


Are there other operations besides signed right shift that suffer in a
similar way?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b5f66021-efc4-475a-a9ef-4fd20b7ddde0%40isocpp.org.

------=_Part_418_1353320959.1475803540119
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So there is this long standing question of integer represe=
ntations. C++ tries to support as many theoretical hardware platforms as po=
ssible but sometimes hardware converges to one solution which is adopted fo=
r all practical purposes universally.<div><br></div><div>This seems to be t=
he case with the fact that as far as I know every modern architecture repre=
sents signed integers using 2&#39;s complement and has been doing so for de=
cades.=C2=A0</div><div>The practical consequence is the fact that the resul=
t of right shifting a signed integer is implementation defined.</div><div><=
br></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><font colo=
r=3D"#006666"><span style=3D"color: #660;" class=3D"styled-by-prettify">-</=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">937</span></=
font><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>x </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span><font colo=
r=3D"#006666"><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">6</span><spa=
n 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=
: #800;" class=3D"styled-by-prettify">//Implementation defined result</span=
></font><font color=3D"#006666"></font></div></code></div><br></div><div>Te=
chnically this means you cannot portably right shift a signed integer in C+=
+ and to add insult to injury the standard library doesn&#39;t provide any =
alternative inline function to do a portable right arithmetic shift. Some p=
eople have been saying we should drop support for other integer representat=
ions and base the C++ standard on 2&#39;s complement. I&#39;d be onboard wi=
th that but there is also a compromise that effectively gives everyone what=
 they want.</div><div><br></div><div>Instead of removing theoretical suppor=
t for other integer representations for the standard, I think as first step=
 we should just define such operations on all 2&#39;s complement platforms =
that implement C++.</div><div><br></div><div>In other words, the rule shoul=
d be:</div><div><br></div><div>&quot;If your platform represents signed int=
egers using 2&#39;s complement, then operator&gt;&gt;(signed integral, int)=
 is defined to perform a right arithmetic shift. If your platform does not =
use 2&#39;s complement, the result of operator&gt;&gt;(signed integral, int=
) is implementation defined&quot;</div><div><br></div><div>This compromise =
still allows theoretical support for other integer representations while gi=
ving all of us living in the real world the portable behavior that all comp=
ilers already implement anyway. It does not preclude later removing support=
 for other integer representations from the standard.</div><div><br></div><=
div><br></div><div>Are there other operations besides signed right shift th=
at suffer in a similar way?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5f66021-efc4-475a-a9ef-4fd20b7ddde0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5f66021-efc4-475a-a9ef-4fd20b7ddde0=
%40isocpp.org</a>.<br />

------=_Part_418_1353320959.1475803540119--

------=_Part_417_1268873489.1475803540119--

.