------=_Part_854_1511178572.1476161452867
Content-Type: multipart/alternative;
 boundary="----=_Part_855_1581966514.1476161452867"

------=_Part_855_1581966514.1476161452867
Content-Type: text/plain; charset=UTF-8

As suggested in the other thread about 2's complement, and also lifted from
my previous proposal N3864. I've written a small proposal to add explicit
shift operations to the standard library.

Should be pretty self explanatory.

https://github.com/fmatthew5876/stdcxx-bitops/blob/master/proposal/shift.md

Please let me know if you have any objections or feedback.

Thanks!

--
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/95e94b53-d65a-4a81-8209-9ec5322d09d7%40isocpp.org.

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

<div dir=3D"ltr">As suggested in the other thread about 2&#39;s complement,=
 and also lifted from my previous proposal N3864. I&#39;ve written a small =
proposal to add explicit shift operations to the standard library.<div><br>=
</div><div>Should be pretty self explanatory.</div><div><br></div><div>http=
s://github.com/fmatthew5876/stdcxx-bitops/blob/master/proposal/shift.md<br>=
</div><div><br></div><div>Please let me know if you have any objections or =
feedback.</div><div><br></div><div>Thanks!</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/95e94b53-d65a-4a81-8209-9ec5322d09d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95e94b53-d65a-4a81-8209-9ec5322d09d7=
%40isocpp.org</a>.<br />

------=_Part_855_1581966514.1476161452867--

------=_Part_854_1511178572.1476161452867--

.

--001a1135043acc42b8053e99f5c7
Content-Type: text/plain; charset=UTF-8

Hi Matthew,

