Author: Matthew Fioravante <fmatthew5876@gmail.com>

Date: Thu, 6 Oct 2016 18:25:40 -0700 (PDT)

------=_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'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">>></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'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's complement. I'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's complement platforms = that implement C++.</div><div><br></div><div>In other words, the rule shoul= d be:</div><div><br></div><div>"If your platform represents signed int= egers 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"</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" 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-- .