I am interested in a similar feature specifically related to arithmetic
scaling (although I'm not completely certain of its necessity yet).
However, it has a number of extra requirements. Notably, I'd like for users
to be able to specialize scaling for their own, user-defined types. I'd
also like to consider powers other than two.

The upshot of these two requirements would be classes in the style of
std::hash with an additional parameter specifying the base. For example:

// standard
template<Integral T, int Base>
struct shar;

// user-defined
template<>
struct shar<MyIntegralType, 2> {
  constexpr MyIntegralType operator()(const MyIntegralType& x, int s);
}

How palatable does all this sound? I'm in two minds whether this should be
something to consider in your proposal or merely something that would
depend upon it for standard specializations involving built-in types.

Cheers,
John

On Mon, Oct 10, 2016 at 9:50 PM, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

> As suggested in the other thread about 2's complement, and also lifted
> from my previous proposal N3864. I've written a small proposal to add
> explicit shift operations to the standard library.
>
> Should be pretty self explanatory.
>
> https://github.com/fmatthew5876/stdcxx-bitops/
> blob/master/proposal/shift.md
>
> Please let me know if you have any objections or feedback.
>
> Thanks!
>
> --
> 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/95e94b53-d65a-4a81-
> 8209-9ec5322d09d7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95e94b53-d65a-4a81-8209-9ec5322d09d7%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--001a1135043acc42b8053e99f5c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div>Hi Matthew,<br><br></div>I a=
m interested in a similar feature specifically related to arithmetic scalin=
g (although I&#39;m not completely certain of its necessity yet). However, =
it has a number of extra requirements. Notably, I&#39;d like for users to b=
e able to specialize scaling for their own, user-defined types. I&#39;d als=
o like to consider powers other than two. <br><br>The upshot of these two r=
equirements would be classes in the style of std::hash with an additional p=
arameter specifying the base. For example:<br><br></div><div>// standard<br=
></div><div>template&lt;Integral T, int Base&gt;<br></div><div>struct shar;=
<br><br></div><div>// user-defined<br></div><div>template&lt;&gt;<br></div>=
<div>struct shar&lt;MyIntegralType, 2&gt; {<br>=C2=A0 constexpr MyIntegralT=
ype operator()(const MyIntegralType&amp; x, int s);<br>}<br><br></div><div>=
How palatable does all this sound? I&#39;m in two minds whether this should=
 be something to consider in your proposal or merely something that would d=
epend upon it for standard specializations involving built-in types.<br></d=
iv><div><br>Cheers,<br></div></div></div></div></div>John<br></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Oct 10, 2016 at 9=
:50 PM, Matthew Fioravante <span dir=3D"ltr">&lt;<a href=3D"mailto:fmatthew=
5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">As suggested in the =
other thread about 2&#39;s complement, and also lifted from my previous pro=
posal N3864. I&#39;ve written a small proposal to add explicit shift operat=
ions to the standard library.<div><br></div><div>Should be pretty self expl=
anatory.</div><div><br></div><div><a href=3D"https://github.com/fmatthew587=
6/stdcxx-bitops/blob/master/proposal/shift.md" target=3D"_blank">https://gi=
thub.com/<wbr>fmatthew5876/stdcxx-bitops/<wbr>blob/master/proposal/shift.md=
</a><br></div><div><br></div><div>Please let me know if you have any object=
ions or feedback.</div><div><br></div><div>Thanks!</div></div><span class=
=3D"HOEnZb"><font color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/95e94b53-d65a-4a81-8209-9ec5322d09d7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/95e9=
4b53-d65a-4a81-<wbr>8209-9ec5322d09d7%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></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/CABPJVnQxZvi5S5c4HQN_Rja%2B_thePtRnSW=
93HFvirXP1p1fbVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQxZvi5S5=
c4HQN_Rja%2B_thePtRnSW93HFvirXP1p1fbVA%40mail.gmail.com</a>.<br />

--001a1135043acc42b8053e99f5c7--

.

------=_Part_633_1177444947.1476206914869
Content-Type: multipart/alternative;
 boundary="----=_Part_634_387102295.1476206914869"

------=_Part_634_387102295.1476206914869
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 11, 2016 at 12:11:06 PM UTC-5, John McFarlane wrote:
>
> Hi Matthew,
>
> I am interested in a similar feature specifically related to arithmetic
> scaling (although I'm not completely certain of its necessity yet).
> However, it has a number of extra requirements. Notably, I'd like for users
> to be able to specialize scaling for their own, user-defined types. I'd
> also like to consider powers other than two.
>
> The upshot of these two requirements would be classes in the style of
> std::hash with an additional parameter specifying the base. For example:
>
> // standard
> template<Integral T, int Base>
> struct shar;
>
> // user-defined
> template<>
> struct shar<MyIntegralType, 2> {
>   constexpr MyIntegralType operator()(const MyIntegralType& x, int s);
> }
>
> How palatable does all this sound? I'm in two minds whether this should be
> something to consider in your proposal or merely something that would
> depend upon it for standard specializations involving built-in types.
>
>
Hi John,

The purpose of my proposal is just to give us portable access to basic
shift operations provided by the processor. I think something like what
you're proposing could be done separately as a later step and
implementation of such could possibly be built using mine.

Adding more genericity adds complexity and you yourself have admitted that
you aren't even sure of its necessity. What would likely end up happening
is the combined proposal gets shot down because of all of these
questionable extra features. I've made this mistake in the past with
proposals trying to get too fancy by adding too many things and the half
considered extras ended up killing the most important part which was the
well reasoned about core feature.

As it stands now I believe what I've proposed is extremely simple and easy
to reason about. The 80/20 principle applies and this will solve 80% of the
problems related to shifts, with more specialized and generic use cases
left to the users or later 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b7d2c28-ffed-44f5-b19d-2d906f57a09a%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, October 11, 2016 at 12:11:06 PM UTC-5,=
 John McFarlane 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"><div><div><div><div><div><div>Hi Matthew,<br><br></div>I am intere=
sted in a similar feature specifically related to arithmetic scaling (altho=
ugh I&#39;m not completely certain of its necessity yet). However, it has a=
 number of extra requirements. Notably, I&#39;d like for users to be able t=
o specialize scaling for their own, user-defined types. I&#39;d also like t=
o consider powers other than two. <br><br>The upshot of these two requireme=
nts would be classes in the style of std::hash with an additional parameter=
 specifying the base. For example:<br><br></div><div>// standard<br></div><=
div>template&lt;Integral T, int Base&gt;<br></div><div>struct shar;<br><br>=
</div><div>// user-defined<br></div><div>template&lt;&gt;<br></div><div>str=
uct shar&lt;MyIntegralType, 2&gt; {<br>=C2=A0 constexpr MyIntegralType oper=
ator()(const MyIntegralType&amp; x, int s);<br>}<br><br></div><div>How pala=
table does all this sound? I&#39;m in two minds whether this should be some=
thing to consider in your proposal or merely something that would depend up=
on it for standard specializations involving built-in types.<br></div><div>=
<br></div></div></div></div></div></div></blockquote><div><br></div><div>Hi=
 John,</div><div><br></div><div>The purpose of my proposal is just to give =
us portable access to basic shift operations provided by the processor. I t=
hink something like what you&#39;re proposing could be done separately as a=
 later step and implementation of such could possibly be built using mine.<=
/div><div><br></div><div>Adding more genericity adds complexity and you you=
rself have admitted that you aren&#39;t even sure of its necessity. What wo=
uld likely end up happening is the combined proposal gets shot down because=
 of all of these questionable extra features. I&#39;ve made this mistake in=
 the past with proposals trying to get too fancy by adding too many things =
and the half considered extras ended up killing the most important part whi=
ch was the well reasoned about core feature.</div><div><br></div><div>As it=
 stands now I believe what I&#39;ve proposed is extremely simple and easy t=
o reason about. The 80/20 principle applies and this will solve 80% of the =
problems related to shifts, with more specialized and generic use cases lef=
t to the users or later proposals.</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/5b7d2c28-ffed-44f5-b19d-2d906f57a09a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b7d2c28-ffed-44f5-b19d-2d906f57a09a=
%40isocpp.org</a>.<br />

------=_Part_634_387102295.1476206914869--

------=_Part_633_1177444947.1476206914869--

.

--001a11447fceb2bfcf053e9acfc5
Content-Type: text/plain; charset=UTF-8

That makes a lot of sense. Although, I'm not sure it would be possible to
build upon the functionality of your arithmetic variants without a base
parameter.

For a little background, this is in relation to fixed-point proposal,
P0037R2, which has gained some interest from the financial sector who have
a desire for decimal fixed-point arithmetic. They may separately be
interested in a decimal option with your functions.

On Tue, Oct 11, 2016 at 10:28 AM, Matthew Fioravante <fmatthew5876@gmail.com
> wrote:

>
>
> On Tuesday, October 11, 2016 at 12:11:06 PM UTC-5, John McFarlane wrote:
>>
>> Hi Matthew,
>>
>> I am interested in a similar feature specifically related to arithmetic
>> scaling (although I'm not completely certain of its necessity yet).
>> However, it has a number of extra requirements. Notably, I'd like for users
>> to be able to specialize scaling for their own, user-defined types. I'd
>> also like to consider powers other than two.
>>
>> The upshot of these two requirements would be classes in the style of
>> std::hash with an additional parameter specifying the base. For example:
>>
>> // standard
>> template<Integral T, int Base>
>> struct shar;
>>
>> // user-defined
>> template<>
>> struct shar<MyIntegralType, 2> {
>>   constexpr MyIntegralType operator()(const MyIntegralType& x, int s);
>> }
>>
>> How palatable does all this sound? I'm in two minds whether this should
>> be something to consider in your proposal or merely something that would
>> depend upon it for standard specializations involving built-in types.
>>
>>
> Hi John,
>
> The purpose of my proposal is just to give us portable access to basic
> shift operations provided by the processor. I think something like what
> you're proposing could be done separately as a later step and
> implementation of such could possibly be built using mine.
>
> Adding more genericity adds complexity and you yourself have admitted that
> you aren't even sure of its necessity. What would likely end up happening
> is the combined proposal gets shot down because of all of these
> questionable extra features. I've made this mistake in the past with
> proposals trying to get too fancy by adding too many things and the half
> considered extras ended up killing the most important part which was the
> well reasoned about core feature.
>
> As it stands now I believe what I've proposed is extremely simple and easy
> to reason about. The 80/20 principle applies and this will solve 80% of the
> problems related to shifts, with more specialized and generic use cases
> left to the users or later 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/5b7d2c28-ffed-44f5-
> b19d-2d906f57a09a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b7d2c28-ffed-44f5-b19d-2d906f57a09a%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--001a11447fceb2bfcf053e9acfc5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That makes a lot of sense. Although, I&#39;m not sure=
 it would be possible to build upon the functionality of your arithmetic va=
riants without a base parameter. <br><br>For a little background, this is i=
n relation to fixed-point proposal, P0037R2, which has gained some interest=
 from the financial sector who have a desire for decimal fixed-point arithm=
etic. They may separately be interested in a decimal option with your funct=
ions.<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Oct 11, 2016 at 10:28 AM, Matthew Fioravante <span dir=3D"ltr">=
&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew587=
6@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><span class=3D""><br><br>On Tuesday, October 11, 2016 at 12:11:06=
 PM UTC-5, John McFarlane wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div><div><div><div><div>Hi Matthew,<br><br></div>I am i=
nterested in a similar feature specifically related to arithmetic scaling (=
although I&#39;m not completely certain of its necessity yet). However, it =
has a number of extra requirements. Notably, I&#39;d like for users to be a=
ble to specialize scaling for their own, user-defined types. I&#39;d also l=
ike to consider powers other than two. <br><br>The upshot of these two requ=
irements would be classes in the style of std::hash with an additional para=
meter specifying the base. For example:<br><br></div><div>// standard<br></=
div><div>template&lt;Integral T, int Base&gt;<br></div><div>struct shar;<br=
><br></div><div>// user-defined<br></div><div>template&lt;&gt;<br></div><di=
v>struct shar&lt;MyIntegralType, 2&gt; {<br>=C2=A0 constexpr MyIntegralType=
 operator()(const MyIntegralType&amp; x, int s);<br>}<br><br></div><div>How=
 palatable does all this sound? I&#39;m in two minds whether this should be=
 something to consider in your proposal or merely something that would depe=
nd upon it for standard specializations involving built-in types.<br></div>=
<div><br></div></div></div></div></div></div></blockquote><div><br></div></=
span><div>Hi John,</div><div><br></div><div>The purpose of my proposal is j=
ust to give us portable access to basic shift operations provided by the pr=
ocessor. I think something like what you&#39;re proposing could be done sep=
arately as a later step and implementation of such could possibly be built =
using mine.</div><div><br></div><div>Adding more genericity adds complexity=
 and you yourself have admitted that you aren&#39;t even sure of its necess=
ity. What would likely end up happening is the combined proposal gets shot =
down because of all of these questionable extra features. I&#39;ve made thi=
s mistake in the past with proposals trying to get too fancy by adding too =
many things and the half considered extras ended up killing the most import=
ant part which was the well reasoned about core feature.</div><div><br></di=
v><div>As it stands now I believe what I&#39;ve proposed is extremely simpl=
e and easy to reason about. The 80/20 principle applies and this will solve=
 80% of the problems related to shifts, with more specialized and generic u=
se cases left to the users or later proposals.</div></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5b7d2c28-ffed-44f5-b19d-2d906f57a09a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5b7d=
2c28-ffed-44f5-<wbr>b19d-2d906f57a09a%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CABPJVnT%3DzrencnMBj3VxnUxNaB2jirHbN5=
tf1bY6A8u%2B_xHmpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnT%3Dzr=
encnMBj3VxnUxNaB2jirHbN5tf1bY6A8u%2B_xHmpA%40mail.gmail.com</a>.<br />

--001a11447fceb2bfcf053e9acfc5--

.

On 10/11/16 07:50, Matthew Fioravante wrote:
> As suggested in the other thread about 2's complement, and also lifted
> from my previous proposal N3864. I've written a small proposal to add
> explicit shift operations to the standard library.
>
> Should be pretty self explanatory.
>
> https://github.com/fmatthew5876/stdcxx-bitops/blob/master/proposal/shift.md
>
> Please let me know if you have any objections or feedback.

I'm interested in this proposal and I have a few suggestions.

1. I think it would be better to reverse the letters that denote
left/right and logical/arithmetic shift. I.e. rename shlr -> shrl and
shar -> shra.

2. With the above naming change, add a new function shr(), which will be
equivalent to shra for signed types and shrl for unsigned. I think, this
is the "natural" shift that most developers expect and compilers
implement for operator>>. I would even say, this would be the most
useful shift function.

3. With the above naming change, it might be reasonable to also rename
shll -> shl since there is no arithmetic left shift anyway.

4. Use unsigned int for bit count. Yes, I know the committee members
announced the preference for signed types, but using a signed type and
immediately saying it must never have negative values is just nonsense, IMO.

--
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/e6fc7f3d-c10b-799b-4c01-ccada8a7b12f%40gmail.com.

.

------=_Part_28_1301242095.1477527519243
Content-Type: multipart/alternative;
 boundary="----=_Part_29_59959320.1477527519243"

------=_Part_29_59959320.1477527519243
Content-Type: text/plain; charset=UTF-8

Hi Andrey

On Tuesday, October 18, 2016 at 12:16:59 PM UTC-5, Andrey Semashev wrote:
>
> On 10/11/16 07:50, Matthew Fioravante wrote:
> > As suggested in the other thread about 2's complement, and also lifted
> > from my previous proposal N3864. I've written a small proposal to add
> > explicit shift operations to the standard library.
> >
> > Should be pretty self explanatory.
> >
> >
> https://github.com/fmatthew5876/stdcxx-bitops/blob/master/proposal/shift.md
> >
> > Please let me know if you have any objections or feedback.
>
> I'm interested in this proposal and I have a few suggestions.
>
> 1. I think it would be better to reverse the letters that denote
> left/right and logical/arithmetic shift. I.e. rename shlr -> shrl and
> shar -> shra.
>

I like your names better. We usually say SHift Right Arithmetic instead of
SHift Arithemetic Right.


> 2. With the above naming change, add a new function shr(), which will be
> equivalent to shra for signed types and shrl for unsigned. I think, this
> is the "natural" shift that most developers expect and compilers
> implement for operator>>. I would even say, this would be the most
> useful shift function.


I'm going to stay away from this one for now. We already have a function in
the standard, its called operator>>(). See my other post about that.

It comes down to a question of whether we fix operator>>() or leave it
broken and adopt a replacement like shr(). I'm worried that by introducing
such a function the proposal gets dragged down into that discussion and
rejected entirely.


>
> 3. With the above naming change, it might be reasonable to also rename
> shll -> shl since there is no arithmetic left shift anyway.
>

Seems reasonable to me. Although shl() is actually redundant so maybe I
should remove it. We only really need the right shifts.


>
> 4. Use unsigned int for bit count. Yes, I know the committee members
> announced the preference for signed types, but using a signed type and
> immediately saying it must never have negative values is just nonsense,
> IMO.
>

Thats a philosophical question. Honestly I really don't care whether its
signed or unsigned.

--
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/4a1ba714-9041-45af-b4d9-a3109b85b466%40isocpp.org.

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

<div dir=3D"ltr">Hi Andrey<br><br>On Tuesday, October 18, 2016 at 12:16:59 =
PM UTC-5, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">On 10/11/16 07:50, Matthew Fioravante wrote:
<br>&gt; As suggested in the other thread about 2&#39;s complement, and als=
o lifted
<br>&gt; from my previous proposal N3864. I&#39;ve written a small proposal=
 to add
<br>&gt; explicit shift operations to the standard library.
<br>&gt;
<br>&gt; Should be pretty self explanatory.
<br>&gt;
<br>&gt; <a href=3D"https://github.com/fmatthew5876/stdcxx-bitops/blob/mast=
er/proposal/shift.md" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ffm=
atthew5876%2Fstdcxx-bitops%2Fblob%2Fmaster%2Fproposal%2Fshift.md\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNEYvomosXbcoB3i13EfYyFJ9xmkew&#39;;return true=
;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Ffmatthew5876%2Fstdcxx-bitops%2Fblob%2Fmaster%2Fproposal%2Fsh=
ift.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEYvomosXbcoB3i13EfYyFJ9xmkew=
&#39;;return true;">https://github.com/<wbr>fmatthew5876/stdcxx-bitops/<wbr=
>blob/master/proposal/shift.md</a>
<br>&gt;
<br>&gt; Please let me know if you have any objections or feedback.
<br>
<br>I&#39;m interested in this proposal and I have a few suggestions.
<br>
<br>1. I think it would be better to reverse the letters that denote=20
<br>left/right and logical/arithmetic shift. I.e. rename shlr -&gt; shrl an=
d=20
<br>shar -&gt; shra.
<br></blockquote><div><br></div><div>I like your names better. We usually s=
ay SHift Right Arithmetic instead of SHift Arithemetic Right.=C2=A0</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>2. With the above naming change, add a new function shr(), which will b=
e=20
<br>equivalent to shra for signed types and shrl for unsigned. I think, thi=
s=20
<br>is the &quot;natural&quot; shift that most developers expect and compil=
ers=20
<br>implement for operator&gt;&gt;. I would even say, this would be the mos=
t=20
<br>useful shift function.=C2=A0</blockquote><div><br></div><div>I&#39;m go=
ing to stay away from this one for now. We already have a function in the s=
tandard, its called operator&gt;&gt;(). See my other post about that.=C2=A0=
</div><div><br></div><div>It comes down to a question of whether we fix ope=
rator&gt;&gt;() or leave it broken and adopt a replacement like shr(). I&#3=
9;m worried that by introducing such a function the proposal gets dragged d=
own into that discussion and rejected entirely.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<br>3. With the above naming change, it might be reasonable to also rename=
=20
<br>shll -&gt; shl since there is no arithmetic left shift anyway.
<br></blockquote><div><br></div><div>Seems reasonable to me. Although shl()=
 is actually redundant so maybe I should remove it. We only really need the=
 right shifts.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">
<br>4. Use unsigned int for bit count. Yes, I know the committee members=20
<br>announced the preference for signed types, but using a signed type and=
=20
<br>immediately saying it must never have negative values is just nonsense,=
 IMO.
<br></blockquote><div><br></div><div>Thats a philosophical question. Honest=
ly I really don&#39;t care whether its signed or unsigned. =C2=A0</div></di=
v>

<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/4a1ba714-9041-45af-b4d9-a3109b85b466%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a1ba714-9041-45af-b4d9-a3109b85b466=
%40isocpp.org</a>.<br />

------=_Part_29_59959320.1477527519243--

------=_Part_28_1301242095.1477527519243--

.

On 10/27/16 03:18, Matthew Fioravante wrote:
> Hi Andrey
>
> On Tuesday, October 18, 2016 at 12:16:59 PM UTC-5, Andrey Semashev wrote:
>
>     2. With the above naming change, add a new function shr(), which
>     will be
>     equivalent to shra for signed types and shrl for unsigned. I think,
>     this
>     is the "natural" shift that most developers expect and compilers
>     implement for operator>>. I would even say, this would be the most
>     useful shift function.
>
> I'm going to stay away from this one for now. We already have a function
> in the standard, its called operator>>(). See my other post about that.
>
> It comes down to a question of whether we fix operator>>() or leave it
> broken and adopt a replacement like shr(). I'm worried that by
> introducing such a function the proposal gets dragged down into that
> discussion and rejected entirely.

If we fix the operator>> so that it is portably defined for all inputs
then none of these functions are needed. If we don't, then shr() would
be useful, extremely so in generic code.

The problem I see in fixing operator>> is that I find a hard time seeing
it fixed without also requiring two's complement representation of
signed integers. Defining the operator only iff integers are two's
complement seems like a half solution to me. I mean, how should
programmers write their code portably if this change is made?

Defining operator>> in terms of bit patterns might be more viable, but
there's the question of trap representations. What if the shift
operation results in a trap representation?

Really, I think signed integers in C++ are doomed as there are currently
too many gotchas around them. C++ is a hostage of its own portability
here. I'm thinking about writing a signed facade around unsigned
integers that would just remove all "undefined" cases and never using
signed integers ever again. That facade would have two's complement
integer representation and the arithmetic right shift, as expected. I
find it embarrassing that a full-blown library solution is needed for
such a simple and intrinsic thing as integers.

>     3. With the above naming change, it might be reasonable to also rename
>     shll -> shl since there is no arithmetic left shift anyway.
>
> Seems reasonable to me. Although shl() is actually redundant so maybe I
> should remove it. We only really need the right shifts.

I would prefer it there, for the completeness sake.

>     4. Use unsigned int for bit count. Yes, I know the committee members
>     announced the preference for signed types, but using a signed type and
>     immediately saying it must never have negative values is just
>     nonsense, IMO.
>
> Thats a philosophical question. Honestly I really don't care whether its
> signed or unsigned.

For me, that is a question of interface clarity. If the function does
not handle negative values, don't provide a way to provide 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ab6cba70-1559-2570-bb07-39742754f9f1%40gmail.com.

.

On quarta-feira, 26 de outubro de 2016 17:18:39 PDT Matthew Fioravante wrote:
> > 1. I think it would be better to reverse the letters that denote
> > left/right and logical/arithmetic shift. I.e. rename shlr -> shrl and
> > shar -> shra.
>
> I like your names better. We usually say SHift Right Arithmetic instead of
> SHift Arithemetic Right.

Another option is to move to the beginning: Logical Shift Right (LSHR or LSR),
Arithmetic Shift Left (ASL), etc. This is what ARM assembly does.

Any way you choose, you're going to find an assembly with different mnemonics.
It's a matter of how many people you're going displease. Just try to choose
something that doesn't cause confusion: it should be unambiguous whether the
shift is to the left or to the right.

> > 3. With the above naming change, it might be reasonable to also rename
> > shll -> shl since there is no arithmetic left shift anyway.
>
> Seems reasonable to me. Although shl() is actually redundant so maybe I
> should remove it. We only really need the right shifts.

Actually, no. Shifting left into the sign bit of a signed integer is undefined.
So this function may still be useful.

> > 4. Use unsigned int for bit count. Yes, I know the committee members
> > announced the preference for signed types, but using a signed type and
> > immediately saying it must never have negative values is just nonsense,
> > IMO.
>
> Thats a philosophical question. Honestly I really don't care whether its
> signed or unsigned.

It might be useful to shift in the other direction if the count is negative.
That would imply a difference in arithmetic and logical shifts left, since
they could go right too.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1723826.oeVGczXg3q%40tjmaciei-mobl1.

.

------=_Part_268_1249419263.1477604463468
Content-Type: multipart/alternative;
 boundary="----=_Part_269_1918405433.1477604463468"

------=_Part_269_1918405433.1477604463468
Content-Type: text/plain; charset=UTF-8



On Thursday, October 27, 2016 at 4:31:30 PM UTC-5, Thiago Macieira wrote:
>
> On quarta-feira, 26 de outubro de 2016 17:18:39 PDT Matthew Fioravante
> wrote:
> > > 1. I think it would be better to reverse the letters that denote
> > > left/right and logical/arithmetic shift. I.e. rename shlr -> shrl and
> > > shar -> shra.
> >
> > I like your names better. We usually say SHift Right Arithmetic instead
> of
> > SHift Arithemetic Right.
>
> Another option is to move to the beginning: Logical Shift Right (LSHR or
> LSR),
> Arithmetic Shift Left (ASL), etc. This is what ARM assembly does.
>
> Any way you choose, you're going to find an assembly with different
> mnemonics.
> It's a matter of how many people you're going displease. Just try to
> choose
> something that doesn't cause confusion: it should be unambiguous whether
> the
> shift is to the left or to the right.
>
> > > 3. With the above naming change, it might be reasonable to also rename
> > > shll -> shl since there is no arithmetic left shift anyway.
> >
> > Seems reasonable to me. Although shl() is actually redundant so maybe I
> > should remove it. We only really need the right shifts.
>
> Actually, no. Shifting left into the sign bit of a signed integer is
> undefined.
> So this function may still be useful.
>

Interesting, I wasn't aware of this one. I'll add this to the paper.


>
> > > 4. Use unsigned int for bit count. Yes, I know the committee members
> > > announced the preference for signed types, but using a signed type and
> > > immediately saying it must never have negative values is just
> nonsense,
> > > IMO.
> >
> > Thats a philosophical question. Honestly I really don't care whether its
> > signed or unsigned.
>
> It might be useful to shift in the other direction if the count is
> negative.
> That would imply a difference in arithmetic and logical shifts left, since
> they could go right too.
>

This is a direction I don't want to go. These are supposed to be fast
assembly mnemonics. If we add support for negative shifts and the user
passes in a runtime value for the shift amount then now we have a branch.

Also It seems silly to have right shift and left shift functions when
you're using a signed value to determine shift direction. Do away with
directionality in the name and just have functions called arith_shift(),
log_shift(), and rot_shift() which shift left for negative and right for
positive.


>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>

--
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/c1b9daf9-5c98-4dab-8712-b351ee333576%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, October 27, 2016 at 4:31:30 PM UTC-5,=
 Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quar=
ta-feira, 26 de outubro de 2016 17:18:39 PDT Matthew Fioravante wrote:
<br>&gt; &gt; 1. I think it would be better to reverse the letters that den=
ote
<br>&gt; &gt; left/right and logical/arithmetic shift. I.e. rename shlr -&g=
t; shrl and
<br>&gt; &gt; shar -&gt; shra.
<br>&gt;=20
<br>&gt; I like your names better. We usually say SHift Right Arithmetic in=
stead of
<br>&gt; SHift Arithemetic Right.
<br>
<br>Another option is to move to the beginning: Logical Shift Right (LSHR o=
r LSR),=20
<br>Arithmetic Shift Left (ASL), etc. This is what ARM assembly does.
<br>
<br>Any way you choose, you&#39;re going to find an assembly with different=
 mnemonics.=20
<br>It&#39;s a matter of how many people you&#39;re going displease. Just t=
ry to choose=20
<br>something that doesn&#39;t cause confusion: it should be unambiguous wh=
ether the=20
<br>shift is to the left or to the right.
<br>
<br>&gt; &gt; 3. With the above naming change, it might be reasonable to al=
so rename
<br>&gt; &gt; shll -&gt; shl since there is no arithmetic left shift anyway=
..
<br>&gt;=20
<br>&gt; Seems reasonable to me. Although shl() is actually redundant so ma=
ybe I
<br>&gt; should remove it. We only really need the right shifts.
<br>
<br>Actually, no. Shifting left into the sign bit of a signed integer is un=
defined.=20
<br>So this function may still be useful.
<br></blockquote><div><br></div><div>Interesting, I wasn&#39;t aware of thi=
s one. I&#39;ll add this to the paper.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
<br>&gt; &gt; 4. Use unsigned int for bit count. Yes, I know the committee =
members
<br>&gt; &gt; announced the preference for signed types, but using a signed=
 type and
<br>&gt; &gt; immediately saying it must never have negative values is just=
 nonsense,
<br>&gt; &gt; IMO.
<br>&gt;=20
<br>&gt; Thats a philosophical question. Honestly I really don&#39;t care w=
hether its
<br>&gt; signed or unsigned.
<br>
<br>It might be useful to shift in the other direction if the count is nega=
tive.=20
<br>That would imply a difference in arithmetic and logical shifts left, si=
nce=20
<br>they could go right too.
<br></blockquote><div><br></div><div>This is a direction I don&#39;t want t=
o go. These are supposed to be fast assembly mnemonics. If we add support f=
or negative shifts and the user passes in a runtime value for the shift amo=
unt then now we have a branch.</div><div><br></div><div>Also It seems silly=
 to have right shift and left shift functions when you&#39;re using a signe=
d value to determine shift direction. Do away with directionality in the na=
me and just have functions called arith_shift(), log_shift(), and rot_shift=
() which shift left for negative and right for positive.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></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/c1b9daf9-5c98-4dab-8712-b351ee333576%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c1b9daf9-5c98-4dab-8712-b351ee333576=
%40isocpp.org</a>.<br />

------=_Part_269_1918405433.1477604463468--

------=_Part_268_1249419263.1477604463468--

.

Em quinta-feira, 27 de outubro de 2016, =C3=A0s 14:41:03 PDT, Matthew Fiora=
vante
> > Actually, no. Shifting left into the sign bit of a signed integer is
> > undefined.
> > So this function may still be useful.
>=20
> Interesting, I wasn't aware of this one. I'll add this to the paper.

Subtle wording of 5.9 [expr.shift]/2, that says:

"Otherwise, if E1 has a signed type and non-negative value, and E1 =C3=97 2=
^E2 is=20
representable in the corresponding unsigned type of the result type, then t=
hat=20
value, converted to the result type, is the resulting value; otherwise, the=
=20
behavior is undefined."

1 << 31 implies 1 * 2^31 =3D 2147483648, which is not representable in int,=
=20
therefore it's undefined to shift into the sign bit.

int(1U << 31) is implementation-defined.

> > It might be useful to shift in the other direction if the count is
> > negative.
> > That would imply a difference in arithmetic and logical shifts left, si=
nce
> > they could go right too.
>=20
> This is a direction I don't want to go. These are supposed to be fast
> assembly mnemonics. If we add support for negative shifts and the user
> passes in a runtime value for the shift amount then now we have a branch.

Fair enough, that's a good argument.

Sorry for missing the beginning of the discussion, but what is the plan for=
=20
when the shift count is larger than the type's size? That's UB in the stand=
ard=20
for the built-in operators.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

------=_Part_358_18306485.1477620416505
Content-Type: multipart/alternative;
 boundary="----=_Part_359_1194312159.1477620416505"

------=_Part_359_1194312159.1477620416505
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
> Subtle wording of 5.9 [expr.shift]/2, that says:=20
>
> "Otherwise, if E1 has a signed type and non-negative value, and E1 =C3=97=
 2^E2=20
> is=20
> representable in the corresponding unsigned type of the result type, then=
=20
> that=20
> value, converted to the result type, is the resulting value; otherwise,=
=20
> the=20
> behavior is undefined."=20
>
> 1 << 31 implies 1 * 2^31 =3D 2147483648, which is not representable in in=
t,=20
> therefore it's undefined to shift into the sign bit.=20
>

To nitpick, you can (since C++14=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457>)=20
left-shift into the sign bit, but not past it. However, the resulting value=
=20
is implementation-defined. Assuming 32-bit ints, 1 << 31 is equivalent to=
=20
static_cast<int>(2147483648) because 1 * 2^31 "is representable in the=20
corresponding unsigned type of the result type" (i.e. unsigned int).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0bcee386-89f3-4294-931a-dfb2cd590468%40isocpp.or=
g.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Subtle wordin=
g of 5.9 [expr.shift]/2, that says:
<br>
<br>&quot;Otherwise, if E1 has a signed type and non-negative value, and E1=
 =C3=97 2^E2 is=20
<br>representable in the corresponding unsigned type of the result type, th=
en that=20
<br>value, converted to the result type, is the resulting value; otherwise,=
 the=20
<br>behavior is undefined.&quot;
<br>
<br>1 &lt;&lt; 31 implies 1 * 2^31 =3D 2147483648, which is not representab=
le in int,=20
<br>therefore it&#39;s undefined to shift into the sign bit.
<br></blockquote><div><br>To nitpick, you can (<a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457">since C++14</a>) left-shi=
ft into the sign bit, but not past it. However, the resulting value is impl=
ementation-defined. Assuming 32-bit ints, <span style=3D"font-family: couri=
er new,monospace;">1 &lt;&lt; 31</span> is equivalent to <span style=3D"fon=
t-family: courier new,monospace;">static_cast&lt;int&gt;(2147483648)</span>=
 because 1 * 2^31 &quot;is representable in the corresponding unsigned type=
 of the result type&quot; (i.e. unsigned int).<br></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/0bcee386-89f3-4294-931a-dfb2cd590468%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0bcee386-89f3-4294-931a-dfb2cd590468=
%40isocpp.org</a>.<br />

------=_Part_359_1194312159.1477620416505--

------=_Part_358_18306485.1477620416505--

.

------=_Part_531_1255310382.1477621828423
Content-Type: multipart/alternative;
 boundary="----=_Part_532_50819264.1477621828423"

------=_Part_532_50819264.1477621828423
Content-Type: text/plain; charset=UTF-8



On Thursday, October 27, 2016 at 7:53:29 PM UTC-5, Thiago Macieira wrote:
>
>
> Sorry for missing the beginning of the discussion, but what is the plan
> for
> when the shift count is larger than the type's size? That's UB in the
> standard
> for the built-in operators.
>

Same undefined behavior for portable maximal efficiency. Think of this
working exactly like operator>>() but with well defined semantics for the
high bits of a right shift.


>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>

--
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/5d7e2b18-20db-4e9b-b73c-5f5b74e28318%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, October 27, 2016 at 7:53:29 PM UTC-5,=
 Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Sor=
ry for missing the beginning of the discussion, but what is the plan for=20
<br>when the shift count is larger than the type&#39;s size? That&#39;s UB =
in the standard=20
<br>for the built-in operators.<br></blockquote><div><br></div><div>Same un=
defined behavior for portable maximal efficiency. Think of this working exa=
ctly like operator&gt;&gt;() but with well defined semantics for the high b=
its of a right shift.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></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/5d7e2b18-20db-4e9b-b73c-5f5b74e28318%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d7e2b18-20db-4e9b-b73c-5f5b74e28318=
%40isocpp.org</a>.<br />

------=_Part_532_50819264.1477621828423--

------=_Part_531_1255310382.1477621828423--

.

Em quinta-feira, 27 de outubro de 2016, =C3=A0s 19:06:56 PDT, Chris Hallock=
=20
escreveu:
> > Subtle wording of 5.9 [expr.shift]/2, that says:
> >=20
> > "Otherwise, if E1 has a signed type and non-negative value, and E1 =C3=
=97 2^E2
> > is
> > representable in the corresponding unsigned type of the result type, th=
en
> > that
> > value, converted to the result type, is the resulting value; otherwise,
> > the
> > behavior is undefined."
> >=20
> > 1 << 31 implies 1 * 2^31 =3D 2147483648, which is not representable in =
int,
> > therefore it's undefined to shift into the sign bit.
>=20
> To nitpick, you can (since C++14
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457>)
> left-shift into the sign bit, but not past it. However, the resulting val=
ue
> is implementation-defined. Assuming 32-bit ints, 1 << 31 is equivalent to
> static_cast<int>(2147483648) because 1 * 2^31 "is representable in the
> corresponding unsigned type of the result type" (i.e. unsigned int).

Hmm... you're actually right. The resolution of CWG1457 is already in the t=
ext=20
I quoted.

So it isn't UB, it's implementation-defined behaviour.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

------=_Part_508_185437560.1477624630788
Content-Type: multipart/alternative;
 boundary="----=_Part_509_1501697231.1477624630789"

------=_Part_509_1501697231.1477624630789
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, October 27, 2016 at 9:47:23 PM UTC-5, Thiago Macieira wrote:
>
> Em quinta-feira, 27 de outubro de 2016, =C3=A0s 19:06:56 PDT, Chris Hallo=
ck=20
> escreveu:=20
> > > Subtle wording of 5.9 [expr.shift]/2, that says:=20
> > >=20
> > > "Otherwise, if E1 has a signed type and non-negative value, and E1 =
=C3=97=20
> 2^E2=20
> > > is=20
> > > representable in the corresponding unsigned type of the result type,=
=20
> then=20
> > > that=20
> > > value, converted to the result type, is the resulting value;=20
> otherwise,=20
> > > the=20
> > > behavior is undefined."=20
> > >=20
> > > 1 << 31 implies 1 * 2^31 =3D 2147483648, which is not representable i=
n=20
> int,=20
> > > therefore it's undefined to shift into the sign bit.=20
> >=20
> > To nitpick, you can (since C++14=20
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457>)=20
> > left-shift into the sign bit, but not past it. However, the resulting=
=20
> value=20
> > is implementation-defined. Assuming 32-bit ints, 1 << 31 is equivalent=
=20
> to=20
> > static_cast<int>(2147483648) because 1 * 2^31 "is representable in the=
=20
> > corresponding unsigned type of the result type" (i.e. unsigned int).=20
>
> Hmm... you're actually right. The resolution of CWG1457 is already in the=
=20
> text=20
> I quoted.=20
>
> So it isn't UB, it's implementation-defined behaviour.=20
>
>
Does anyone else find it kind of sad that all of us who could be considered=
=20
expert level C++ programmers still don't know little caveat rules like=20
this?? How is there any hope for novices..=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/44e604a3-1a8b-4058-8524-0191ba2750f2%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Thursday, October 27, 2016 at 9:47:23 PM UTC-5,=
 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 quin=
ta-feira, 27 de outubro de 2016, =C3=A0s 19:06:56 PDT, Chris Hallock=20
<br>escreveu:
<br>&gt; &gt; Subtle wording of 5.9 [expr.shift]/2, that says:
<br>&gt; &gt;=20
<br>&gt; &gt; &quot;Otherwise, if E1 has a signed type and non-negative val=
ue, and E1 =C3=97 2^E2
<br>&gt; &gt; is
<br>&gt; &gt; representable in the corresponding unsigned type of the resul=
t type, then
<br>&gt; &gt; that
<br>&gt; &gt; value, converted to the result type, is the resulting value; =
otherwise,
<br>&gt; &gt; the
<br>&gt; &gt; behavior is undefined.&quot;
<br>&gt; &gt;=20
<br>&gt; &gt; 1 &lt;&lt; 31 implies 1 * 2^31 =3D 2147483648, which is not r=
epresentable in int,
<br>&gt; &gt; therefore it&#39;s undefined to shift into the sign bit.
<br>&gt;=20
<br>&gt; To nitpick, you can (since C++14
<br>&gt; &lt;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_def=
ects.html#1457" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%231457\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNEK4o6a1txapugY-5I83mgtNIAgrw&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%231457\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNEK4o6a1txapugY-5I83mgtNIAgrw&#39;;return true;">http://w=
ww.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_defects.<wbr>html#1457</a>&gt;=
)
<br>&gt; left-shift into the sign bit, but not past it. However, the result=
ing value
<br>&gt; is implementation-defined. Assuming 32-bit ints, 1 &lt;&lt; 31 is =
equivalent to
<br>&gt; static_cast&lt;int&gt;(2147483648) because 1 * 2^31 &quot;is repre=
sentable in the
<br>&gt; corresponding unsigned type of the result type&quot; (i.e. unsigne=
d int).
<br>
<br>Hmm... you&#39;re actually right. The resolution of CWG1457 is already =
in the text=20
<br>I quoted.
<br>
<br>So it isn&#39;t UB, it&#39;s implementation-defined behaviour.
<br><br></blockquote><div><br></div><div>Does anyone else find it kind of s=
ad that all of us who could be considered expert level C++ programmers stil=
l don&#39;t know little caveat rules like this?? How is there any hope for =
novices..=C2=A0</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/44e604a3-1a8b-4058-8524-0191ba2750f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44e604a3-1a8b-4058-8524-0191ba2750f2=
%40isocpp.org</a>.<br />

------=_Part_509_1501697231.1477624630789--

------=_Part_508_185437560.1477624630788--

.

On 10/28/16 05:06, Chris Hallock wrote:
>     Subtle wording of 5.9 [expr.shift]/2, that says:
>
>     "Otherwise, if E1 has a signed type and non-negative value, and E1 =
=C3=97
>     2^E2 is
>     representable in the corresponding unsigned type of the result type,
>     then that
>     value, converted to the result type, is the resulting value;
>     otherwise, the
>     behavior is undefined."
>
>     1 << 31 implies 1 * 2^31 =3D 2147483648, which is not representable i=
n
>     int,
>     therefore it's undefined to shift into the sign bit.
>
>
> To nitpick, you can (since C++14
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457>)
> left-shift into the sign bit, but not past it. However, the resulting
> value is implementation-defined. Assuming 32-bit ints, 1 << 31 is
> equivalent to static_cast<int>(2147483648) because 1 * 2^31 "is
> representable in the corresponding unsigned type of the result type"
> (i.e. unsigned int).

<nitpick> Except that static_cast<int>(2147483648) overflows, which is=20
UB. Assuming int is 32-bit two's complement, it should be -2147483648.=20
</nitpick>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1e687ac9-1bd9-5813-478f-d0ac3ecdd6d4%40gmail.com=
..

.

------=_Part_993_968623274.1477661917797
Content-Type: multipart/alternative;
 boundary="----=_Part_994_1384225986.1477661917798"

------=_Part_994_1384225986.1477661917798
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Friday, October 28, 2016 at 5:58:38 AM UTC-4, Andrey Semashev wrote:
>
> On 10/28/16 05:06, Chris Hallock wrote:=20
> >     Subtle wording of 5.9 [expr.shift]/2, that says:=20
> >=20
> >     "Otherwise, if E1 has a signed type and non-negative value, and E1 =
=C3=97=20
> >     2^E2 is=20
> >     representable in the corresponding unsigned type of the result type=
,=20
> >     then that=20
> >     value, converted to the result type, is the resulting value;=20
> >     otherwise, the=20
> >     behavior is undefined."=20
> >=20
> >     1 << 31 implies 1 * 2^31 =3D 2147483648, which is not representable=
 in=20
> >     int,=20
> >     therefore it's undefined to shift into the sign bit.=20
> >=20
> >=20
> > To nitpick, you can (since C++14=20
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457>)=20
> > left-shift into the sign bit, but not past it. However, the resulting=
=20
> > value is implementation-defined. Assuming 32-bit ints, 1 << 31 is=20
> > equivalent to static_cast<int>(2147483648) because 1 * 2^31 "is=20
> > representable in the corresponding unsigned type of the result type"=20
> > (i.e. unsigned int).=20
>
> <nitpick> Except that static_cast<int>(2147483648) overflows, which is=20
> UB. Assuming int is 32-bit two's complement, it should be -2147483648.=20
> </nitpick>=20
>
>
Nitpick parry: it's implementation-defined, not UB. The static_cast finds=
=20
an implicit conversion sequence ([expr.static.cast]/4) from the type of the=
=20
literal, which is either long or long long ([lex.icon]/2), to int. The=20
implicit conversion sequence consists of an integral conversion, which is=
=20
implementation-defined if the input doesn't fit in a signed result type=20
([conv.integral]/3).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f6dd3892-7b8f-45f2-9d26-505970939360%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Friday, October 28, 2016 at 5:58:38 AM UTC-4, A=
ndrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/28/=
16 05:06, Chris Hallock wrote:
<br>&gt; =C2=A0 =C2=A0 Subtle wording of 5.9 [expr.shift]/2, that says:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 &quot;Otherwise, if E1 has a signed type and non-neg=
ative value, and E1 =C3=97
<br>&gt; =C2=A0 =C2=A0 2^E2 is
<br>&gt; =C2=A0 =C2=A0 representable in the corresponding unsigned type of =
the result type,
<br>&gt; =C2=A0 =C2=A0 then that
<br>&gt; =C2=A0 =C2=A0 value, converted to the result type, is the resultin=
g value;
<br>&gt; =C2=A0 =C2=A0 otherwise, the
<br>&gt; =C2=A0 =C2=A0 behavior is undefined.&quot;
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 1 &lt;&lt; 31 implies 1 * 2^31 =3D 2147483648, which=
 is not representable in
<br>&gt; =C2=A0 =C2=A0 int,
<br>&gt; =C2=A0 =C2=A0 therefore it&#39;s undefined to shift into the sign =
bit.
<br>&gt;
<br>&gt;
<br>&gt; To nitpick, you can (since C++14
<br>&gt; &lt;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_def=
ects.html#1457" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%231457\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNEK4o6a1txapugY-5I83mgtNIAgrw&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%231457\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNEK4o6a1txapugY-5I83mgtNIAgrw&#39;;return true;">http://w=
ww.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_defects.<wbr>html#1457</a>&gt;=
)
<br>&gt; left-shift into the sign bit, but not past it. However, the result=
ing
<br>&gt; value is implementation-defined. Assuming 32-bit ints, 1 &lt;&lt; =
31 is
<br>&gt; equivalent to static_cast&lt;int&gt;(2147483648) because 1 * 2^31 =
&quot;is
<br>&gt; representable in the corresponding unsigned type of the result typ=
e&quot;
<br>&gt; (i.e. unsigned int).
<br>
<br>&lt;nitpick&gt; Except that static_cast&lt;int&gt;(2147483648) overflow=
s, which is=20
<br>UB. Assuming int is 32-bit two&#39;s complement, it should be -21474836=
48.=20
<br>&lt;/nitpick&gt;
<br>
<br></blockquote><div><br>Nitpick parry: it&#39;s implementation-defined, n=
ot UB. The static_cast finds an implicit conversion sequence ([expr.static.=
cast]/4) from the type of the literal, which is either long or long long ([=
lex.icon]/2), to int. The implicit conversion sequence consists of an integ=
ral conversion, which is implementation-defined if the input doesn&#39;t fi=
t in a signed result type ([conv.integral]/3).<br></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/f6dd3892-7b8f-45f2-9d26-505970939360%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6dd3892-7b8f-45f2-9d26-505970939360=
%40isocpp.org</a>.<br />

------=_Part_994_1384225986.1477661917798--

------=_Part_993_968623274.1477661917797--

.

Em quinta-feira, 27 de outubro de 2016, =C3=A0s 20:17:10 PDT, Matthew Fiora=
vante=20
escreveu:
> > Hmm... you're actually right. The resolution of CWG1457 is already in t=
he
> > text
> > I quoted.
> >=20
> > So it isn't UB, it's implementation-defined behaviour.
>=20
> Does anyone else find it kind of sad that all of us who could be consider=
ed
> expert level C++ programmers still don't know little caveat rules like
> this?? How is there any hope for novices..

Well, it used to be UB. I searched for the text that was making it so, copy=
 &=20
pasted it. I just failed to re-read it and notice that it had changed, maki=
ng=20
it IDB instead of UB.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 2016-10-28 05:17, Matthew Fioravante wrote:
>
>
> On Thursday, October 27, 2016 at 9:47:23 PM UTC-5, Thiago Macieira wrote:
>
>     Em quinta-feira, 27 de outubro de 2016, =C3=A0s 19:06:56 PDT, Chris H=
allock
>     escreveu:
>     > > Subtle wording of 5.9 [expr.shift]/2, that says:
>     > >
>     > > "Otherwise, if E1 has a signed type and non-negative value, and
>     E1 =C3=97 2^E2
>     > > is
>     > > representable in the corresponding unsigned type of the result
>     type, then
>     > > that
>     > > value, converted to the result type, is the resulting value;
>     otherwise,
>     > > the
>     > > behavior is undefined."
>     > >
>     > > 1 << 31 implies 1 * 2^31 =3D 2147483648, which is not
>     representable in int,
>     > > therefore it's undefined to shift into the sign bit.
>     >
>     > To nitpick, you can (since C++14
>     > <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457>>)
>     > left-shift into the sign bit, but not past it. However, the
>     resulting value
>     > is implementation-defined. Assuming 32-bit ints, 1 << 31 is
>     equivalent to
>     > static_cast<int>(2147483648) because 1 * 2^31 "is representable in
>     the
>     > corresponding unsigned type of the result type" (i.e. unsigned int)=
..
>
>     Hmm... you're actually right. The resolution of CWG1457 is already
>     in the text
>     I quoted.
>
>     So it isn't UB, it's implementation-defined behaviour.
>
>
> Does anyone else find it kind of sad that all of us who could be
> considered expert level C++ programmers still don't know little caveat
> rules like this?? How is there any hope for novices..
>

The difference is extremely small.

If it is UB, an implementation is still *allowed* to document some=20
reasonable behavior. Now it is *required* to document it, but the=20
behavior might still be blow-up (a hardware trap).

So for any code you want to be portable, you will still have to read the=20
documentation for every possible compiler. Just like it was before.


     Bo Persson



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nv1tl9%24mv0%241%40blaine.gmane.org.

.