Topic: Understanding the evaluation order compromise
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 9 Jul 2016 11:00:30 -0700 (PDT)
Raw View
------=_Part_255_822653869.1468087230374
Content-Type: multipart/alternative;
boundary="----=_Part_256_851379943.1468087230374"
------=_Part_256_851379943.1468087230374
Content-Type: text/plain; charset=UTF-8
C++17's CD has apparently voted in the expression evaluation order
proposal, but as I understand it, they used the "Alternate Evaluation Order
for Function Calls" That says:
the expression in the function position is evaluated before all the
> arguments and the evaluations of the arguments are indeterminately
> sequenced, but with no interleaving.
>
So, I want to make sure I understand something.
This has well defined behavior:
template<typename Ts...>
void func(Ts&&... args)
{
vector<int> v;
v.reserve(sizeof...(Ts));
(v.insert(v.end(), std::forward<Ts>(args)), ...);
}
This will insert to the end of `v` every element in `args`, in the order of
the arguments passed to `func`.
But this will not:
template<typename Ts...>
void func(Ts&&... args)
{
vector<int> v;
v.reserve(sizeof...(Ts));
auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
}
So, by the mere act of calling a function on the return values, the state
of `v` is unspecified.
Now, the new sequencing rules will at least ensure that this code results
in a valid `v`. That is, each `v.end` will be called, followed by its
corresponding `v.insert`. There won't be any interleaving, so `v` will have
actual data in it in some order. And the returned iterators will all be
equally valid.
But there also won't be a guaranteed order. All because it was wrapped in a
function call.
Is my understanding of things correct? Would people not consider this
highly surprising behavior?
--
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/d9433013-9b95-495f-b1ed-289673dd87a3%40isocpp.org.
------=_Part_256_851379943.1468087230374
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">C++17's CD has apparently voted in the expression eval=
uation order proposal, but as I understand it, they used the "Alternat=
e Evaluation Order for Function Calls" That says:<br><br><blockquote s=
tyle=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;" class=3D"gmail_quote">the expression in the function=
position is evaluated before all the arguments and the evaluations of the =
arguments are indeterminately sequenced, but with no interleaving.<br></blo=
ckquote><br>So, I want to make sure I understand something.<br><br>This has=
well defined behavior:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Ts</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Ts</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">&&...</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> args</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 vector</span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify"><int></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 v</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">reserve</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">...(</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">insert</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">v</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">end</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">forward</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">args</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)),</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">...);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span></div></code></div><br>This will insert to the end of `v` every el=
ement in `args`, in the order of the arguments passed to `func`.<br><br>But=
this will not:<br><br><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"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">...></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Ts</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&&...</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> args</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 vector</span><span style=3D"color: #080;" class=3D"styled=
-by-prettify"><int></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 v</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">re=
serve</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">...(</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> inserts </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> make_array</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">insert</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">v</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">end</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">forward</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Ts</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">>(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">))...);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span></div></code></div><br>So, by the mere act of calling a functio=
n on the return values, the state of `v` is unspecified.<br><br>Now, the ne=
w sequencing rules will at least ensure that this code results in a valid `=
v`. That is, each `v.end` will be called, followed by its corresponding `v.=
insert`. There won't be any interleaving, so `v` will have actual data =
in it in some order. And the returned iterators will all be equally valid.<=
br><br>But there also won't be a guaranteed order. All because it was w=
rapped in a function call.<br><br>Is my understanding of things correct? Wo=
uld people not consider this highly surprising behavior?<br></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/d9433013-9b95-495f-b1ed-289673dd87a3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d9433013-9b95-495f-b1ed-289673dd87a3=
%40isocpp.org</a>.<br />
------=_Part_256_851379943.1468087230374--
------=_Part_255_822653869.1468087230374--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Sun, 10 Jul 2016 14:52:14 -0700 (PDT)
Raw View
------=_Part_175_842176248.1468187534256
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yes, your understanding is correct to the best of my knowledge. It's mildly=
surprising, certainly; but C++ has plenty of mildly surprising corner case=
s. In mitigation, the syntax is different (no comma) so you can hardly say =
that it's the same code wrapped in a function call, and the code as written=
is somewhat artificial (why not use array directly with a braced-init-list=
via template argument deduction)?=20
For the benefit of those reading up on this for the first time, and who did=
not have the pleasure of participating in previous discussions on the topi=
c, there are several good reasons for preserving the current unspecified or=
dering. Among those I find most compelling are refactoring, optimization, =
backwards compatibility. Also, of course, with the ordering unspecified imp=
lementations are at liberty to fix on an LTR or RTL ordering, and there is =
nothing preventing a further version of the standard from making that chang=
e, but to do so now would be nearly irrevocable if it proved dissatisfactor=
y.
--=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/9f9be10e-ea35-4fc8-84c5-e71c770063dd%40isocpp.or=
g.
------=_Part_175_842176248.1468187534256--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 11 Jul 2016 12:17:08 -0400
Raw View
--94eb2c06fb2e1066bc05375e7dc1
Content-Type: text/plain; charset=UTF-8
The irrevocable wrong decision that was made was that in assignments, the
RHS is evaluated before the LHS.
On Sun, Jul 10, 2016 at 5:52 PM, Edward Catmur <ed@catmur.co.uk> wrote:
> Yes, your understanding is correct to the best of my knowledge. It's
> mildly surprising, certainly; but C++ has plenty of mildly surprising
> corner cases. In mitigation, the syntax is different (no comma) so you can
> hardly say that it's the same code wrapped in a function call, and the code
> as written is somewhat artificial (why not use array directly with a
> braced-init-list via template argument deduction)?
>
> For the benefit of those reading up on this for the first time, and who
> did not have the pleasure of participating in previous discussions on the
> topic, there are several good reasons for preserving the current
> unspecified ordering. Among those I find most compelling are refactoring,
> optimization, backwards compatibility. Also, of course, with the ordering
> unspecified implementations are at liberty to fix on an LTR or RTL
> ordering, and there is nothing preventing a further version of the standard
> from making that change, but to do so now would be nearly irrevocable if it
> proved dissatisfactory.
>
> --
> 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/9f9be10e-ea35-4fc8-84c5-e71c770063dd%40isocpp.org
> .
>
--
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/CAHSYqdbDY%2BvzsT2_J_1T82qHL8jUbRMqBBfrGj3p_w1ZRf_zDw%40mail.gmail.com.
--94eb2c06fb2e1066bc05375e7dc1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The irrevocable wrong decision that was made was that in a=
ssignments, the RHS is evaluated before the LHS.</div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 5:52 PM, Edwar=
d Catmur <span dir=3D"ltr"><<a href=3D"mailto:ed@catmur.co.uk" target=3D=
"_blank">ed@catmur.co.uk</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Yes, your understanding is correct to the best of my knowledge. It=
9;s mildly surprising, certainly; but C++ has plenty of mildly surprising c=
orner cases. In mitigation, the syntax is different (no comma) so you can h=
ardly say that it's the same code wrapped in a function call, and the c=
ode as written is somewhat artificial (why not use array directly with a br=
aced-init-list via template argument deduction)?<br>
<br>
For the benefit of those reading up on this for the first time, and who did=
not have the pleasure of participating in previous discussions on the topi=
c, there are several good reasons for preserving the current unspecified or=
dering. Among those I find most compelling are=C2=A0 refactoring, optimizat=
ion, backwards compatibility. Also, of course, with the ordering unspecifie=
d implementations are at liberty to fix on an LTR or RTL ordering, and ther=
e is nothing preventing a further version of the standard from making that =
change, but to do so now would be nearly irrevocable if it proved dissatisf=
actory.<br>
<span class=3D""><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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/9f9be10e-ea35-4fc8-84c5-e71c77=
0063dd%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/9f9be10e-ea35-4fc8-84c5-e71c770=
063dd%40isocpp.org</a>.<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" 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/CAHSYqdbDY%2BvzsT2_J_1T82qHL8jUbRMqBB=
frGj3p_w1ZRf_zDw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbDY%2Bvz=
sT2_J_1T82qHL8jUbRMqBBfrGj3p_w1ZRf_zDw%40mail.gmail.com</a>.<br />
--94eb2c06fb2e1066bc05375e7dc1--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 11 Jul 2016 12:16:22 -0700 (PDT)
Raw View
------=_Part_11584_681685767.1468264582967
Content-Type: multipart/alternative;
boundary="----=_Part_11585_979944610.1468264582967"
------=_Part_11585_979944610.1468264582967
Content-Type: text/plain; charset=UTF-8
On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>
> The irrevocable wrong decision that was made was that in assignments, the
> RHS is evaluated before the LHS.
>
Why do you consider that the wrong decision, and what would have been the
right decision?
--
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/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org.
------=_Part_11585_979944610.1468264582967
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen=
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">The ir=
revocable wrong decision that was made was that in assignments, the RHS is =
evaluated before the LHS.</div></blockquote><div><br></div><div>Why do you =
consider that the wrong decision, and what would have been the right decisi=
on?</div><div><br></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/e3c4df92-5e44-441b-8f06-e039623bb9a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9=
%40isocpp.org</a>.<br />
------=_Part_11585_979944610.1468264582967--
------=_Part_11584_681685767.1468264582967--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 11 Jul 2016 13:35:23 -0700 (PDT)
Raw View
------=_Part_737_1256956647.1468269323743
Content-Type: multipart/alternative;
boundary="----=_Part_738_262571410.1468269323743"
------=_Part_738_262571410.1468269323743
Content-Type: text/plain; charset=UTF-8
On Sunday, July 10, 2016 at 5:52:14 PM UTC-4, Edward Catmur wrote:
>
> Yes, your understanding is correct to the best of my knowledge. It's
> mildly surprising, certainly; but C++ has plenty of mildly surprising
> corner cases.
Yes. And the point of specifying the order of evaluation was to eliminate a
big one of those. And this doesn't.
Of course, the point of braced-init-lists was to eliminate
initialization-based corner cases too. But it didn't. And the point of
perfect forwarding was to eliminate forwarding-based corner cases. But it
didn't.
So I guess this one fits right in: evaluation order is perfectly
well-specified... except when it isn't.
> In mitigation, the syntax is different (no comma) so you can hardly say
> that it's the same code wrapped in a function call,
It is as far as the user is concerned. Capturing the return value of
expressions should not suddenly cause the code's behavior to change. Even
if you had to give it a different spelling to make it work right.
and the code as written is somewhat artificial (why not use array directly
> with a braced-init-list via template argument deduction)?
.... because that's not possible? Maybe I'm misunderstanding what you're
suggesting here. But I don't know of a way to turn a braced-init-list into
a std::array that involves template argument deduction.
Sure, you could do this:
auto inserts = array<vector<int>::iterator, sizeof...(args)>{v.insert(v.end
(), std::forward<Ts>(args))...}
But the whole point of `make_array` is that you don't have to specify the
type or the count of values; they can be deduced. Since `std::array` is an
aggregate, I see no way for it to deduce the number of arguments or their
types. Even the new constructor deduction scheme introduced in C++17 only
applies to actual constructors, and `array` doesn't have any.
--
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/93e469cf-a137-4305-aa99-d32d35d7e87b%40isocpp.org.
------=_Part_738_262571410.1468269323743
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 10, 2016 at 5:52:14 PM UTC-4, Edward Catmu=
r wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, your understandin=
g is correct to the best of my knowledge. It's mildly surprising, certa=
inly; but C++ has plenty of mildly surprising corner cases.</blockquote><di=
v><br>Yes. And the point of specifying the order of evaluation was to elimi=
nate a big one of those. And this doesn't.<br><br>Of course, the point =
of braced-init-lists was to eliminate initialization-based corner cases too=
.. But it didn't. And the point of perfect forwarding was to eliminate f=
orwarding-based corner cases. But it didn't.<br><br>So I guess this one=
fits right in: evaluation order is perfectly well-specified... except when=
it isn't.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
In mitigation, the syntax is different (no comma) so you can hardly say tha=
t it's the same code wrapped in a function call, </blockquote><div><br>=
It is as far as the user is concerned. Capturing the return value of expres=
sions should not suddenly cause the code's behavior to change. Even if =
you had to give it a different spelling to make it work right.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">and the code as written is so=
mewhat artificial (why not use array directly with a braced-init-list via t=
emplate argument deduction)?</blockquote><div><br>... because that's no=
t possible? Maybe I'm misunderstanding what you're suggesting here.=
But I don't know of a way to turn a braced-init-list into a std::array=
that involves template argument deduction.<br><br>Sure, you could do this:=
<br><br><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"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> inserts <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> array</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"=
color: #080;" class=3D"styled-by-prettify"><int></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">iterator</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">...(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">args</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">insert</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">forw=
ard</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">args</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">))...}</span></div></code></div>=
<br>But the whole point of `make_array` is that you don't have to speci=
fy the type or the count of values; they can be deduced. Since `std::array`=
is an aggregate, I see no way for it to deduce the number of arguments or =
their types. Even the new constructor deduction scheme introduced in C++17 =
only applies to actual constructors, and `array` doesn't have any.<br><=
/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/93e469cf-a137-4305-aa99-d32d35d7e87b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/93e469cf-a137-4305-aa99-d32d35d7e87b=
%40isocpp.org</a>.<br />
------=_Part_738_262571410.1468269323743--
------=_Part_737_1256956647.1468269323743--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 11 Jul 2016 16:35:53 -0400
Raw View
--001a114ab99c619ac60537621a7a
Content-Type: text/plain; charset=UTF-8
The right decision is strict left-to-right order of evaluation for all
expressions, with side-effects fully completed as they are evaluated.
The reason for defining order is to avoid code that "accidentally works" -
that is, code that has order dependencies such that its behavior is
undefined or unspecified, but happens to be built with a compiler whose
behavior matches the programmer's intent. Such code can mysteriously break
when built on a different platform, long after it was written and has
appeared to work correctly. We have personally encountered this situation
in our company.
The reason for choosing strict left-to-right order is that it's trivial to
explain, matches the order in which code is read, and matches other
languages such as Java.
The C++17 change is wrong in two parts.
First, it does not specify order of evaluation completely, so accidentally
working code will continue to be a problem. This can be fixed in a later
version of the standard.
Second, it specifies that in assignments, the RHS is evaluated before the
LHS (I believe because of a mistaken notion of what associativity means).
This makes the Standard irretrievably broken, because it becomes impossible
to specify the correct left-to-right behavior in the future.
On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <gregmmarr@gmail.com> wrote:
> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>>
>> The irrevocable wrong decision that was made was that in assignments, the
>> RHS is evaluated before the LHS.
>>
>
> Why do you consider that the wrong decision, and what would have been the
> right decision?
>
> --
> 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/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%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/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com.
--001a114ab99c619ac60537621a7a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The right decision is strict left-to-right order of evalua=
tion for all expressions, with side-effects fully completed as they are eva=
luated.<br><br>The reason for defining order is to avoid code that "ac=
cidentally works" - that is, code that has order dependencies such tha=
t its behavior is undefined or unspecified, but happens to be built with a =
compiler whose behavior matches the programmer's intent. Such code can =
mysteriously break when built on a different platform, long after it was wr=
itten and has appeared to work correctly. We have personally encountered th=
is situation in our company.<br><br>The reason for choosing strict left-to-=
right order is that it's trivial to explain, matches the order in which=
code is read, and matches other languages such as Java.<br><br>The C++17 c=
hange is wrong in two parts.<br><br>First, it does not specify order of eva=
luation completely, so accidentally working code will continue to be a prob=
lem.=C2=A0 This can be fixed in a later version of the standard.<br><br>Sec=
ond, it specifies that in assignments, the RHS is evaluated before the LHS =
(I believe because of a mistaken notion of what associativity means).=C2=A0=
This makes the Standard irretrievably broken, because it becomes impossibl=
e to specify the correct left-to-right behavior in the future.</div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 11, 2016 at =
3:16 PM, Greg Marr <span dir=3D"ltr"><<a href=3D"mailto:gregmmarr@gmail.=
com" target=3D"_blank">gregmmarr@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Monday, July 1=
1, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">The irrevocable wrong decision that was made =
was that in assignments, the RHS is evaluated before the LHS.</div></blockq=
uote><div><br></div></span><div>Why do you consider that the wrong decision=
, and what would have been the right decision?</div><div><br></div></div><s=
pan class=3D"">
<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" target=3D"_=
blank">std-proposals+unsubscribe@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/e3c4df92-5e44-441b-8f06-e039623bb9a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-=
441b-8f06-e039623bb9a9%40isocpp.org</a>.<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" 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/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25=
yFphPSz%3DS45ryQQu5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbW=
iH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com</a>.<br />
--001a114ab99c619ac60537621a7a--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 11 Jul 2016 14:16:41 -0700 (PDT)
Raw View
------=_Part_10006_718122902.1468271801965
Content-Type: multipart/alternative;
boundary="----=_Part_10007_2056315261.1468271801965"
------=_Part_10007_2056315261.1468271801965
Content-Type: text/plain; charset=UTF-8
On Monday, July 11, 2016 at 4:36:14 PM UTC-4, Hyman Rosen wrote:
>
> The right decision is strict left-to-right order of evaluation for all
> expressions, with side-effects fully completed as they are evaluated.
>
> The reason for defining order is to avoid code that "accidentally works" -
> that is, code that has order dependencies such that its behavior is
> undefined or unspecified, but happens to be built with a compiler whose
> behavior matches the programmer's intent. Such code can mysteriously break
> when built on a different platform, long after it was written and has
> appeared to work correctly. We have personally encountered this situation
> in our company.
>
> The reason for choosing strict left-to-right order is that it's trivial to
> explain, matches the order in which code is read, and matches other
> languages such as Java.
>
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so accidentally
> working code will continue to be a problem. This can be fixed in a later
> version of the standard.
>
> Second, it specifies that in assignments, the RHS is evaluated before the
> LHS (I believe because of a mistaken notion of what associativity means).
> This makes the Standard irretrievably broken, because it becomes impossible
> to specify the correct left-to-right behavior in the future.
>
I think saying that it's irrevocably *broken* is a bit hyperbolic.
Certainly, it cannot be changed. But even if the order is not what is
expected, it is still *some* order.
Also, the CD is not the final word on C++17. National body comments and so
forth can change things.
--
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/e1ed0611-174b-46bb-b2d6-37fd686c059c%40isocpp.org.
------=_Part_10007_2056315261.1468271801965
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 11, 2016 at 4:36:14 PM UTC-4, Hyman Rosen =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The rig=
ht decision is strict left-to-right order of evaluation for all expressions=
, with side-effects fully completed as they are evaluated.<br><br>The reaso=
n for defining order is to avoid code that "accidentally works" -=
that is, code that has order dependencies such that its behavior is undefi=
ned or unspecified, but happens to be built with a compiler whose behavior =
matches the programmer's intent. Such code can mysteriously break when =
built on a different platform, long after it was written and has appeared t=
o work correctly. We have personally encountered this situation in our comp=
any.<br><br>The reason for choosing strict left-to-right order is that it&#=
39;s trivial to explain, matches the order in which code is read, and match=
es other languages such as Java.<br><br>The C++17 change is wrong in two pa=
rts.<br><br>First, it does not specify order of evaluation completely, so a=
ccidentally working code will continue to be a problem.=C2=A0 This can be f=
ixed in a later version of the standard.<br><br>Second, it specifies that i=
n assignments, the RHS is evaluated before the LHS (I believe because of a =
mistaken notion of what associativity means).=C2=A0 This makes the Standard=
irretrievably broken, because it becomes impossible to specify the correct=
left-to-right behavior in the future.</div></blockquote><div><br>I think s=
aying that it's irrevocably <i>broken</i> is a bit hyperbolic. Certainl=
y, it cannot be changed. But even if the order is not what is expected, it =
is still <i>some</i> order.<br><br>Also, the CD is not the final word on C+=
+17. National body comments and so forth can change things.</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/e1ed0611-174b-46bb-b2d6-37fd686c059c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e1ed0611-174b-46bb-b2d6-37fd686c059c=
%40isocpp.org</a>.<br />
------=_Part_10007_2056315261.1468271801965--
------=_Part_10006_718122902.1468271801965--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 11 Jul 2016 14:22:16 -0700 (PDT)
Raw View
------=_Part_937_928856881.1468272137166
Content-Type: multipart/alternative;
boundary="----=_Part_938_696856627.1468272137166"
------=_Part_938_696856627.1468272137166
Content-Type: text/plain; charset=UTF-8
On Monday, July 11, 2016 at 4:36:14 PM UTC-4, Hyman Rosen wrote:
>
> The reason for defining order is to avoid code that "accidentally works" -
> that is, code that has order dependencies such that its behavior is
> undefined or unspecified, but happens to be built with a compiler whose
> behavior matches the programmer's intent. Such code can mysteriously break
> when built on a different platform, long after it was written and has
> appeared to work correctly. We have personally encountered this situation
> in our company.
>
Agree 100%.
> The right decision is strict left-to-right order of evaluation for all
> expressions, with side-effects fully completed as they are evaluated.
>
> The reason for choosing strict left-to-right order is that it's trivial to
> explain, matches the order in which code is read, and matches other
> languages such as Java.
>
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so accidentally
> working code will continue to be a problem. This can be fixed in a later
> version of the standard.
>
> Second, it specifies that in assignments, the RHS is evaluated before the
> LHS (I believe because of a mistaken notion of what associativity means).
> This makes the Standard irretrievably broken, because it becomes impossible
> to specify the correct left-to-right behavior in the future.
>
I agree with the first part, was only asking about the second part. Thanks
for the information.
I was actually thinking of something completely different than what came up
when I was looking things up based on your answer.
The reference I found was this:
int a[2] = {0, 1}
int b = 1;
a[b] = b = 0;
(adjust syntax as appropriate for language).
The question was whether this changes a[0] or a[1].
The best answer is, of course, "don't do that".
It seems that the answer to this is a[1] in Java and a[0] in Python.
What I was thing of was
a() = b() + c();
To me it made sense to order it like this:
auto temp_b = b();
auto temp_c = c();
auto temp_sum = temp_b + temp_c;
a() = temp_sum;
This is, I believe, based on how I might write this in english:
Compute b() and c(), add them together, and assign that value to a().
Are you suggesting this instead?
auto &&temp_a = a();
auto &&temp_b = b();
auto &&temp_c = c();
temp_a = temp_b + temp_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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/763c6a42-f05e-420e-8c38-06b922d03f06%40isocpp.org.
------=_Part_938_696856627.1468272137166
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 11, 2016 at 4:36:14 PM UTC-4, Hyman Rosen =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The rea=
son for defining order is to avoid code that "accidentally works"=
- that is, code that has order dependencies such that its behavior is unde=
fined or unspecified, but happens to be built with a compiler whose behavio=
r matches the programmer's intent. Such code can mysteriously break whe=
n built on a different platform, long after it was written and has appeared=
to work correctly. We have personally encountered this situation in our co=
mpany.<br></div></blockquote><div><br></div><div>Agree 100%.</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;"><div dir=3D"ltr">The =
right decision is strict left-to-right order of evaluation for all expressi=
ons, with side-effects fully completed as they are evaluated.<br><br>The re=
ason for choosing strict left-to-right order is that it's trivial to ex=
plain, matches the order in which code is read, and matches other languages=
such as Java.<br><br>The C++17 change is wrong in two parts.<br><br>First,=
it does not specify order of evaluation completely, so accidentally workin=
g code will continue to be a problem.=C2=A0 This can be fixed in a later ve=
rsion of the standard.<br><br>Second, it specifies that in assignments, the=
RHS is evaluated before the LHS (I believe because of a mistaken notion of=
what associativity means).=C2=A0 This makes the Standard irretrievably bro=
ken, because it becomes impossible to specify the correct left-to-right beh=
avior in the future.</div></blockquote><div><br></div><div>I agree with the=
first part, was only asking about the second part. =C2=A0Thanks for the in=
formation.</div><div><br></div><div>I was actually thinking of something co=
mpletely different than what came up when I was looking things up based on =
your answer.</div><div>The reference I found was this:</div><div><br></div>=
<div>int a[2] =3D {0, 1}</div><div>int b =3D 1;</div><div>a[b] =3D b =3D 0;=
</div><div><br></div><div>(adjust syntax as appropriate for language).</div=
><div><br></div><div>The question was whether this changes a[0] or a[1].</d=
iv><div>The best answer is, of course, "don't do that".</div>=
<div>It seems that the answer to this is a[1] in Java and a[0] in Python.</=
div><div><br></div><div>What I was thing of was</div><div><br></div><div>a(=
) =3D b() + c();</div><div><br></div><div>To me it made sense to order it l=
ike this:</div><div><br></div><div>auto temp_b =3D b();</div><div>auto temp=
_c =3D c();</div><div>auto temp_sum =3D temp_b + temp_c;</div><div>a() =3D =
temp_sum;</div><div><br></div><div>This is, I believe, based on how I might=
write this in english:</div><div>Compute b() and c(), add them together, a=
nd assign that value to a().</div><div><br></div><div>Are you suggesting th=
is instead?</div><div><br></div><div>auto &&temp_a =3D a();</div><d=
iv><div>auto &&temp_b =3D b();</div><div>auto &&temp_c =3D =
c();</div><div>temp_a =3D temp_b + temp_c;</div><div><br></div></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/763c6a42-f05e-420e-8c38-06b922d03f06%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/763c6a42-f05e-420e-8c38-06b922d03f06=
%40isocpp.org</a>.<br />
------=_Part_938_696856627.1468272137166--
------=_Part_937_928856881.1468272137166--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 11 Jul 2016 14:24:33 -0700 (PDT)
Raw View
------=_Part_810_1454260444.1468272273926
Content-Type: multipart/alternative;
boundary="----=_Part_811_1799243518.1468272273927"
------=_Part_811_1799243518.1468272273927
Content-Type: text/plain; charset=UTF-8
On Monday, July 11, 2016 at 5:22:17 PM UTC-4, Greg Marr wrote:
>
> What I was thing of was
>
What I was *thinking* of was
> To me it made sense to order it like this:
>
> auto temp_b = b();
> auto temp_c = c();
> auto temp_sum = temp_b + temp_c;
> a() = temp_sum;
>
> This is, I believe, based on how I might write this in english:
> Compute b() and c(), add them together, and assign that value to a().
>
> Are you suggesting this instead?
>
> auto &&temp_a = a();
> auto &&temp_b = b();
> auto &&temp_c = c();
> temp_a = temp_b + temp_c;
>
Ignore the differences between auto and auto && in those two examples.
--
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/839ae2a9-57f9-4a36-a60a-8bab6ddd6f67%40isocpp.org.
------=_Part_811_1799243518.1468272273927
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 11, 2016 at 5:22:17 PM UTC-4, Greg Marr wr=
ote:<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>What=
I was thing of was</div></div></blockquote><div><br></div><div>What I was =
*thinking* of was</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>To me it made sense to order it like this:<=
br></div><div><br></div><div>auto temp_b =3D b();</div><div>auto temp_c =3D=
c();</div><div>auto temp_sum =3D temp_b + temp_c;</div><div>a() =3D temp_s=
um;</div><div><br></div><div>This is, I believe, based on how I might write=
this in english:</div><div>Compute b() and c(), add them together, and ass=
ign that value to a().</div><div><br></div><div>Are you suggesting this ins=
tead?</div><div><br></div><div>auto &&temp_a =3D a();</div><div><di=
v>auto &&temp_b =3D b();</div><div>auto &&temp_c =3D c();</=
div><div>temp_a =3D temp_b + temp_c;</div></div></div></blockquote><div><br=
></div><div>Ignore the differences between auto and auto && in thos=
e two examples.</div><div><br></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/839ae2a9-57f9-4a36-a60a-8bab6ddd6f67%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/839ae2a9-57f9-4a36-a60a-8bab6ddd6f67=
%40isocpp.org</a>.<br />
------=_Part_811_1799243518.1468272273927--
------=_Part_810_1454260444.1468272273926--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 11 Jul 2016 15:04:12 -0700
Raw View
--001a11499a741f66e005376355c0
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 11, 2016 at 1:35 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> The right decision is strict left-to-right order of evaluation for all
> expressions, with side-effects fully completed as they are evaluated.
>
> The reason for defining order is to avoid code that "accidentally works" -
> that is, code that has order dependencies such that its behavior is
> undefined or unspecified, but happens to be built with a compiler whose
> behavior matches the programmer's intent. Such code can mysteriously break
> when built on a different platform, long after it was written and has
> appeared to work correctly. We have personally encountered this situation
> in our company.
>
> The reason for choosing strict left-to-right order is that it's trivial to
> explain, matches the order in which code is read, and matches other
> languages such as Java.
>
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so accidentally
> working code will continue to be a problem. This can be fixed in a later
> version of the standard.
>
> Second, it specifies that in assignments, the RHS is evaluated before the
> LHS (I believe because of a mistaken notion of what associativity means).
> This makes the Standard irretrievably broken, because it becomes impossible
> to specify the correct left-to-right behavior in the future.
>
As far as I recall, you're right that the choice to evaluate the RHS of an
assignment before the LHS was made in order to match the associativity
rules. This is not completely disconnected from order of evaluation; given:
a = b = c = d
.... the operator= calls are ordered from right to left, so there's at least
some symmetry in ordering the subexpressions from right to left also. (That
order also minimizes the amount of temporary state that must be retained
for an unparenthesized expression.)
That said, I do agree that this choice still seems a little arbitrary. But
I don't think it's necessarily outright wrong, as you claim.
On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <gregmmarr@gmail.com> wrote:
>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>>>
>>> The irrevocable wrong decision that was made was that in assignments,
>>> the RHS is evaluated before the LHS.
>>>
>>
>> Why do you consider that the wrong decision, and what would have been the
>> right decision?
>>
>> --
>> 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/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%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/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com?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/CAOfiQqm0m2pe6cTkG-1oPNyjLvKd_xTW08OYBkO-VH%3Dke%3DBUqA%40mail.gmail.com.
--001a11499a741f66e005376355c0
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 M=
on, Jul 11, 2016 at 1:35 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>>=
;</span> wrote:<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">The righ=
t decision is strict left-to-right order of evaluation for all expressions,=
with side-effects fully completed as they are evaluated.<br><br>The reason=
for defining order is to avoid code that "accidentally works" - =
that is, code that has order dependencies such that its behavior is undefin=
ed or unspecified, but happens to be built with a compiler whose behavior m=
atches the programmer's intent. Such code can mysteriously break when b=
uilt on a different platform, long after it was written and has appeared to=
work correctly. We have personally encountered this situation in our compa=
ny.<br><br>The reason for choosing strict left-to-right order is that it=
9;s trivial to explain, matches the order in which code is read, and matche=
s other languages such as Java.<br><br>The C++17 change is wrong in two par=
ts.<br><br>First, it does not specify order of evaluation completely, so ac=
cidentally working code will continue to be a problem.=C2=A0 This can be fi=
xed in a later version of the standard.<br><br>Second, it specifies that in=
assignments, the RHS is evaluated before the LHS (I believe because of a m=
istaken notion of what associativity means).=C2=A0 This makes the Standard =
irretrievably broken, because it becomes impossible to specify the correct =
left-to-right behavior in the future.</div></blockquote><div><br></div><div=
>As far as I recall, you're right that the choice to evaluate the RHS o=
f an assignment before the LHS was made in order to match the associativity=
rules. This is not completely disconnected from order of evaluation; given=
:</div><div><br></div><div>=C2=A0 a =3D b =3D c =3D d</div><div><br></div><=
div>... the operator=3D calls are ordered from right to left, so there'=
s at least some symmetry in ordering the subexpressions from right to left =
also. (That order also minimizes the amount of temporary state that must be=
retained for an unparenthesized expression.)</div><div><br></div><div>That=
said, I do agree that this choice still seems a little arbitrary. But I do=
n't think it's necessarily outright wrong, as you claim.</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Jul 11, 2016 at 3:16 PM=
, Greg Marr <span dir=3D"ltr"><<a href=3D"mailto:gregmmarr@gmail.com" ta=
rget=3D"_blank">gregmmarr@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><span>On Monday, July 11, 2016 at 12:17:3=
1 PM UTC-4, Hyman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">The irrevocable wrong decision that was made was that in assign=
ments, the RHS is evaluated before the LHS.</div></blockquote><div><br></di=
v></span><div>Why do you consider that the wrong decision, and what would h=
ave been the right decision?</div><div><br></div></div><span>
<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" target=3D"_=
blank">std-proposals+unsubscribe@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/e3c4df92-5e44-441b-8f06-e039623bb9a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-=
441b-8f06-e039623bb9a9%40isocpp.org</a>.<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" 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@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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25=
yFphPSz%3DS45ryQQu5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail=
..gmail.com</a>.<br>
</blockquote></div><br></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/CAOfiQqm0m2pe6cTkG-1oPNyjLvKd_xTW08OY=
BkO-VH%3Dke%3DBUqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm0m2pe=
6cTkG-1oPNyjLvKd_xTW08OYBkO-VH%3Dke%3DBUqA%40mail.gmail.com</a>.<br />
--001a11499a741f66e005376355c0--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 01:07:46 +0100
Raw View
--94eb2c0772a2fe0ec00537650eae
Content-Type: text/plain; charset=UTF-8
On 11 Jul 2016 9:35 p.m., "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> On Sunday, July 10, 2016 at 5:52:14 PM UTC-4, Edward Catmur wrote:
>>
>> In mitigation, the syntax is different (no comma) so you can hardly say
that it's the same code wrapped in a function call,
>
>
> It is as far as the user is concerned. Capturing the return value of
expressions should not suddenly cause the code's behavior to change. Even
if you had to give it a different spelling to make it work right.
If you don't understand the reason behind the different spelling you're
programming by permutation. Which is a fine enough technique but will bite
you sooner or later.
>> and the code as written is somewhat artificial (why not use array
directly with a braced-init-list via template argument deduction)?
>
>
> ... because that's not possible? Maybe I'm misunderstanding what you're
suggesting here. But I don't know of a way to turn a braced-init-list into
a std::array that involves template argument deduction.
>
> Sure, you could do this:
>
> auto inserts = array<vector<int>::iterator,
sizeof...(args)>{v.insert(v.end(), std::forward<Ts>(args))...}
>
> But the whole point of `make_array` is that you don't have to specify the
type or the count of values; they can be deduced. Since `std::array` is an
aggregate, I see no way for it to deduce the number of arguments or their
types. Even the new constructor deduction scheme introduced in C++17 only
applies to actual constructors, and `array` doesn't have any.
>
No, you're right, I was expecting that template deduction guides should
work for array. It's a pity if they won't.
--
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/CAJnLdObftG815_5P%3DnhGV-DoG9wencJdx25nn4CVevZ596YTRA%40mail.gmail.com.
--94eb2c0772a2fe0ec00537650eae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 11 Jul 2016 9:35 p.m., "Nicol Bolas" <<a href=3D"mailto:jmc=
kesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>
><br>
> On Sunday, July 10, 2016 at 5:52:14 PM UTC-4, Edward Catmur wrote:<br>
>><br>
>> In mitigation, the syntax is different (no comma) so you can hardl=
y say that it's the same code wrapped in a function call,<br>
><br>
><br>
> It is as far as the user is concerned. Capturing the return value of e=
xpressions should not suddenly cause the code's behavior to change. Eve=
n if you had to give it a different spelling to make it work right.</p>
<p dir=3D"ltr">If you don't understand the reason behind the different =
spelling you're programming by permutation. Which is a fine enough tech=
nique but will bite you sooner or later.</p>
<p dir=3D"ltr">>> and the code as written is somewhat artificial (why=
not use array directly with a braced-init-list via template argument deduc=
tion)?<br>
><br>
><br>
> ... because that's not possible? Maybe I'm misunderstanding wh=
at you're suggesting here. But I don't know of a way to turn a brac=
ed-init-list into a std::array that involves template argument deduction.<b=
r>
><br>
> Sure, you could do this:<br>
><br>
> auto inserts =3D array<vector<int>::iterator, sizeof...(args)=
>{v.insert(v.end(), std::forward<Ts>(args))...}<br>
><br>
> But the whole point of `make_array` is that you don't have to spec=
ify the type or the count of values; they can be deduced. Since `std::array=
` is an aggregate, I see no way for it to deduce the number of arguments or=
their types. Even the new constructor deduction scheme introduced in C++17=
only applies to actual constructors, and `array` doesn't have any.<br>
></p>
<p dir=3D"ltr">No, you're right, I was expecting that template deductio=
n guides should work for array. It's a pity if they won't. </p>
<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/CAJnLdObftG815_5P%3DnhGV-DoG9wencJdx2=
5nn4CVevZ596YTRA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObftG815_=
5P%3DnhGV-DoG9wencJdx25nn4CVevZ596YTRA%40mail.gmail.com</a>.<br />
--94eb2c0772a2fe0ec00537650eae--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 01:27:39 +0100
Raw View
--94eb2c124a041d376d0537655696
Content-Type: text/plain; charset=UTF-8
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all
expressions, with side-effects fully completed as they are evaluated.
That sounds like a performance nightmare.
> The reason for defining order is to avoid code that "accidentally works"
- that is, code that has order dependencies such that its behavior is
undefined or unspecified, but happens to be built with a compiler whose
behavior matches the programmer's intent. Such code can mysteriously break
when built on a different platform, long after it was written and has
appeared to work correctly. We have personally encountered this situation
in our company.
There will always be implementation variance especially between platforms.
A blanket statement that it is always bad ignores the multitude of reasons
to permit and encourage implementation variance. And of course the
implementation variance already exists, so you won't be able to change the
behavior of existing platforms.
> The reason for choosing strict left-to-right order is that it's trivial
to explain, matches the order in which code is read, and matches other
languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient
reader of natural languages reads sentences and paragraphs in a single
glance.
And is making C++ more similar to Java supposed to be a *good* thing?
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so
accidentally working code will continue to be a problem. This can be fixed
in a later version of the standard.
>
> Second, it specifies that in assignments, the RHS is evaluated before the
LHS (I believe because of a mistaken notion of what associativity means).
This makes the Standard irretrievably broken, because it becomes impossible
to specify the correct left-to-right behavior in the future.
Quite.
> On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <gregmmarr@gmail.com> wrote:
>>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>>>
>>> The irrevocable wrong decision that was made was that in assignments,
the RHS is evaluated before the LHS.
>>
>>
>> Why do you consider that the wrong decision, and what would have been
the right decision?
>>
>> --
>> 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/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org
..
>
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/unsubscribe
..
> To unsubscribe from this group and all its topics, 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/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com
..
--
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/CAJnLdOaZS2B456QigQK6%2BPXQzOvGB9Kfr1%2Btz3zN-5ni0vZEbw%40mail.gmail.com.
--94eb2c124a041d376d0537655696
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a href=3D"mailto:hym=
an.rosen@gmail.com">hyman.rosen@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare. </p>
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms. </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance. </p>
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing? </p>
<p dir=3D"ltr">> The C++17 change is wrong in two parts.<br>
><br>
> First, it does not specify order of evaluation completely, so accident=
ally working code will continue to be a problem.=C2=A0 This can be fixed in=
a later version of the standard.<br>
><br>
> Second, it specifies that in assignments, the RHS is evaluated before =
the LHS (I believe because of a mistaken notion of what associativity means=
).=C2=A0 This makes the Standard irretrievably broken, because it becomes i=
mpossible to specify the correct left-to-right behavior in the future.</p>
<p dir=3D"ltr">Quite. </p>
<p dir=3D"ltr">> On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <<a href=
=3D"mailto:gregmmarr@gmail.com">gregmmarr@gmail.com</a>> wrote:<br>
>><br>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:<=
br>
>>><br>
>>> The irrevocable wrong decision that was made was that in assig=
nments, the RHS is evaluated before the LHS.<br>
>><br>
>><br>
>> Why do you consider that the wrong decision, and what would have b=
een the right decision?<br>
>><br>
>> -- <br>
>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br>
>><br>
>> To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039=
623bb9a9%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org</a>.<br>
><br>
><br>
> -- <br>
> You received this message because you are subscribed to a topic in the=
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/unsubscribe<=
/a>.<br>
> To unsubscribe from this group and all its topics, send an email to <a=
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsub=
scribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJ=
TCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%=
3DS45ryQQu5A%40mail.gmail.com</a>.<br>
</p>
<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/CAJnLdOaZS2B456QigQK6%2BPXQzOvGB9Kfr1=
%2Btz3zN-5ni0vZEbw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaZS2B4=
56QigQK6%2BPXQzOvGB9Kfr1%2Btz3zN-5ni0vZEbw%40mail.gmail.com</a>.<br />
--94eb2c124a041d376d0537655696--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 11 Jul 2016 17:27:46 -0700
Raw View
--94eb2c063e9eb1b70505376557b6
Content-Type: text/plain; charset=UTF-8
On Sat, Jul 9, 2016 at 11:00 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> C++17's CD has apparently voted in the expression evaluation order
> proposal, but as I understand it, they used the "Alternate Evaluation Order
> for Function Calls" That says:
>
> the expression in the function position is evaluated before all the
>> arguments and the evaluations of the arguments are indeterminately
>> sequenced, but with no interleaving.
>>
>
> So, I want to make sure I understand something.
>
> This has well defined behavior:
>
> template<typename Ts...>
> void func(Ts&&... args)
> {
> vector<int> v;
> v.reserve(sizeof...(Ts));
>
> (v.insert(v.end(), std::forward<Ts>(args)), ...);
> }
>
> This will insert to the end of `v` every element in `args`, in the order
> of the arguments passed to `func`.
>
> But this will not:
>
> template<typename Ts...>
> void func(Ts&&... args)
> {
> vector<int> v;
> v.reserve(sizeof...(Ts));
>
> auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args
> ))...);
> }
>
> So, by the mere act of calling a function on the return values, the state
> of `v` is unspecified.
>
I don't expect this to convince you, but note that "calling a function on
the return value" of the (v.insert(v.end(), std::forward<Ts>(args)), ...)
expression would look like:
make_array((v.insert(v.end(), std::forward<Ts>(args))...));
which will continue to evaluate in order, but of course won't give an array
of the results of the insert() calls.
> Now, the new sequencing rules will at least ensure that this code results
> in a valid `v`. That is, each `v.end` will be called, followed by its
> corresponding `v.insert`. There won't be any interleaving, so `v` will have
> actual data in it in some order. And the returned iterators will all be
> equally valid.
>
> But there also won't be a guaranteed order. All because it was wrapped in
> a function call.
>
> Is my understanding of things correct? Would people not consider this
> highly surprising behavior?
>
It's definitely surprising that different uses of commas behave
differently, but it may be necessarily surprising. I think we don't *know*
that the surprise is necessary yet, but there wasn't enough confidence to
lock in the change. We made it somewhat better in the C++17 CD, but it's
certainly not perfect. Hopefully we'll get papers proposing and justifying
further improvements for C++20.
Jeffrey
--
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/CANh-dX%3Dja5yDM7miR1RsELpet7zvcrP4mVoiBiUuJovugAuE6g%40mail.gmail.com.
--94eb2c063e9eb1b70505376557b6
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 S=
at, Jul 9, 2016 at 11:00 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank" class=3D"gmail-cremed gmail-cr=
emed cremed">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">C++17's CD has appare=
ntly voted in the expression evaluation order proposal, but as I understand=
it, they used the "Alternate Evaluation Order for Function Calls"=
; That says:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">the e=
xpression in the function position is evaluated before all the arguments an=
d the evaluations of the arguments are indeterminately sequenced, but with =
no interleaving.<br></blockquote><br>So, I want to make sure I understand s=
omething.<br><br>This has well defined behavior:<br><br><div style=3D"borde=
r:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,=
250,250)"><code><div><span style=3D"color:rgb(0,0,136)">template</span><spa=
n style=3D"color:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,13=
6)">typename</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"=
color:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102,0)">...>=
</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb=
(0,0,136)">void</span><span style=3D"color:rgb(0,0,0)"> func</span><span st=
yle=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(102,0,102)">T=
s</span><span style=3D"color:rgb(102,102,0)">&&...</span><span styl=
e=3D"color:rgb(0,0,0)"> args</span><span style=3D"color:rgb(102,102,0)">)</=
span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(1=
02,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 vecto=
r</span><span style=3D"color:rgb(0,136,0)"><int></span><span style=3D=
"color:rgb(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">;</span><s=
pan style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 v</span><span style=3D"col=
or:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">reserve</span><=
span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,13=
6)">sizeof</span><span style=3D"color:rgb(102,102,0)">...(</span><span styl=
e=3D"color:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102,0)">))=
;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"colo=
r:rgb(0,0,0)">v</span><span style=3D"color:rgb(102,102,0)">.</span><span st=
yle=3D"color:rgb(0,0,0)">insert</span><span style=3D"color:rgb(102,102,0)">=
(</span><span style=3D"color:rgb(0,0,0)">v</span><span style=3D"color:rgb(1=
02,102,0)">.</span><span style=3D"color:rgb(0,0,136)">end</span><span style=
=3D"color:rgb(102,102,0)">(),</span><span style=3D"color:rgb(0,0,0)"> std</=
span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb=
(0,0,0)">forward</span><span style=3D"color:rgb(102,102,0)"><</span><spa=
n style=3D"color:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102,=
0)">>(</span><span style=3D"color:rgb(0,0,0)">args</span><span style=3D"=
color:rgb(102,102,0)">)),</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(102,102,0)">...);</span><span style=3D"color:rgb(0,0=
,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code><=
/div><br>This will insert to the end of `v` every element in `args`, in the=
order of the arguments passed to `func`.<br><br>But this will not:<br><br>=
<div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgr=
ound-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">=
template</span><span style=3D"color:rgb(102,102,0)"><</span><span style=
=3D"color:rgb(0,0,136)">typename</span><span style=3D"color:rgb(0,0,0)"> </=
span><span style=3D"color:rgb(102,0,102)">Ts</span><span style=3D"color:rgb=
(102,102,0)">...></span><span style=3D"color:rgb(0,0,0)"><br></span><spa=
n style=3D"color:rgb(0,0,136)">void</span><span style=3D"color:rgb(0,0,0)">=
func</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"col=
or:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102,0)">&&=
....</span><span style=3D"color:rgb(0,0,0)"> args</span><span style=3D"color=
:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span =
style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br=
>=C2=A0 =C2=A0 vector</span><span style=3D"color:rgb(0,136,0)"><int><=
/span><span style=3D"color:rgb(0,0,0)"> v</span><span style=3D"color:rgb(10=
2,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 v</spa=
n><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0=
,0)">reserve</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,136)">sizeof</span><span style=3D"color:rgb(102,102,0)">.=
...(</span><span style=3D"color:rgb(102,0,102)">Ts</span><span style=3D"colo=
r:rgb(102,102,0)">));</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">auto</span>=
<span style=3D"color:rgb(0,0,0)"> inserts </span><span style=3D"color:rgb(1=
02,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> make_array</span><sp=
an style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">=
v</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:r=
gb(0,0,0)">insert</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)">v</span><span style=3D"color:rgb(102,102,0)">.</=
span><span style=3D"color:rgb(0,0,136)">end</span><span style=3D"color:rgb(=
102,102,0)">(),</span><span style=3D"color:rgb(0,0,0)"> std</span><span sty=
le=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">forwa=
rd</span><span style=3D"color:rgb(102,102,0)"><</span><span style=3D"col=
or:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102,0)">>(</spa=
n><span style=3D"color:rgb(0,0,0)">args</span><span style=3D"color:rgb(102,=
102,0)">))...);</span><span style=3D"color:rgb(0,0,0)"><br></span><span sty=
le=3D"color:rgb(102,102,0)">}</span></div></code></div><br>So, by the mere =
act of calling a function on the return values, the state of `v` is unspeci=
fied.<br></div></blockquote><div><br></div><div>I don't expect this to =
convince you, but note that "calling a function on the return value&qu=
ot; of the (v.insert(v.end(), std::forward<Ts>(args)), ...) expressio=
n would look like:<br></div><div><br></div><div>make_array((v.insert(v.end(=
), std::forward<Ts>(args))...));<br></div><div><br></div><div>which w=
ill continue to evaluate in order, but of course won't give an array of=
the results of the insert() calls.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Now, the new sequencing r=
ules will at least ensure that this code results in a valid `v`. That is, e=
ach `v.end` will be called, followed by its corresponding `v.insert`. There=
won't be any interleaving, so `v` will have actual data in it in some =
order. And the returned iterators will all be equally valid.<br><br>But the=
re also won't be a guaranteed order. All because it was wrapped in a fu=
nction call.<br><br>Is my understanding of things correct? Would people not=
consider this highly surprising behavior?</div></blockquote><div></div></d=
iv><br></div><div class=3D"gmail_extra">It's definitely surprising that=
different uses of commas behave differently, but it may be necessarily sur=
prising. I think we don't *know* that the surprise is necessary yet, bu=
t there wasn't enough confidence to lock in the change. We made it some=
what better in the C++17 CD, but it's certainly not perfect. Hopefully =
we'll get papers proposing and justifying further improvements for C++2=
0.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jef=
frey</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/CANh-dX%3Dja5yDM7miR1RsELpet7zvcrP4mV=
oiBiUuJovugAuE6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3Dja5yD=
M7miR1RsELpet7zvcrP4mVoiBiUuJovugAuE6g%40mail.gmail.com</a>.<br />
--94eb2c063e9eb1b70505376557b6--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 11 Jul 2016 18:57:54 -0700 (PDT)
Raw View
------=_Part_7178_256737298.1468288674277
Content-Type: multipart/alternative;
boundary="----=_Part_7179_1392443809.1468288674277"
------=_Part_7179_1392443809.1468288674277
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=884:36:14=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> The right decision is strict left-to-right order of evaluation for all=20
> expressions, with side-effects fully completed as they are evaluated.
>
> The reason for defining order is to avoid code that "accidentally works" =
-=20
> that is, code that has order dependencies such that its behavior is=20
> undefined or unspecified, but happens to be built with a compiler whose=
=20
> behavior matches the programmer's intent. Such code can mysteriously brea=
k=20
> when built on a different platform, long after it was written and has=20
> appeared to work correctly. We have personally encountered this situation=
=20
> in our company.
>
> The reason for choosing strict left-to-right order is that it's trivial t=
o=20
> explain, matches the order in which code is read, and matches other=20
> languages such as Java.
>
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so accidentall=
y=20
> working code will continue to be a problem. This can be fixed in a later=
=20
> version of the standard.
>
> Second, it specifies that in assignments, the RHS is evaluated before the=
=20
> LHS (I believe because of a mistaken notion of what associativity means).=
=20
> This makes the Standard irretrievably broken, because it becomes impossib=
le=20
> to specify the correct left-to-right behavior in the future.
>
> Stop rumor on "correct" evaluation order. Left-to-right can not always th=
e=20
"correct" one. In fact, for assignment, it can be very unintuitive if you=
=20
force people to determine the value of left operand before the value of=20
right operand. In most cases the right operand need more complicated=20
computation. This will raise problems when evaluating the assignment=20
expression in human brains. It is stupid to always remember the result of=
=20
evaluation of left operand before evaluation of right operand, so people *s=
hould=20
*have the freedom to evaluate the right operand first. So, unless changing=
=20
the semantics of assignment expressions (or simply enforcing a different=20
operand order of assignment, like Intel -> AT&T assembly syntax), your=20
claim is not valid.
=20
> On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <greg...@gmail.com=20
> <javascript:>> wrote:
>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>>>
>>> The irrevocable wrong decision that was made was that in assignments,=
=20
>>> the RHS is evaluated before the LHS.
>>>
>>
>> Why do you consider that the wrong decision, and what would have been th=
e=20
>> right decision?
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e=
44-441b-8f06-e039623bb9a9%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5=
e44-441b-8f06-e039623bb9a9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/ab903fb6-2477-4d06-987d-51a320799dc0%40isocpp.or=
g.
------=_Part_7179_1392443809.1468288674277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=884:36:14=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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">The right decision is strict left-to-right order of evaluation f=
or all expressions, with side-effects fully completed as they are evaluated=
..<br><br>The reason for defining order is to avoid code that "accident=
ally works" - that is, code that has order dependencies such that its =
behavior is undefined or unspecified, but happens to be built with a compil=
er whose behavior matches the programmer's intent. Such code can myster=
iously break when built on a different platform, long after it was written =
and has appeared to work correctly. We have personally encountered this sit=
uation in our company.<br><br>The reason for choosing strict left-to-right =
order is that it's trivial to explain, matches the order in which code =
is read, and matches other languages such as Java.<br><br>The C++17 change =
is wrong in two parts.<br><br>First, it does not specify order of evaluatio=
n completely, so accidentally working code will continue to be a problem.=
=C2=A0 This can be fixed in a later version of the standard.<br><br>Second,=
it specifies that in assignments, the RHS is evaluated before the LHS (I b=
elieve because of a mistaken notion of what associativity means).=C2=A0 Thi=
s makes the Standard irretrievably broken, because it becomes impossible to=
specify the correct left-to-right behavior in the future.</div><div><br></=
div></blockquote><div>Stop rumor on "correct" evaluation order. L=
eft-to-right can not always the "correct" one. In fact, for assig=
nment, it can be very unintuitive if you force people to determine the valu=
e of left operand before the value of right operand. In most cases the righ=
t operand need more complicated computation. This will raise problems when =
evaluating the assignment expression in human brains. It is stupid to alway=
s remember the result of evaluation of left operand before evaluation of ri=
ght operand, so people <i>should </i>have the freedom to evaluate the right=
operand first. So, unless changing the semantics of assignment expressions=
(or simply enforcing a different operand order of assignment, like Intel -=
> AT&T assembly syntax), your claim is not valid.<br><br>=C2=A0 <br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail=
_quote">On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2fPk2CZxCg=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">greg...=
@gmail.com</a>></span> wrote:<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"><span>On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen w=
rote:<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">The irrevocab=
le wrong decision that was made was that in assignments, the RHS is evaluat=
ed before the LHS.</div></blockquote><div><br></div></span><div>Why do you =
consider that the wrong decision, and what would have been the right decisi=
on?</div><div><br></div></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2fPk2CZxCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"2fPk2CZxCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/e3c4df92-5e44-441b-8f06-e039623bb9a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e3c4df92-5e44-441b-<wbr>8f06-=
e039623bb9a9%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></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/ab903fb6-2477-4d06-987d-51a320799dc0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab903fb6-2477-4d06-987d-51a320799dc0=
%40isocpp.org</a>.<br />
------=_Part_7179_1392443809.1468288674277--
------=_Part_7178_256737298.1468288674277--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 11 Jul 2016 19:42:09 -0700 (PDT)
Raw View
------=_Part_1443_305724366.1468291329932
Content-Type: multipart/alternative;
boundary="----=_Part_1444_125634023.1468291329932"
------=_Part_1444_125634023.1468291329932
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=884:36:14=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> The right decision is strict left-to-right order of evaluation for all=20
> expressions, with side-effects fully completed as they are evaluated.
>
> The reason for defining order is to avoid code that "accidentally works" =
-=20
> that is, code that has order dependencies such that its behavior is=20
> undefined or unspecified, but happens to be built with a compiler whose=
=20
> behavior matches the programmer's intent. Such code can mysteriously brea=
k=20
> when built on a different platform, long after it was written and has=20
> appeared to work correctly. We have personally encountered this situation=
=20
> in our company.
>
> On the contrary, defined order keeps the code "accidentally works" truly=
=20
"accidentally" works, with far less opportunity to be found earlier. It can=
=20
hide bugs that cannot be automatically detected by the implementation=20
easily, i.e. due to lack of consideration on which evaluation order (if=20
any) is really needed, which is almost impossible known by the compiler or=
=20
code checker. For example, "a =3D b =3D c;" is strictly less clearer than "=
a =3D=20
c; b =3Dc;" when both of them "accidentally works". The reason of=20
"accidentally works" is they are accidentally semantically equivalent=20
according to the language rules, not by nature/some magic power. If there=
=20
is volatile-qualified variables involved, it can be fatal to think they are=
=20
still equivalent.
You have not *fixed *the real bugs. You only *workaround *the seen risks.=
=20
You are hard to foresee other risks. You can't guarantee it will never make=
=20
some other bugs more subtle to fix. You can measure and ensure it is=20
feasible for you or your company, but not for others. So this is hardly a=
=20
way worth encouraging in general.
=20
> The reason for choosing strict left-to-right order is that it's trivial t=
o=20
> explain, matches the order in which code is read, and matches other=20
> languages such as Java.
>
> Why should code be read left-to-right? They are usually only *parsed *lef=
t-to-right.=20
As of "trivial"... are you assuming there can be only one "correct" way to=
=20
process the text in others' brains?
And why C++ should matches Java? Further, note Java Language Specification=
=20
is clearly against the naive assumption on left-to-right order. Is it=20
"trivial"?
=20
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so accidentall=
y=20
> working code will continue to be a problem. This can be fixed in a later=
=20
> version of the standard.
>
> To forbid user leaving the order *intentionally unspecified* is a real=20
bug because it makes portability on the opposite of expressiveness (which=
=20
implies maintainability and performance, etc).
=20
> Second, it specifies that in assignments, the RHS is evaluated before the=
=20
> LHS (I believe because of a mistaken notion of what associativity means).=
=20
> This makes the Standard irretrievably broken, because it becomes impossib=
le=20
> to specify the correct left-to-right behavior in the future.
>
> On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <greg...@gmail.com=20
> <javascript:>> wrote:
>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>>>
>>> The irrevocable wrong decision that was made was that in assignments,=
=20
>>> the RHS is evaluated before the LHS.
>>>
>>
>> Why do you consider that the wrong decision, and what would have been th=
e=20
>> right decision?
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e=
44-441b-8f06-e039623bb9a9%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5=
e44-441b-8f06-e039623bb9a9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/4acd9e7c-9e5a-4e60-8072-c81471f89861%40isocpp.or=
g.
------=_Part_1444_125634023.1468291329932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=884:36:14=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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">The right decision is strict left-to-right order of evaluation f=
or all expressions, with side-effects fully completed as they are evaluated=
..<br><br>The reason for defining order is to avoid code that "accident=
ally works" - that is, code that has order dependencies such that its =
behavior is undefined or unspecified, but happens to be built with a compil=
er whose behavior matches the programmer's intent. Such code can myster=
iously break when built on a different platform, long after it was written =
and has appeared to work correctly. We have personally encountered this sit=
uation in our company.<br><br></div></blockquote><div>On the contrary, defi=
ned order keeps the code "accidentally works" truly "acciden=
tally" works, with far less opportunity to be found earlier. It can hi=
de bugs that cannot be automatically detected by the implementation easily,=
i.e. due to lack of consideration on which evaluation order (if any) is re=
ally needed, which is almost impossible known by the compiler or code check=
er. For example, "a =3D b =3D c;" is strictly less clearer than &=
quot;a =3D c; b =3Dc;" when both of them "accidentally works"=
;. The reason of "accidentally works" is they are accidentally se=
mantically equivalent according to the language rules, not by nature/some m=
agic power. If there is volatile-qualified variables involved, it can be fa=
tal to think they are still equivalent.<br><br>You have not <i>fixed </i>th=
e real bugs. You only <i>workaround </i>the seen risks. You are hard to for=
esee other risks. You can't guarantee it will never make some other bug=
s more subtle to fix. You can measure and ensure it is feasible for you or =
your company, but not for others. So this is hardly a way worth encouraging=
in general.<br>=C2=A0<br></div><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">The reason for choosing strict left-to-right order is th=
at it's trivial to explain, matches the order in which code is read, an=
d matches other languages such as Java.<br><br></div></blockquote><div>Why =
should code be read left-to-right? They are usually only <i>parsed </i>left=
-to-right. As of "trivial"... are you assuming there can be only =
one "correct" way to process the text in others' brains?<br><=
br>And why C++ should matches Java? Further, note Java Language Specificati=
on is clearly against the naive assumption on left-to-right order. Is it &q=
uot;trivial"?<br>=C2=A0</div><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">The C++17 change is wrong in two parts.<br><br>First=
, it does not specify order of evaluation completely, so accidentally worki=
ng code will continue to be a problem.=C2=A0 This can be fixed in a later v=
ersion of the standard.<br><br></div></blockquote><div>To forbid user leavi=
ng the order <i>intentionally unspecified</i> is a real bug because it make=
s portability on the opposite of expressiveness (which implies maintainabil=
ity and performance, etc).<br>=C2=A0<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">Second, it specifies that in assignments, =
the RHS is evaluated before the LHS (I believe because of a mistaken notion=
of what associativity means).=C2=A0 This makes the Standard irretrievably =
broken, because it becomes impossible to specify the correct left-to-right =
behavior in the future.</div><div><br><div class=3D"gmail_quote">On Mon, Ju=
l 11, 2016 at 3:16 PM, Greg Marr <span dir=3D"ltr"><<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"2fPk2CZxCgAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">greg...@gmail.com</a>&g=
t;</span> wrote:<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"><span>O=
n Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen 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">The irrevocable wrong decisio=
n that was made was that in assignments, the RHS is evaluated before the LH=
S.</div></blockquote><div><br></div></span><div>Why do you consider that th=
e wrong decision, and what would have been the right decision?</div><div><b=
r></div></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2fPk2CZxCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"2fPk2CZxCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/e3c4df92-5e44-441b-8f06-e039623bb9a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e3c4df92-5e44-441b-<wbr>8f06-=
e039623bb9a9%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></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/4acd9e7c-9e5a-4e60-8072-c81471f89861%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4acd9e7c-9e5a-4e60-8072-c81471f89861=
%40isocpp.org</a>.<br />
------=_Part_1444_125634023.1468291329932--
------=_Part_1443_305724366.1468291329932--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 11 Jul 2016 19:46:43 -0700 (PDT)
Raw View
------=_Part_1293_185616764.1468291603432
Content-Type: multipart/alternative;
boundary="----=_Part_1294_629861312.1468291603432"
------=_Part_1294_629861312.1468291603432
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com <javascript:>=
>=20
> wrote:
> >
> > The right decision is strict left-to-right order of evaluation for all=
=20
> expressions, with side-effects fully completed as they are evaluated.
>
> That sounds like a performance nightmare.=20
>
This can be resolved by introducing some specific primitives to specify the=
=20
evaluation order not obeying this rule. However, they will be lengthy and=
=20
users will be reluctant to use them. Users will have excuse granted by the=
=20
default rule.
The true harm of such decision is, it encourages stupidity and laziness as=
=20
the default case. Freedom of expressiveness is defeated by freedom of lack=
=20
of consideration. This is offensive to people who want to write the "more=
=20
correct" (more precise, easier to read, easier to maintain) - not merely=20
"runnable" code: it makes they harder to achieve their goals while giving=
=20
them nothing.
=20
> > The reason for defining order is to avoid code that "accidentally works=
"=20
> - that is, code that has order dependencies such that its behavior is=20
> undefined or unspecified, but happens to be built with a compiler whose=
=20
> behavior matches the programmer's intent. Such code can mysteriously brea=
k=20
> when built on a different platform, long after it was written and has=20
> appeared to work correctly. We have personally encountered this situation=
=20
> in our company.
>
> There will always be implementation variance especially between platforms=
..=20
> A blanket statement that it is always bad ignores the multitude of reason=
s=20
> to permit and encourage implementation variance. And of course the=20
> implementation variance already exists, so you won't be able to change th=
e=20
> behavior of existing platforms.=20
>
> > The reason for choosing strict left-to-right order is that it's trivial=
=20
> to explain, matches the order in which code is read, and matches other=20
> languages such as Java.
>
> Any experienced user reads code blocks as a unit, just as any proficient=
=20
> reader of natural languages reads sentences and paragraphs in a single=20
> glance.=20
>
Yes. This is exactly my experience, and not only to C++. If a user can only=
=20
work under a single strict order with some sequenced materials, I doubt=20
his/her brain is damaged. Moreover, assuming left-to-right to be the=20
natural order may be offensive to people who are using natural languages=20
with right-to-left natural layout.
=20
> And is making C++ more similar to Java supposed to be a *good* thing?=20
>
And I can imagine making C++ less similar to C here has more impact in=20
reality.
=20
> > The C++17 change is wrong in two parts.
> >
> > First, it does not specify order of evaluation completely, so=20
> accidentally working code will continue to be a problem. This can be fix=
ed=20
> in a later version of the standard.
> >
> > Second, it specifies that in assignments, the RHS is evaluated before=
=20
> the LHS (I believe because of a mistaken notion of what associativity=20
> means). This makes the Standard irretrievably broken, because it becomes=
=20
> impossible to specify the correct left-to-right behavior in the future.
>
> Quite.=20
>
> > On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <greg...@gmail.com=20
> <javascript:>> wrote:
> >>
> >> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
> >>>
> >>> The irrevocable wrong decision that was made was that in assignments,=
=20
> the RHS is evaluated before the LHS.
> >>
> >>
> >> Why do you consider that the wrong decision, and what would have been=
=20
> the right decision?
> >>
> >> --=20
> >> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> >> To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> >>
> >> To post to this group, send email to std-pr...@isocpp.org <javascript:=
>
> .
> >> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e4=
4-441b-8f06-e039623bb9a9%40isocpp.org
> .
> >
> >
> > --=20
> > You received this message because you are subscribed to a topic in the=
=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/=
unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email to=20
> std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWi=
H%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com
> .
>
--=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/cdcda1c6-c10a-4beb-8490-fbdd3303f15d%40isocpp.or=
g.
------=_Part_1294_629861312.1468291603432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p =
dir=3D"ltr"><br>
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"bI_u-Md9CgAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">hyman...@gmail.com</a>>=
wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare. </p></blockquote><=
div><br>This can be resolved by introducing some specific primitives to spe=
cify the evaluation order not obeying this rule. However, they will be leng=
thy and users will be reluctant to use them. Users will have excuse granted=
by the default rule.<br><br>The true harm of such decision is, it encourag=
es stupidity and laziness as the default case. Freedom of expressiveness is=
defeated by freedom of lack of consideration. This is offensive to people =
who want to write the "more correct" (more precise, easier to rea=
d, easier to maintain) - not merely "runnable" code: it makes the=
y harder to achieve their goals while giving them nothing.<br>=C2=A0 <br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms. </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance. </p></blockquote><div><br>Yes. This is exactly my experien=
ce, and not only to C++. If a user can only work under a single strict orde=
r with some sequenced materials, I doubt his/her brain is damaged. Moreover=
, assuming left-to-right to be the natural order may be offensive to people=
who are using natural languages with right-to-left natural layout.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing? </p></blockquote><div><br>And I can imagine making C++ less simil=
ar to C here has more impact in reality.<br>=C2=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">> The C++17 change is wrong in two parts.<br>
><br>
> First, it does not specify order of evaluation completely, so accident=
ally working code will continue to be a problem.=C2=A0 This can be fixed in=
a later version of the standard.<br>
><br>
> Second, it specifies that in assignments, the RHS is evaluated before =
the LHS (I believe because of a mistaken notion of what associativity means=
).=C2=A0 This makes the Standard irretrievably broken, because it becomes i=
mpossible to specify the correct left-to-right behavior in the future.</p>
<p dir=3D"ltr">Quite. </p>
<p dir=3D"ltr">> On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"bI_u-Md9CgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">greg...@gmai=
l.com</a>> wrote:<br>
>><br>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:<=
br>
>>><br>
>>> The irrevocable wrong decision that was made was that in assig=
nments, the RHS is evaluated before the LHS.<br>
>><br>
>><br>
>> Why do you consider that the wrong decision, and what would have b=
een the right decision?<br>
>><br>
>> -- <br>
>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"bI_u-Md9CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.<br>
>><br>
>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"bI_u-Md9CgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039=
623bb9a9%40isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org';return true;" oncli=
ck=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org';return true=
;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e=
3c4df92-5e44-441b-<wbr>8f06-e039623bb9a9%40isocpp.org</a><wbr>.<br>
><br>
><br>
> -- <br>
> You received this message because you are subscribed to a topic in the=
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/unsubscribe" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.goo=
gle.com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/unsubscribe';ret=
urn true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.o=
rg/d/topic/std-proposals/wahN6MBQt68/unsubscribe';return true;">https:/=
/groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/wahN6MBQt68=
/<wbr>unsubscribe</a>.<br>
> To unsubscribe from this group and all its topics, send an email to <a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"bI_u-Md9Cg=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">std-pro=
posal...@<wbr>isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"bI_u-Md9CgAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJ=
TCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQ=
Qu5A%40mail.gmail.com';return true;" onclick=3D"this.href=3D'https:=
//groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixd=
zPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com';return true;">h=
ttps://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAHSY=
qdanbWiH%<wbr>2BFixdzPLjLnD%<wbr>2BfJTCr25yFphPSz%3DS45ryQQu5A%<wbr>40mail.=
gmail.com</a>.<br>
</p>
</blockquote></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/cdcda1c6-c10a-4beb-8490-fbdd3303f15d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cdcda1c6-c10a-4beb-8490-fbdd3303f15d=
%40isocpp.org</a>.<br />
------=_Part_1294_629861312.1468291603432--
------=_Part_1293_185616764.1468291603432--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 11 Jul 2016 21:34:57 -0700 (PDT)
Raw View
------=_Part_42_1928128145.1468298097152
Content-Type: multipart/alternative;
boundary="----=_Part_43_855876425.1468298097152"
------=_Part_43_855876425.1468298097152
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>>
>> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>> >
>> > The right decision is strict left-to-right order of evaluation for all=
=20
>> expressions, with side-effects fully completed as they are evaluated.
>>
>> That sounds like a performance nightmare.=20
>>
>
> This can be resolved by introducing some specific primitives to specify=
=20
> the evaluation order not obeying this rule. However, they will be lengthy=
=20
> and users will be reluctant to use them. Users will have excuse granted b=
y=20
> the default rule.
>
> The true harm of such decision is, it encourages stupidity and laziness a=
s=20
> the default case. Freedom of expressiveness is defeated by freedom of lac=
k=20
> of consideration.
>
Accepting reality should superseded all else. Reality has shown us that,=20
99% of the time, programmers assume things happen in a left-to-right order.=
=20
Which means that your vaunted "freedom of expressiveness" is only being=20
used 1% of the time.
C++ is a practical language, not some ivory-tower experiment. We must bow=
=20
to reality when it is presented to us. And reality tells us, *time and=20
again*, that we lose far more from undefined evaluation order than we gain=
=20
from it. We lose time in debugging. We lose time in development. We lose=20
mental time in having to think about it.
The only thing we gain from it is making it harder to become a proficient=
=20
C++ programmer. And that's not a benefit of the language.
This is offensive to people who want to write the "more correct" (more=20
> precise, easier to read, easier to maintain) - not merely "runnable" code=
:=20
> it makes they harder to achieve their goals while giving them nothing.
>
I don't know; I find this to be quite "correct" code:
auto inserts =3D make_array(v.insert(v.end(), std::forward<Ts>(args))...);
This code is very clear: for each item in the pack, insert it at the end,=
=20
capturing those iterators in an array. I see no reason to express this code=
=20
in a more verbose way. Well, besides the fact that it doesn't work, but=20
that's only due to a silly language rule.
What is the "more correct" alternative? Show me how to write that same code=
=20
in a way that is as clear and *concise* as this, which doesn't provoke=20
undefined behavior.
And if `make_array` offends you, feel free to change it into any function=
=20
that would take a sequence of iterators.
> The reason for defining order is to avoid code that "accidentally works"=
=20
>> - that is, code that has order dependencies such that its behavior is=20
>> undefined or unspecified, but happens to be built with a compiler whose=
=20
>> behavior matches the programmer's intent. Such code can mysteriously bre=
ak=20
>> when built on a different platform, long after it was written and has=20
>> appeared to work correctly. We have personally encountered this situatio=
n=20
>> in our company.
>>
>> There will always be implementation variance especially between=20
>> platforms. A blanket statement that it is always bad ignores the multitu=
de=20
>> of reasons to permit and encourage implementation variance. And of cours=
e=20
>> the implementation variance already exists, so you won't be able to chan=
ge=20
>> the behavior of existing platforms.=20
>>
>> > The reason for choosing strict left-to-right order is that it's trivia=
l=20
>> to explain, matches the order in which code is read, and matches other=
=20
>> languages such as Java.
>>
>> Any experienced user reads code blocks as a unit, just as any proficient=
=20
>> reader of natural languages reads sentences and paragraphs in a single=
=20
>> glance.=20
>>
>
> Yes. This is exactly my experience, and not only to C++. If a user can=20
> only work under a single strict order with some sequenced materials, I=20
> doubt his/her brain is damaged. Moreover, assuming left-to-right to be th=
e=20
> natural order may be offensive to people who are using natural languages=
=20
> with right-to-left natural layout.
>
Wait a minute. Having a left-to-right order is offensive to people who use=
=20
right-to-left languages... but having all our keywords being *English* is=
=20
perfectly fine? What about the fact that the parser goes left-to-right; are=
=20
they offended by that too? Maybe my brain is too damaged from not being=20
able to read paragraphs at a single glance, but I really can't follow your=
=20
logic here.
Also, programming isn't a sport; you don't get extra points for degree of=
=20
difficulty.
And is making C++ more similar to Java supposed to be a *good* thing?=20
>>
>
> And I can imagine making C++ less similar to C here has more impact in=20
> reality.
>
C is not a subset of C++, and it hasn't been since... C++98. While there=20
are people who write in the subset between C and C++, this is usually code=
=20
intended to be compiled as either. And such people are generally writing C=
=20
which can be compiled as C++, not writing C++ that can be compiled as C. So=
=20
they will write it under C's rules first and foremost. Porting the other=20
way is much rarer.
Also, let's not forget that, when it comes to complex expressions, C has=20
*nothing* on C++. We have so many more tools to write complicated=20
expressions than C does. That's why my example involved parameter packs and=
=20
fold expressions; to me, they're the poster-child for making sequences of=
=20
complex expressions that the user will *expect* to evaluate in order.
C++ needs it far more than C.
--=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/d882316a-bbd4-451a-85a0-161d27467086%40isocpp.or=
g.
------=_Part_43_855876425.1468298097152
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989=
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">=E5=9C=
=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=
=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=9A<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"><br>
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a rel=3D"nofollow">h=
yman...@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare. </p></blockquote><=
div><br>This can be resolved by introducing some specific primitives to spe=
cify the evaluation order not obeying this rule. However, they will be leng=
thy and users will be reluctant to use them. Users will have excuse granted=
by the default rule.<br><br>The true harm of such decision is, it encourag=
es stupidity and laziness as the default case. Freedom of expressiveness is=
defeated by freedom of lack of consideration.</div></div></blockquote><div=
><br>Accepting reality should superseded all else. Reality has shown us tha=
t, 99% of the time, programmers assume things happen in a left-to-right ord=
er. Which means that your vaunted "freedom of expressiveness" is =
only being used 1% of the time.<br><br>C++ is a practical language, not som=
e ivory-tower experiment. We must bow to reality when it is presented to us=
.. And reality tells us, <i>time and again</i>, that we lose far more from u=
ndefined evaluation order than we gain from it. We lose time in debugging. =
We lose time in development. We lose mental time in having to think about i=
t.<br><br>The only thing we gain from it is making it harder to become a pr=
oficient C++ programmer. And that's not a benefit of the language.<br><=
br></div><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=
>This is offensive to people who want to write the "more correct"=
(more precise, easier to read, easier to maintain) - not merely "runn=
able" code: it makes they harder to achieve their goals while giving t=
hem nothing.<br></div></div></blockquote><div><br>I don't know; I find =
this to be quite "correct" code:<br><br><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;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> inserts </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> make_array</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">v</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">in=
sert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">forward</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Ts</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">args</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">))...);</spa=
n></div></code></div><br>This code is very clear: for each item in the pack=
, insert it at the end, capturing those iterators in an array. I see no rea=
son to express this code in a more verbose way. Well, besides the fact that=
it doesn't work, but that's only due to a silly language rule.<br>=
<br>What is the "more correct" alternative? Show me how to write =
that same code in a way that is as clear and <i>concise</i> as this, which =
doesn't provoke undefined behavior.<br><br>And if `make_array` offends =
you, feel free to change it into any function that would take a sequence of=
iterators.<br><br></div><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><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms. </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance. </p></blockquote><div><br>Yes. This is exactly my experien=
ce, and not only to C++. If a user can only work under a single strict orde=
r with some sequenced materials, I doubt his/her brain is damaged. Moreover=
, assuming left-to-right to be the natural order may be offensive to people=
who are using natural languages with right-to-left natural layout.<br></di=
v></div></blockquote><div><br>Wait a minute. Having a left-to-right order i=
s offensive to people who use right-to-left languages... but having all our=
keywords being <i>English</i> is perfectly fine? What about the fact that =
the parser goes left-to-right; are they offended by that too? Maybe my brai=
n is too damaged from not being able to read paragraphs at a single glance,=
but I really can't follow your logic here.<br><br>Also, programming is=
n't a sport; you don't get extra points for degree of difficulty.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing? </p></blockquote><div><br>And I can imagine making C++ less simil=
ar to C here has more impact in reality.<br></div></div></blockquote><div><=
br>C is not a subset of C++, and it hasn't been since... C++98. While t=
here are people who write in the subset between C and C++, this is usually =
code intended to be compiled as either. And such people are generally writi=
ng C which can be compiled as C++, not writing C++ that can be compiled as =
C. So they will write it under C's rules first and foremost. Porting th=
e other way is much rarer.<br><br>Also, let's not forget that, when it =
comes to complex expressions, C has <i>nothing</i> on C++. We have so many =
more tools to write complicated expressions than C does. That's why my =
example involved parameter packs and fold expressions; to me, they're t=
he poster-child for making sequences of complex expressions that the user w=
ill <i>expect</i> to evaluate in order.<br><br>C++ needs it far more than C=
..<br></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/d882316a-bbd4-451a-85a0-161d27467086%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d882316a-bbd4-451a-85a0-161d27467086=
%40isocpp.org</a>.<br />
------=_Part_43_855876425.1468298097152--
------=_Part_42_1928128145.1468298097152--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 11 Jul 2016 22:12:21 -0700 (PDT)
Raw View
------=_Part_27_306337873.1468300341118
Content-Type: multipart/alternative;
boundary="----=_Part_28_1072916783.1468300341118"
------=_Part_28_1072916783.1468300341118
Content-Type: text/plain; charset=UTF-8
On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:
>
> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com <javascript:>>
> wrote:
> >
> > The right decision is strict left-to-right order of evaluation for all
> expressions, with side-effects fully completed as they are evaluated.
>
> That sounds like a performance nightmare.
>
I've heard a lot of "sounds like" out of people defending the undefined
order rules. I've heard far less "certainly is". Is there any genuine
evidence of this "performance nightmare", or is it just fear of the unknown?
> The reason for defining order is to avoid code that "accidentally works"
> - that is, code that has order dependencies such that its behavior is
> undefined or unspecified, but happens to be built with a compiler whose
> behavior matches the programmer's intent. Such code can mysteriously break
> when built on a different platform, long after it was written and has
> appeared to work correctly. We have personally encountered this situation
> in our company.
>
> There will always be implementation variance especially between platforms.
> A blanket statement that it is always bad ignores the multitude of reasons
> to permit and encourage implementation variance. And of course the
> implementation variance already exists, so you won't be able to change the
> behavior of existing platforms.
>
Sure, there will always be implementation variance.
Now explain why we should allow *this* one.
As far as I'm concerned, removing needless variance is its own reward. So
unless you can prove that the variance actually accomplishes something, it
should be done away with.
It's not like C++ hasn't removed variance in the past once it was shown to
be pointless. For example, the division of POD types into standard layout
and trivial copyability that C++11 did. It also expanded the range of types
that could be standard layout or trivially copyable, compared to C++98. Why
was standard layout expanded to allow base classes that were empty?
Because virtually all implementations didn't have empty classes interfere
in their layout. And thus the variance was proven to be pointless. Same
goes for expanding trivial copyability.
How many compilers actually use the undefined evaluation order rules to
optimize code? Do they re-order expressions based on what is best for that
specific expression? Or do they always evaluate expressions in an arbitrary
order? Because if such flexibility is not actually making code faster, then
the variance is pointless and should be done away with.
> The reason for choosing strict left-to-right order is that it's trivial
> to explain, matches the order in which code is read, and matches other
> languages such as Java.
>
> Any experienced user reads code blocks as a unit, just as any proficient
> reader of natural languages reads sentences and paragraphs in a single
> glance.
>
Let's pretend this was true (despite the undeniable fact that "experienced
users" make these mistakes too).
So what? Are we supposed to restrict C++ to "experienced users" as you
define it?
And is making C++ more similar to Java supposed to be a *good* thing?
>
In and of itself? No. But it's not a bad thing either. A language feature
should not be justified merely by "language X does it". But neither should
it be dismissed for that reason either.
--
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/788785e4-0946-432b-aa9c-e1c064cce167%40isocpp.org.
------=_Part_28_1072916783.1468300341118
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmu=
r wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"bI_u-Md9CgAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">hyman...@gmail.com</a>>=
wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare.</p></blockquote><d=
iv><br>I've heard a lot of "sounds like" out of people defend=
ing the undefined order rules. I've heard far less "certainly is&q=
uot;. Is there any genuine evidence of this "performance nightmare&quo=
t;, or is it just fear of the unknown?<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms.</p></blockquote><div><br>Sure, t=
here will always be implementation variance.<br><br>Now explain why we shou=
ld allow <i>this</i> one.<br><br>As far as I'm concerned, removing need=
less variance is its own reward. So unless you can prove that the variance =
actually accomplishes something, it should be done away with.<br><br>It'=
;s not like C++ hasn't removed variance in the past once it was shown t=
o be pointless. For example, the division of POD types into standard layout=
and trivial copyability that C++11 did. It also expanded the range of type=
s that could be standard layout or trivially copyable, compared to C++98. W=
hy was standard layout expanded to allow base classes that were empty?<br><=
br>Because virtually all implementations didn't have empty classes inte=
rfere in their layout. And thus the variance was proven to be pointless. Sa=
me goes for expanding trivial copyability.<br><br>How many compilers actual=
ly use the undefined evaluation order rules to optimize code? Do they re-or=
der expressions based on what is best for that specific expression? Or do t=
hey always evaluate expressions in an arbitrary order? Because if such flex=
ibility is not actually making code faster, then the variance is pointless =
and should be done away with.<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance.<br></p></blockquote><div><br>Let's pretend this was tr=
ue (despite the undeniable fact that "experienced users" make the=
se mistakes too).<br><br>So what? Are we supposed to restrict C++ to "=
experienced users" as you define it?<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing?<br></p></blockquote><div><br>In and of itself? No. But it's n=
ot a bad thing either. A language feature should not be justified merely by=
"language X does it". But neither should it be dismissed for tha=
t reason either.</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/788785e4-0946-432b-aa9c-e1c064cce167%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/788785e4-0946-432b-aa9c-e1c064cce167=
%40isocpp.org</a>.<br />
------=_Part_28_1072916783.1468300341118--
------=_Part_27_306337873.1468300341118--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 12 Jul 2016 01:02:45 -0700 (PDT)
Raw View
------=_Part_292_1669891846.1468310565486
Content-Type: multipart/alternative;
boundary="----=_Part_293_388804629.1468310565487"
------=_Part_293_388804629.1468310565487
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8812:34:57=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=
=BC=9A
>>>
>>>
>>> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>>> >
>>> > The right decision is strict left-to-right order of evaluation for al=
l=20
>>> expressions, with side-effects fully completed as they are evaluated.
>>>
>>> That sounds like a performance nightmare.=20
>>>
>>
>> This can be resolved by introducing some specific primitives to specify=
=20
>> the evaluation order not obeying this rule. However, they will be length=
y=20
>> and users will be reluctant to use them. Users will have excuse granted =
by=20
>> the default rule.
>>
>> The true harm of such decision is, it encourages stupidity and laziness=
=20
>> as the default case. Freedom of expressiveness is defeated by freedom of=
=20
>> lack of consideration.
>>
>
> Accepting reality should superseded all else. Reality has shown us that,=
=20
> 99% of the time, programmers assume things happen in a left-to-right orde=
r.=20
> Which means that your vaunted "freedom of expressiveness" is only being=
=20
> used 1% of the time.
>
> What should be there is what is already there. As formal encouragement,=
=20
the rules should be long lived in foreseeable future, so it should better=
=20
avoid compromise merely to the status quo. (Actually I don't think there is=
=20
need of the compromise. Note that we already have ways to make 99% cases=20
work perfectly. The illustrated examples in the original proposal, however,=
=20
are disputable.) And whether it is reality or not, if the assumption does=
=20
not feed the need (of reality, of course) well, it should be thrown away.=
=20
As I experienced, the real need now is to do "the right thing", not "worse=
=20
is better", because we already have the latter enough, if not too much.=20
Your idea seems to go to the wrong direction.
One more reality is, people get bitten when they think too little. Every=20
will-educated programmer around me does not assume left-to-right=20
evaluation, because the rules of the languages (not only C++) told them it=
=20
should not be relied on, or the coding convention forbids them to use such=
=20
risky styles. Unless you eliminate all rules about evaluation order other=
=20
than left-to-right in the world (again, not only in C++), programmers who=
=20
have to deal with multiple languages will have a lesson from it, sooner or=
=20
later. Again in reality, very few programmers learn and use only C++.=20
(Notably, C does not have such guarantee, so they must care about it.)=20
After changing of the rules in C++, they have to care more, if not be=20
ignorant to these changes totally - which is not a good attitude, anyway.
=20
> C++ is a practical language, not some ivory-tower experiment. We must bow=
=20
> to reality when it is presented to us. And reality tells us, *time and=20
> again*, that we lose far more from undefined evaluation order than we=20
> gain from it. We lose time in debugging. We lose time in development. We=
=20
> lose mental time in having to think about it.
>
> The only thing we gain from it is making it harder to become a proficient=
=20
> C++ programmer. And that's not a benefit of the language.
>
> No. I don't have such experience of wasting time on such things. Just kee=
p=20
away from those suspicious styles of code, and nothing would be lost. You=
=20
will eventually gain more (spare time, for example) because you don't have=
=20
to learn such strange code patterns if it is identified as smelly one. Only=
=20
a few proficient reviewers should know how to precisely find them and=20
prevent them harm the "practical" people.
=20
> This is offensive to people who want to write the "more correct" (more=20
>> precise, easier to read, easier to maintain) - not merely "runnable" cod=
e:=20
>> it makes they harder to achieve their goals while giving them nothing.
>>
>
> I don't know; I find this to be quite "correct" code:
>
> auto inserts =3D make_array(v.insert(v.end(), std::forward<Ts>(args))...)=
;
>
> This code is very clear: for each item in the pack, insert it at the end,=
=20
> capturing those iterators in an array. I see no reason to express this co=
de=20
> in a more verbose way. Well, besides the fact that it doesn't work, but=
=20
> that's only due to a silly language rule.
>
> What is the "more correct" alternative? Show me how to write that same=20
> code in a way that is as clear and *concise* as this, which doesn't=20
> provoke undefined behavior.
>
> I admit the language is silly here. The point is there is no way to=20
directly express the specified order you need here. But if it is not so=20
silly to meet your requirements, it would be equally silly when I don't=20
want to depend on the order explicitly. It would be even more silly,=20
because when you have no simple way to express the specified order, you can=
=20
workaround by verbosity; however, after the rules of specified order are=20
settled, I will not workaround without breaking portability. This is the=20
net lost.
I say "more correct" is about logical correctness of the code. Whenever you=
=20
make the code precisely work as your need through the specific rules you=20
have known, it is more correct than code relying on some unconsciously=20
randomly selected and accidentally effective rules, though it may be too=20
wordy.
The root of evil in your case is, the comma token does not play one role=20
well. This insane design can be attributed to C, only because it need to=20
specify order in several uncommon contexts (e.g. in the condition clause of=
=20
a loop statement). It can't consistently use semicolon because the design=
=20
of syntax. Your case is one of the victim of the silly design.
It is unfortunate that the comma operator is more messy in C++ as a result=
=20
of overloaded operator comma. But actually, the whole silly thing is still=
=20
that simple - the ability of specifying the order by the (builtin) operator=
=20
comma, or more precisely, *making a comma as an operator as well as a=20
non-operator in similar contexts without any reasons besides to workaround=
=20
the silly syntax design*. Why not semicolon? The rules would be simpler a=
=20
lot.
The answer may be *compatibility*. But why you throw away compatibility=20
just *now*, in a hurry and a far more disputable manner?
Despite the existed messy rules, a better solution is to add new core rules=
=20
to clearly express your need without such verbosity, e.g. allowing=20
semicolons as separators of function arguments.
=20
> And if `make_array` offends you, feel free to change it into any function=
=20
> that would take a sequence of iterators.
>
> > The reason for defining order is to avoid code that "accidentally works=
"=20
>>> - that is, code that has order dependencies such that its behavior is=
=20
>>> undefined or unspecified, but happens to be built with a compiler whose=
=20
>>> behavior matches the programmer's intent. Such code can mysteriously br=
eak=20
>>> when built on a different platform, long after it was written and has=
=20
>>> appeared to work correctly. We have personally encountered this situati=
on=20
>>> in our company.
>>>
>>> There will always be implementation variance especially between=20
>>> platforms. A blanket statement that it is always bad ignores the multit=
ude=20
>>> of reasons to permit and encourage implementation variance. And of cour=
se=20
>>> the implementation variance already exists, so you won't be able to cha=
nge=20
>>> the behavior of existing platforms.=20
>>>
>>> > The reason for choosing strict left-to-right order is that it's=20
>>> trivial to explain, matches the order in which code is read, and matche=
s=20
>>> other languages such as Java.
>>>
>>> Any experienced user reads code blocks as a unit, just as any proficien=
t=20
>>> reader of natural languages reads sentences and paragraphs in a single=
=20
>>> glance.=20
>>>
>>
>> Yes. This is exactly my experience, and not only to C++. If a user can=
=20
>> only work under a single strict order with some sequenced materials, I=
=20
>> doubt his/her brain is damaged. Moreover, assuming left-to-right to be t=
he=20
>> natural order may be offensive to people who are using natural languages=
=20
>> with right-to-left natural layout.
>>
>
> Wait a minute. Having a left-to-right order is offensive to people who us=
e=20
> right-to-left languages... but having all our keywords being *English* is=
=20
> perfectly fine? What about the fact that the parser goes left-to-right; a=
re=20
> they offended by that too? Maybe my brain is too damaged from not being=
=20
> able to read paragraphs at a single glance, but I really can't follow you=
r=20
> logic here.
>
No, it does not. ... I mean, it is *not *English. In reality, some people=
=20
ignorant to programming have already protested the "discrimination" of=20
English-central culture in programming languages. As a rebuttal, we told=20
them the words in common programming languages are never "English", just=20
occasionally spelled by Latin alphabets similarly as English words due to=
=20
some historical reasons.
I was illustrating the difference between processing text of natural=20
languages vs. in programming languages should not be ignored. Because I=20
don't think they can effectively use the same path of logic in one's brain,=
=20
there is no "natural" bonus of RTL evaluation. Further, I am sure different=
=20
natural languages can share little processing logic in my brain unless they=
=20
are similar enough (which is already difficult between arbitrary natural=20
languages), though they may share similar parsing logic in typical cases=20
(extraordinary cases are rare, e.g. Dongba symbols). Since I don't daily=20
use RTL languages so I used "may" to illustrate the possibility if the=20
points above is not feasible.
As of a parser... it can go from left to right, and vice versa. It can even=
=20
be neither LTR or RTL, but I guess it will be very inefficient.
>
> Also, programming isn't a sport; you don't get extra points for degree of=
=20
> difficulty.
>
> And is making C++ more similar to Java supposed to be a *good* thing?=20
>>>
>>
>> And I can imagine making C++ less similar to C here has more impact in=
=20
>> reality.
>>
>
> C is not a subset of C++, and it hasn't been since... C++98. While there=
=20
> are people who write in the subset between C and C++, this is usually cod=
e=20
> intended to be compiled as either. And such people are generally writing =
C=20
> which can be compiled as C++, not writing C++ that can be compiled as C. =
So=20
> they will write it under C's rules first and foremost. Porting the other=
=20
> way is much rarer.
>
> Yes, C++ should not be messed up with C. But again in reality, there a=20
plenty of "C/C++" code to maintain. People write code that compiled both by=
=20
C and C++ compiler (e.g. header files), or transfer code in C to C++ with=
=20
quite a few modifications (e.g. GCC source tree). The "context switch"=20
between working on C and C++ code base is often a pain, so those people=20
will likely continue to only use the common set of C and C++ features. So=
=20
the changes in the rule has almost no effect to them, if they are not=20
confused.
The worse thing is, the changes also make it more complicated to transfer=
=20
code between different version of C++ dialects, since they are not=20
bidirectionally compatible. Note the effective region is too broad so a=20
full coverage of review is always needed to port valid code in new dialects=
=20
back to the code base in old dialects (very likely in reality). Tools may=
=20
help, but not enough.
Should the extra effort be deserved? Or is it insane to switch to the new=
=20
C++ dialects?
=20
> Also, let's not forget that, when it comes to complex expressions, C has=
=20
> *nothing* on C++. We have so many more tools to write complicated=20
> expressions than C does. That's why my example involved parameter packs a=
nd=20
> fold expressions; to me, they're the poster-child for making sequences of=
=20
> complex expressions that the user will *expect* to evaluate in order.
>
> This expectation are based on vague and non modular design of specific=20
syntax (mostly borrowed from C), rather than intuition.=20
Briefly, there is no problem.to specify the order. But if the unavoidable=
=20
cost is to limit how to specify the order in other cases, it is problematic=
=20
and unacceptable.
=20
> C++ needs it far more than C.
>
--=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/59cb4a9f-f479-4416-ad7a-560f97af60bf%40isocpp.or=
g.
------=_Part_293_388804629.1468310565487
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8812:34:57=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=
=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=
=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=BC=9A<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><p dir=3D"ltr"><br>
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a rel=3D"nofollow">h=
yman...@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare. </p></blockquote><=
div><br>This can be resolved by introducing some specific primitives to spe=
cify the evaluation order not obeying this rule. However, they will be leng=
thy and users will be reluctant to use them. Users will have excuse granted=
by the default rule.<br><br>The true harm of such decision is, it encourag=
es stupidity and laziness as the default case. Freedom of expressiveness is=
defeated by freedom of lack of consideration.</div></div></blockquote><div=
><br>Accepting reality should superseded all else. Reality has shown us tha=
t, 99% of the time, programmers assume things happen in a left-to-right ord=
er. Which means that your vaunted "freedom of expressiveness" is =
only being used 1% of the time.<br><br></div></div></blockquote><div>What s=
hould be there is what is already there. As formal encouragement, the rules=
should be long lived in foreseeable future, so it should better avoid comp=
romise merely to the status quo. (Actually I don't think there is need =
of the compromise. Note that we already have ways to make 99% cases work pe=
rfectly. The illustrated examples in the original proposal, however, are di=
sputable.) And whether it is reality or not, if the assumption does not fee=
d the need (of reality, of course) well, it should be thrown away. As I exp=
erienced, the real need now is to do "the right thing", not "=
;worse is better", because we already have the latter enough, if not t=
oo much. Your idea seems to go to the wrong direction.<br><br>One more real=
ity is, people get bitten when they think too little. Every will-educated p=
rogrammer around me does not assume left-to-right evaluation, because the r=
ules of the languages (not only C++) told them it should not be relied on, =
or the coding convention forbids them to use such risky styles. Unless you =
eliminate all rules about evaluation order other than left-to-right in the =
world (again, not only in C++), programmers who have to deal with multiple =
languages will have a lesson from it, sooner or later. Again in reality, ve=
ry few programmers learn and use only C++. (Notably, C does not have such g=
uarantee, so they must care about it.) After changing of the rules in C++, =
they have to care more, if not be ignorant to these changes totally - which=
is not a good attitude, anyway.<br>=C2=A0<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>C++ is a practical language, no=
t some ivory-tower experiment. We must bow to reality when it is presented =
to us. And reality tells us, <i>time and again</i>, that we lose far more f=
rom undefined evaluation order than we gain from it. We lose time in debugg=
ing. We lose time in development. We lose mental time in having to think ab=
out it.<br><br>The only thing we gain from it is making it harder to become=
a proficient C++ programmer. And that's not a benefit of the language.=
<br><br></div></div></blockquote><div>No. I don't have such experience =
of wasting time on such things. Just keep away from those suspicious styles=
of code, and nothing would be lost. You will eventually gain more (spare t=
ime, for example) because you don't have to learn such strange code pat=
terns if it is identified as smelly one. Only a few proficient reviewers sh=
ould know how to precisely find them and prevent them harm the "practi=
cal" people.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div></div><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>This is offensive to people who want to write the &q=
uot;more correct" (more precise, easier to read, easier to maintain) -=
not merely "runnable" code: it makes they harder to achieve thei=
r goals while giving them nothing.<br></div></div></blockquote><div><br>I d=
on't know; I find this to be quite "correct" code:<br><br><di=
v 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><div><span =
style=3D"color:#008">auto</span><span style=3D"color:#000"> inserts </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> make_array=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">v</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">insert</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000">v</span><sp=
an style=3D"color:#660">.</span><span style=3D"color:#008">end</span><span =
style=3D"color:#660">(),</span><span style=3D"color:#000"> std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#000">forward</span><spa=
n style=3D"color:#660"><</span><span style=3D"color:#606">Ts</span><span=
style=3D"color:#660">>(</span><span style=3D"color:#000">args</span><sp=
an style=3D"color:#660">))...);</span></div></code></div><br>This code is v=
ery clear: for each item in the pack, insert it at the end, capturing those=
iterators in an array. I see no reason to express this code in a more verb=
ose way. Well, besides the fact that it doesn't work, but that's on=
ly due to a silly language rule.<br><br>What is the "more correct"=
; alternative? Show me how to write that same code in a way that is as clea=
r and <i>concise</i> as this, which doesn't provoke undefined behavior.=
<br><br></div></div></blockquote><div>I admit the language is silly here. T=
he point is there is no way to directly express the specified order you nee=
d here. But if it is not so silly to meet your requirements, it would be eq=
ually silly when I don't want to depend on the order explicitly. It wou=
ld be even more silly, because when you have no simple way to express the s=
pecified order, you can workaround by verbosity; however, after the rules o=
f specified order are settled, I will not workaround without breaking porta=
bility. This is the net lost.<br><br>I say "more correct" is abou=
t logical correctness of the code. Whenever you make the code precisely wor=
k as your need through the specific rules you have known, it is more correc=
t than code relying on some unconsciously randomly selected and accidentall=
y effective rules, though it may be too wordy.<br><br>The root of evil in y=
our case is, the comma token does not play one role well. This insane desig=
n can be attributed to C, only because it need to specify order in several =
uncommon contexts (e.g. in the condition clause of a loop statement). It ca=
n't=C2=A0 consistently use semicolon because the design of syntax. Your=
case is one of the victim of the silly design.<br><br> It is unfortunate t=
hat the comma operator is more messy in C++ as a result of overloaded opera=
tor comma. But actually, the whole silly thing is still that simple - the a=
bility of specifying the order by the (builtin) operator comma, or more pre=
cisely, <i>making a comma as an operator as well as a non-operator in simil=
ar contexts without any reasons besides to workaround the silly syntax desi=
gn</i>. Why not semicolon? The rules would be simpler a lot.<br><br>The ans=
wer may be <i>compatibility</i>. But why you throw away compatibility just =
<i>now</i>, in a hurry and a far more disputable manner?<br><br>Despite the=
existed messy rules, a better solution is to add new core rules to clearly=
express your=20
need without such verbosity, e.g. allowing semicolons as separators of=20
function arguments.<br><br>=C2=A0<br></div><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>And if `make_array` offends you, feel fr=
ee to change it into any function that would take a sequence of iterators.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms. </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance. </p></blockquote><div><br>Yes. This is exactly my experien=
ce, and not only to C++. If a user can only work under a single strict orde=
r with some sequenced materials, I doubt his/her brain is damaged. Moreover=
, assuming left-to-right to be the natural order may be offensive to people=
who are using natural languages with right-to-left natural layout.<br></di=
v></div></blockquote><div><br>Wait a minute. Having a left-to-right order i=
s offensive to people who use right-to-left languages... but having all our=
keywords being <i>English</i> is perfectly fine? What about the fact that =
the parser goes left-to-right; are they offended by that too? Maybe my brai=
n is too damaged from not being able to read paragraphs at a single glance,=
but I really can't follow your logic here.<br></div></div></blockquote=
><div>No, it does not. ... I mean, it is <i>not </i>English. In reality, so=
me people ignorant to programming have already protested the "discrimi=
nation" of English-central culture in programming languages. As a rebu=
ttal, we told them the words in common programming languages are never &quo=
t;English", just occasionally spelled by Latin alphabets similarly as =
English words due to some historical reasons.<br>I was illustrating the dif=
ference between processing text of natural languages vs. in programming lan=
guages should not be ignored. Because I don't think they can effectivel=
y use the same path of logic in one's brain, there is no "natural&=
quot; bonus of RTL evaluation. Further, I am sure different natural languag=
es can share little processing logic in my brain unless they are similar en=
ough (which is already difficult between arbitrary natural languages), thou=
gh they may share similar parsing logic in typical cases (extraordinary cas=
es are rare, e.g. Dongba symbols). Since I don't daily use RTL language=
s so I used "may" to illustrate the possibility if the points abo=
ve is not feasible.<br>As of a parser... it can go from left to right, and =
vice versa. It can even be neither LTR or RTL, but I guess it will be very =
inefficient.<br></div><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><br>Also, programming isn't a sport; you don't get ex=
tra points for degree of difficulty.<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing? </p></blockquote><div><br>And I can imagine making C++ less simil=
ar to C here has more impact in reality.<br></div></div></blockquote><div><=
br>C is not a subset of C++, and it hasn't been since... C++98. While t=
here are people who write in the subset between C and C++, this is usually =
code intended to be compiled as either. And such people are generally writi=
ng C which can be compiled as C++, not writing C++ that can be compiled as =
C. So they will write it under C's rules first and foremost. Porting th=
e other way is much rarer.<br><br></div></div></blockquote><div>Yes, C++ sh=
ould not be messed up with C. But again in reality, there a plenty of "=
;C/C++" code to maintain. People write code that compiled both by C an=
d C++ compiler (e.g. header files), or transfer code in C to C++ with quite=
a few modifications (e.g. GCC source tree). The "context switch"=
between working on C and C++ code base is often a pain, so those people wi=
ll likely continue to only use the common set of C and C++ features. So the=
changes in the rule has almost no effect to them, if they are not confused=
..<br><br>The worse thing is, the changes also make it more complicated to t=
ransfer code between different version of C++ dialects, since they are not =
bidirectionally compatible. Note the effective region is too broad so a ful=
l coverage of review is always needed to port valid code in new dialects ba=
ck to the code base in old dialects (very likely in reality). Tools may hel=
p, but not enough.<br><br>Should the extra effort be deserved? Or is it ins=
ane to switch to the new C++ dialects?<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Also, let's not forge=
t that, when it comes to complex expressions, C has <i>nothing</i> on C++. =
We have so many more tools to write complicated expressions than C does. Th=
at's why my example involved parameter packs and fold expressions; to m=
e, they're the poster-child for making sequences of complex expressions=
that the user will <i>expect</i> to evaluate in order.<br><br></div></div>=
</blockquote><div>This expectation are based on vague and non modular desig=
n of specific syntax (mostly borrowed from C), rather than intuition. <br><=
br>Briefly, there is no problem.to specify the order. But if the unavoidabl=
e cost is to limit how to specify the order in other cases, it is problemat=
ic and unacceptable.<br>=C2=A0<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;"><div dir=3D"ltr"><div>C++ needs it far more than C.<br></div></di=
v></blockquote></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/59cb4a9f-f479-4416-ad7a-560f97af60bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f479-4416-ad7a-560f97af60bf=
%40isocpp.org</a>.<br />
------=_Part_293_388804629.1468310565487--
------=_Part_292_1669891846.1468310565486--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 12:00:32 -0400
Raw View
--001a1135729e8802c90537725fd2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
We have been around and around this discussion many times before. I know
that there are people who do not accept that C++ should have strict
left-to-right evaluation. I believe that those people are utterly wrong,
but that there is no way to convince them of that, not unlike other
political situations. To me, the notion that (a() << (b() << c())) and
(a() =3D (b() =3D c())) should call a(), b(), and c() in different specifie=
d
orders, while (a() + (b() + c())) should call them in unspecified order is
so irrational that it beggars belief.
On Tue, Jul 12, 2016 at 4:02 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8B=E5=8D=8812:34:57=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:
>>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=
UTC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=EF=
=BC=9A
>>>>
>>>>
>>>> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>>>> >
>>>> > The right decision is strict left-to-right order of evaluation for
>>>> all expressions, with side-effects fully completed as they are evaluat=
ed.
>>>>
>>>> That sounds like a performance nightmare.
>>>>
>>>
>>> This can be resolved by introducing some specific primitives to specify
>>> the evaluation order not obeying this rule. However, they will be lengt=
hy
>>> and users will be reluctant to use them. Users will have excuse granted=
by
>>> the default rule.
>>>
>>> The true harm of such decision is, it encourages stupidity and laziness
>>> as the default case. Freedom of expressiveness is defeated by freedom o=
f
>>> lack of consideration.
>>>
>>
>> Accepting reality should superseded all else. Reality has shown us that,
>> 99% of the time, programmers assume things happen in a left-to-right ord=
er.
>> Which means that your vaunted "freedom of expressiveness" is only being
>> used 1% of the time.
>>
>> What should be there is what is already there. As formal encouragement,
> the rules should be long lived in foreseeable future, so it should better
> avoid compromise merely to the status quo. (Actually I don't think there =
is
> need of the compromise. Note that we already have ways to make 99% cases
> work perfectly. The illustrated examples in the original proposal, howeve=
r,
> are disputable.) And whether it is reality or not, if the assumption does
> not feed the need (of reality, of course) well, it should be thrown away.
> As I experienced, the real need now is to do "the right thing", not "wors=
e
> is better", because we already have the latter enough, if not too much.
> Your idea seems to go to the wrong direction.
>
> One more reality is, people get bitten when they think too little. Every
> will-educated programmer around me does not assume left-to-right
> evaluation, because the rules of the languages (not only C++) told them i=
t
> should not be relied on, or the coding convention forbids them to use suc=
h
> risky styles. Unless you eliminate all rules about evaluation order other
> than left-to-right in the world (again, not only in C++), programmers who
> have to deal with multiple languages will have a lesson from it, sooner o=
r
> later. Again in reality, very few programmers learn and use only C++.
> (Notably, C does not have such guarantee, so they must care about it.)
> After changing of the rules in C++, they have to care more, if not be
> ignorant to these changes totally - which is not a good attitude, anyway.
>
>
>> C++ is a practical language, not some ivory-tower experiment. We must bo=
w
>> to reality when it is presented to us. And reality tells us, *time and
>> again*, that we lose far more from undefined evaluation order than we
>> gain from it. We lose time in debugging. We lose time in development. We
>> lose mental time in having to think about it.
>>
>> The only thing we gain from it is making it harder to become a proficien=
t
>> C++ programmer. And that's not a benefit of the language.
>>
>> No. I don't have such experience of wasting time on such things. Just
> keep away from those suspicious styles of code, and nothing would be lost=
..
> You will eventually gain more (spare time, for example) because you don't
> have to learn such strange code patterns if it is identified as smelly on=
e.
> Only a few proficient reviewers should know how to precisely find them an=
d
> prevent them harm the "practical" people.
>
>
>> This is offensive to people who want to write the "more correct" (more
>>> precise, easier to read, easier to maintain) - not merely "runnable" co=
de:
>>> it makes they harder to achieve their goals while giving them nothing.
>>>
>>
>> I don't know; I find this to be quite "correct" code:
>>
>> auto inserts =3D make_array(v.insert(v.end(), std::forward<Ts>(args))...=
);
>>
>> This code is very clear: for each item in the pack, insert it at the end=
,
>> capturing those iterators in an array. I see no reason to express this c=
ode
>> in a more verbose way. Well, besides the fact that it doesn't work, but
>> that's only due to a silly language rule.
>>
>> What is the "more correct" alternative? Show me how to write that same
>> code in a way that is as clear and *concise* as this, which doesn't
>> provoke undefined behavior.
>>
>> I admit the language is silly here. The point is there is no way to
> directly express the specified order you need here. But if it is not so
> silly to meet your requirements, it would be equally silly when I don't
> want to depend on the order explicitly. It would be even more silly,
> because when you have no simple way to express the specified order, you c=
an
> workaround by verbosity; however, after the rules of specified order are
> settled, I will not workaround without breaking portability. This is the
> net lost.
>
> I say "more correct" is about logical correctness of the code. Whenever
> you make the code precisely work as your need through the specific rules
> you have known, it is more correct than code relying on some unconsciousl=
y
> randomly selected and accidentally effective rules, though it may be too
> wordy.
>
> The root of evil in your case is, the comma token does not play one role
> well. This insane design can be attributed to C, only because it need to
> specify order in several uncommon contexts (e.g. in the condition clause =
of
> a loop statement). It can't consistently use semicolon because the desig=
n
> of syntax. Your case is one of the victim of the silly design.
>
> It is unfortunate that the comma operator is more messy in C++ as a resul=
t
> of overloaded operator comma. But actually, the whole silly thing is stil=
l
> that simple - the ability of specifying the order by the (builtin) operat=
or
> comma, or more precisely, *making a comma as an operator as well as a
> non-operator in similar contexts without any reasons besides to workaroun=
d
> the silly syntax design*. Why not semicolon? The rules would be simpler a
> lot.
>
> The answer may be *compatibility*. But why you throw away compatibility
> just *now*, in a hurry and a far more disputable manner?
>
> Despite the existed messy rules, a better solution is to add new core
> rules to clearly express your need without such verbosity, e.g. allowing
> semicolons as separators of function arguments.
>
>
>
>> And if `make_array` offends you, feel free to change it into any functio=
n
>> that would take a sequence of iterators.
>>
>> > The reason for defining order is to avoid code that "accidentally
>>>> works" - that is, code that has order dependencies such that its behav=
ior
>>>> is undefined or unspecified, but happens to be built with a compiler w=
hose
>>>> behavior matches the programmer's intent. Such code can mysteriously b=
reak
>>>> when built on a different platform, long after it was written and has
>>>> appeared to work correctly. We have personally encountered this situat=
ion
>>>> in our company.
>>>>
>>>> There will always be implementation variance especially between
>>>> platforms. A blanket statement that it is always bad ignores the multi=
tude
>>>> of reasons to permit and encourage implementation variance. And of cou=
rse
>>>> the implementation variance already exists, so you won't be able to ch=
ange
>>>> the behavior of existing platforms.
>>>>
>>>> > The reason for choosing strict left-to-right order is that it's
>>>> trivial to explain, matches the order in which code is read, and match=
es
>>>> other languages such as Java.
>>>>
>>>> Any experienced user reads code blocks as a unit, just as any
>>>> proficient reader of natural languages reads sentences and paragraphs =
in a
>>>> single glance.
>>>>
>>>
>>> Yes. This is exactly my experience, and not only to C++. If a user can
>>> only work under a single strict order with some sequenced materials, I
>>> doubt his/her brain is damaged. Moreover, assuming left-to-right to be =
the
>>> natural order may be offensive to people who are using natural language=
s
>>> with right-to-left natural layout.
>>>
>>
>> Wait a minute. Having a left-to-right order is offensive to people who
>> use right-to-left languages... but having all our keywords being
>> *English* is perfectly fine? What about the fact that the parser goes
>> left-to-right; are they offended by that too? Maybe my brain is too dama=
ged
>> from not being able to read paragraphs at a single glance, but I really
>> can't follow your logic here.
>>
> No, it does not. ... I mean, it is *not *English. In reality, some people
> ignorant to programming have already protested the "discrimination" of
> English-central culture in programming languages. As a rebuttal, we told
> them the words in common programming languages are never "English", just
> occasionally spelled by Latin alphabets similarly as English words due to
> some historical reasons.
> I was illustrating the difference between processing text of natural
> languages vs. in programming languages should not be ignored. Because I
> don't think they can effectively use the same path of logic in one's brai=
n,
> there is no "natural" bonus of RTL evaluation. Further, I am sure differe=
nt
> natural languages can share little processing logic in my brain unless th=
ey
> are similar enough (which is already difficult between arbitrary natural
> languages), though they may share similar parsing logic in typical cases
> (extraordinary cases are rare, e.g. Dongba symbols). Since I don't daily
> use RTL languages so I used "may" to illustrate the possibility if the
> points above is not feasible.
> As of a parser... it can go from left to right, and vice versa. It can
> even be neither LTR or RTL, but I guess it will be very inefficient.
>
>>
>> Also, programming isn't a sport; you don't get extra points for degree o=
f
>> difficulty.
>>
>> And is making C++ more similar to Java supposed to be a *good* thing?
>>>>
>>>
>>> And I can imagine making C++ less similar to C here has more impact in
>>> reality.
>>>
>>
>> C is not a subset of C++, and it hasn't been since... C++98. While there
>> are people who write in the subset between C and C++, this is usually co=
de
>> intended to be compiled as either. And such people are generally writing=
C
>> which can be compiled as C++, not writing C++ that can be compiled as C.=
So
>> they will write it under C's rules first and foremost. Porting the other
>> way is much rarer.
>>
>> Yes, C++ should not be messed up with C. But again in reality, there a
> plenty of "C/C++" code to maintain. People write code that compiled both =
by
> C and C++ compiler (e.g. header files), or transfer code in C to C++ with
> quite a few modifications (e.g. GCC source tree). The "context switch"
> between working on C and C++ code base is often a pain, so those people
> will likely continue to only use the common set of C and C++ features. So
> the changes in the rule has almost no effect to them, if they are not
> confused.
>
> The worse thing is, the changes also make it more complicated to transfer
> code between different version of C++ dialects, since they are not
> bidirectionally compatible. Note the effective region is too broad so a
> full coverage of review is always needed to port valid code in new dialec=
ts
> back to the code base in old dialects (very likely in reality). Tools may
> help, but not enough.
>
> Should the extra effort be deserved? Or is it insane to switch to the new
> C++ dialects?
>
>
>> Also, let's not forget that, when it comes to complex expressions, C has
>> *nothing* on C++. We have so many more tools to write complicated
>> expressions than C does. That's why my example involved parameter packs =
and
>> fold expressions; to me, they're the poster-child for making sequences o=
f
>> complex expressions that the user will *expect* to evaluate in order.
>>
>> This expectation are based on vague and non modular design of specific
> syntax (mostly borrowed from C), rather than intuition.
>
> Briefly, there is no problem.to specify the order. But if the unavoidable
> cost is to limit how to specify the order in other cases, it is problemat=
ic
> and unacceptable.
>
>
>> C++ needs it far more than 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f47=
9-4416-ad7a-560f97af60bf%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f4=
79-4416-ad7a-560f97af60bf%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAHSYqdaW%2BejAuevQB%3D6KZpWwt_P_ocL-6a9SqN5Sy2M=
ZB1oR5A%40mail.gmail.com.
--001a1135729e8802c90537725fd2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">We have been around and around this discussion many times =
before.=C2=A0 I know that there are people who do not accept that C++ shoul=
d have strict left-to-right evaluation.=C2=A0 I believe that those people a=
re utterly wrong, but that there is no way to convince them of that, not un=
like other political situations.=C2=A0 To me, the notion that (a() <<=
(b() << c())) and (a() =3D (b() =3D c())) should call a(), b(), and =
c() in different specified orders, while (a() + (b() + c())) should call th=
em in unspecified order is so irrational that it beggars belief.</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 12, 2016 a=
t 4:02 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"mailto:frankhb1989@=
gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=
=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=
=8812:34:57=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<span class=3D"">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, July 11=
, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=
=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward C=
atmur=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p =
dir=3D"ltr"><br>
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a rel=3D"nofollow">h=
yman...@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare. </p></blockquote><=
div><br>This can be resolved by introducing some specific primitives to spe=
cify the evaluation order not obeying this rule. However, they will be leng=
thy and users will be reluctant to use them. Users will have excuse granted=
by the default rule.<br><br>The true harm of such decision is, it encourag=
es stupidity and laziness as the default case. Freedom of expressiveness is=
defeated by freedom of lack of consideration.</div></div></blockquote><div=
><br>Accepting reality should superseded all else. Reality has shown us tha=
t, 99% of the time, programmers assume things happen in a left-to-right ord=
er. Which means that your vaunted "freedom of expressiveness" is =
only being used 1% of the time.<br><br></div></div></blockquote></span><div=
>What should be there is what is already there. As formal encouragement, th=
e rules should be long lived in foreseeable future, so it should better avo=
id compromise merely to the status quo. (Actually I don't think there i=
s need of the compromise. Note that we already have ways to make 99% cases =
work perfectly. The illustrated examples in the original proposal, however,=
are disputable.) And whether it is reality or not, if the assumption does =
not feed the need (of reality, of course) well, it should be thrown away. A=
s I experienced, the real need now is to do "the right thing", no=
t "worse is better", because we already have the latter enough, i=
f not too much. Your idea seems to go to the wrong direction.<br><br>One mo=
re reality is, people get bitten when they think too little. Every will-edu=
cated programmer around me does not assume left-to-right evaluation, becaus=
e the rules of the languages (not only C++) told them it should not be reli=
ed on, or the coding convention forbids them to use such risky styles. Unle=
ss you eliminate all rules about evaluation order other than left-to-right =
in the world (again, not only in C++), programmers who have to deal with mu=
ltiple languages will have a lesson from it, sooner or later. Again in real=
ity, very few programmers learn and use only C++. (Notably, C does not have=
such guarantee, so they must care about it.) After changing of the rules i=
n C++, they have to care more, if not be ignorant to these changes totally =
- which is not a good attitude, anyway.<br>=C2=A0<br></div><span class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>C++ is a pra=
ctical language, not some ivory-tower experiment. We must bow to reality wh=
en it is presented to us. And reality tells us, <i>time and again</i>, that=
we lose far more from undefined evaluation order than we gain from it. We =
lose time in debugging. We lose time in development. We lose mental time in=
having to think about it.<br><br>The only thing we gain from it is making =
it harder to become a proficient C++ programmer. And that's not a benef=
it of the language.<br><br></div></div></blockquote></span><div>No. I don&#=
39;t have such experience of wasting time on such things. Just keep away fr=
om those suspicious styles of code, and nothing would be lost. You will eve=
ntually gain more (spare time, for example) because you don't have to l=
earn such strange code patterns if it is identified as smelly one. Only a f=
ew proficient reviewers should know how to precisely find them and prevent =
them harm the "practical" people.<br>=C2=A0<br></div><span class=
=3D""><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><=
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>This is offens=
ive to people who want to write the "more correct" (more precise,=
easier to read, easier to maintain) - not merely "runnable" code=
: it makes they harder to achieve their goals while giving them nothing.<br=
></div></div></blockquote><div><br>I don't know; I find this to be quit=
e "correct" code:<br><br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><span style=3D"color:#008">auto</span><span=
style=3D"color:#000"> inserts </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> make_array</span><span style=3D"color:#660">(</=
span><span style=3D"color:#000">v</span><span style=3D"color:#660">.</span>=
<span style=3D"color:#000">insert</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">v</span><span style=3D"color:#660">.</span><span=
style=3D"color:#008">end</span><span style=3D"color:#660">(),</span><span =
style=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span s=
tyle=3D"color:#000">forward</span><span style=3D"color:#660"><</span><sp=
an style=3D"color:#606">Ts</span><span style=3D"color:#660">>(</span><sp=
an style=3D"color:#000">args</span><span style=3D"color:#660">))...);</span=
></div></code></div><br>This code is very clear: for each item in the pack,=
insert it at the end, capturing those iterators in an array. I see no reas=
on to express this code in a more verbose way. Well, besides the fact that =
it doesn't work, but that's only due to a silly language rule.<br><=
br>What is the "more correct" alternative? Show me how to write t=
hat same code in a way that is as clear and <i>concise</i> as this, which d=
oesn't provoke undefined behavior.<br><br></div></div></blockquote></sp=
an><div>I admit the language is silly here. The point is there is no way to=
directly express the specified order you need here. But if it is not so si=
lly to meet your requirements, it would be equally silly when I don't w=
ant to depend on the order explicitly. It would be even more silly, because=
when you have no simple way to express the specified order, you can workar=
ound by verbosity; however, after the rules of specified order are settled,=
I will not workaround without breaking portability. This is the net lost.<=
br><br>I say "more correct" is about logical correctness of the c=
ode. Whenever you make the code precisely work as your need through the spe=
cific rules you have known, it is more correct than code relying on some un=
consciously randomly selected and accidentally effective rules, though it m=
ay be too wordy.<br><br>The root of evil in your case is, the comma token d=
oes not play one role well. This insane design can be attributed to C, only=
because it need to specify order in several uncommon contexts (e.g. in the=
condition clause of a loop statement). It can't=C2=A0 consistently use=
semicolon because the design of syntax. Your case is one of the victim of =
the silly design.<br><br> It is unfortunate that the comma operator is more=
messy in C++ as a result of overloaded operator comma. But actually, the w=
hole silly thing is still that simple - the ability of specifying the order=
by the (builtin) operator comma, or more precisely, <i>making a comma as a=
n operator as well as a non-operator in similar contexts without any reason=
s besides to workaround the silly syntax design</i>. Why not semicolon? The=
rules would be simpler a lot.<br><br>The answer may be <i>compatibility</i=
>. But why you throw away compatibility just <i>now</i>, in a hurry and a f=
ar more disputable manner?<br><br>Despite the existed messy rules, a better=
solution is to add new core rules to clearly express your=20
need without such verbosity, e.g. allowing semicolons as separators of=20
function arguments.<br><br>=C2=A0<br></div><span class=3D""><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>And if `make_array` offends =
you, feel free to change it into any function that would take a sequence of=
iterators.<br><br></div><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><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms. </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance. </p></blockquote><div><br>Yes. This is exactly my experien=
ce, and not only to C++. If a user can only work under a single strict orde=
r with some sequenced materials, I doubt his/her brain is damaged. Moreover=
, assuming left-to-right to be the natural order may be offensive to people=
who are using natural languages with right-to-left natural layout.<br></di=
v></div></blockquote><div><br>Wait a minute. Having a left-to-right order i=
s offensive to people who use right-to-left languages... but having all our=
keywords being <i>English</i> is perfectly fine? What about the fact that =
the parser goes left-to-right; are they offended by that too? Maybe my brai=
n is too damaged from not being able to read paragraphs at a single glance,=
but I really can't follow your logic here.<br></div></div></blockquote=
></span><div>No, it does not. ... I mean, it is <i>not </i>English. In real=
ity, some people ignorant to programming have already protested the "d=
iscrimination" of English-central culture in programming languages. As=
a rebuttal, we told them the words in common programming languages are nev=
er "English", just occasionally spelled by Latin alphabets simila=
rly as English words due to some historical reasons.<br>I was illustrating =
the difference between processing text of natural languages vs. in programm=
ing languages should not be ignored. Because I don't think they can eff=
ectively use the same path of logic in one's brain, there is no "n=
atural" bonus of RTL evaluation. Further, I am sure different natural =
languages can share little processing logic in my brain unless they are sim=
ilar enough (which is already difficult between arbitrary natural languages=
), though they may share similar parsing logic in typical cases (extraordin=
ary cases are rare, e.g. Dongba symbols). Since I don't daily use RTL l=
anguages so I used "may" to illustrate the possibility if the poi=
nts above is not feasible.<br>As of a parser... it can go from left to righ=
t, and vice versa. It can even be neither LTR or RTL, but I guess it will b=
e very inefficient.<br></div><span class=3D""><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br>Also, programming isn't a sport; y=
ou don't get extra points for degree of difficulty.<br><br></div><block=
quote 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><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing? </p></blockquote><div><br>And I can imagine making C++ less simil=
ar to C here has more impact in reality.<br></div></div></blockquote><div><=
br>C is not a subset of C++, and it hasn't been since... C++98. While t=
here are people who write in the subset between C and C++, this is usually =
code intended to be compiled as either. And such people are generally writi=
ng C which can be compiled as C++, not writing C++ that can be compiled as =
C. So they will write it under C's rules first and foremost. Porting th=
e other way is much rarer.<br><br></div></div></blockquote></span><div>Yes,=
C++ should not be messed up with C. But again in reality, there a plenty o=
f "C/C++" code to maintain. People write code that compiled both =
by C and C++ compiler (e.g. header files), or transfer code in C to C++ wit=
h quite a few modifications (e.g. GCC source tree). The "context switc=
h" between working on C and C++ code base is often a pain, so those pe=
ople will likely continue to only use the common set of C and C++ features.=
So the changes in the rule has almost no effect to them, if they are not c=
onfused.<br><br>The worse thing is, the changes also make it more complicat=
ed to transfer code between different version of C++ dialects, since they a=
re not bidirectionally compatible. Note the effective region is too broad s=
o a full coverage of review is always needed to port valid code in new dial=
ects back to the code base in old dialects (very likely in reality). Tools =
may help, but not enough.<br><br>Should the extra effort be deserved? Or is=
it insane to switch to the new C++ dialects?<br>=C2=A0<br></div><span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Also, =
let's not forget that, when it comes to complex expressions, C has <i>n=
othing</i> on C++. We have so many more tools to write complicated expressi=
ons than C does. That's why my example involved parameter packs and fol=
d expressions; to me, they're the poster-child for making sequences of =
complex expressions that the user will <i>expect</i> to evaluate in order.<=
br><br></div></div></blockquote></span><div>This expectation are based on v=
ague and non modular design of specific syntax (mostly borrowed from C), ra=
ther than intuition. <br><br>Briefly, there is no <a href=3D"http://problem=
..to" target=3D"_blank">problem.to</a> specify the order. But if the unavoid=
able cost is to limit how to specify the order in other cases, it is proble=
matic and unacceptable.<br>=C2=A0<br></div><span class=3D""><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>C++ needs it far more than C=
..<br></div></div></blockquote></span></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" 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@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/59cb4a9f-f479-4416-ad7a-560f97af60bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f479-=
4416-ad7a-560f97af60bf%40isocpp.org</a>.<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" 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/CAHSYqdaW%2BejAuevQB%3D6KZpWwt_P_ocL-=
6a9SqN5Sy2MZB1oR5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaW%2Be=
jAuevQB%3D6KZpWwt_P_ocL-6a9SqN5Sy2MZB1oR5A%40mail.gmail.com</a>.<br />
--001a1135729e8802c90537725fd2--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 09:01:50 -0700
Raw View
--001a1140f77635c36b05377264e2
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> The true harm of such decision is, it encourages stupidity and laziness as
> the default case.
>
Please try to stick to technical arguments on this mailing list, instead of
personally attacking ("stupidity") the people who prefer a different
outcome than you do.
Jeffrey
--
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/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com.
--001a1140f77635c36b05377264e2
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 M=
on, Jul 11, 2016 at 7:46 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank" class=3D"cremed">frankhb1989=
@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>The true harm of such decision is, it encourages stupidity and la=
ziness as the default case.</div></div></blockquote><div><br></div><div>Ple=
ase try to stick to technical arguments on this mailing list, instead of pe=
rsonally attacking ("stupidity") the people who prefer a differen=
t outcome than you do.</div></div><br></div><div class=3D"gmail_extra">Jeff=
rey</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/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUG=
xHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2=
Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com</a>.<br />
--001a1140f77635c36b05377264e2--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 12:11:46 -0400
Raw View
--001a114c843ab927b6053772872f
Content-Type: text/plain; charset=UTF-8
The "stupidity and laziness" argument demands that the programming language
should contain constructs that must not be used, and that will act as traps
for the unwary. The notion that this is a desirable feature again seems to
me so irrational that it beggars belief.
On Tue, Jul 12, 2016 at 12:01 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frankhb1989@gmail.com>
> wrote:
>>
>> The true harm of such decision is, it encourages stupidity and laziness
>> as the default case.
>>
>
> Please try to stick to technical arguments on this mailing list, instead
> of personally attacking ("stupidity") the people who prefer a different
> outcome than you do.
>
> Jeffrey
>
> --
> 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/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com?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/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFrPe_4H2y70bpW%3DSSng%40mail.gmail.com.
--001a114c843ab927b6053772872f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The "stupidity and laziness" argument demands th=
at the programming language should contain constructs that must not be used=
, and that will act as traps for the unwary.=C2=A0 The notion that this is =
a desirable feature again seems to me so irrational that it beggars belief.=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul=
12, 2016 at 12:01 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Fut=
ure Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.=
org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><span class=3D"">On Mon, Jul 11, 2016 at 7:46 PM, =
FrankHB1989 <span dir=3D"ltr"><<a href=3D"mailto:frankhb1989@gmail.com" =
target=3D"_blank">frankhb1989@gmail.com</a>></span> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>The true harm of such decision is, i=
t encourages stupidity and laziness as the default case.</div></div></block=
quote><div><br></div></span><div>Please try to stick to technical arguments=
on this mailing list, instead of personally attacking ("stupidity&quo=
t;) the people who prefer a different outcome than you do.</div></div><br><=
/div><div class=3D"gmail_extra">Jeffrey</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" 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@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/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUG=
xHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail=
..gmail.com</a>.<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" 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/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFrP=
e_4H2y70bpW%3DSSng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZYhVTM=
LPQsPUw6RkN_hK%3DniYeFrPe_4H2y70bpW%3DSSng%40mail.gmail.com</a>.<br />
--001a114c843ab927b6053772872f--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 17:15:44 +0100
Raw View
--001a11493f96c2721f05377294b1
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 5:34 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Accepting reality should superseded all else. Reality has shown us that,
> 99% of the time, programmers assume things happen in a left-to-right order.
> Which means that your vaunted "freedom of expressiveness" is only being
> used 1% of the time.
>
If that were the case then query languages like SQL, Linq or Python
comprehensions would be an abject failure.
> C++ is a practical language, not some ivory-tower experiment. We must bow
> to reality when it is presented to us. And reality tells us, *time and
> again*, that we lose far more from undefined evaluation order than we
> gain from it. We lose time in debugging. We lose time in development. We
> lose mental time in having to think about it.
>
Reality tells us that order-dependent code is the exception; that 99% of
the time code is non-order-dependent. Any time lost dealing with unexpected
errors arising from undefined evaluation order would be lost anyway trying
to comprehend the intent of the code.
> I don't know; I find this to be quite "correct" code:
>
> auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
>
> This code is very clear: for each item in the pack, insert it at the end,
> capturing those iterators in an array. I see no reason to express this code
> in a more verbose way. Well, besides the fact that it doesn't work, but
> that's only due to a silly language rule.
>
And there is nothing in your problem specification to say that the inserts
should happen in any particular order.
> What is the "more correct" alternative? Show me how to write that same
> code in a way that is as clear and *concise* as this, which doesn't
> provoke undefined behavior.
>
auto inserts = {v.insert(v.end(), args)...};
> And if `make_array` offends you, feel free to change it into any function
> that would take a sequence of iterators.
>
I have never *seen* a function that takes a sequence of iterators. When is
such a beast ever encountered in the wild?
Also, let's not forget that, when it comes to complex expressions, C has
> *nothing* on C++. We have so many more tools to write complicated
> expressions than C does. That's why my example involved parameter packs and
> fold expressions; to me, they're the poster-child for making sequences of
> complex expressions that the user will *expect* to evaluate in order.
>
If you're writing already complicated expressions, why complicate them
further by making them order-dependent?
--
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/CAJnLdOb8TZw-1vr8rYoHTujXoHQ2MLVJVr0DBYLCXQX4_rZpsQ%40mail.gmail.com.
--001a11493f96c2721f05377294b1
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=
ue, Jul 12, 2016 at 5:34 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Accepting reality sho=
uld superseded all else. Reality has shown us that, 99% of the time, progra=
mmers assume things happen in a left-to-right order. Which means that your =
vaunted "freedom of expressiveness" is only being used 1% of the =
time.<br></div></div></blockquote><div>=C2=A0</div><div>If that were the ca=
se then query languages like SQL, Linq or Python comprehensions would be an=
abject failure.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>C++ is a practical language, not some ivory-tower experiment. We must bo=
w to reality when it is presented to us. And reality tells us, <i>time and =
again</i>, that we lose far more from undefined evaluation order than we ga=
in from it. We lose time in debugging. We lose time in development. We lose=
mental time in having to think about it.<br></div></div></blockquote><div>=
<br></div><div>Reality tells us that order-dependent code is the exception;=
that 99% of the time code is non-order-dependent. Any time lost dealing wi=
th unexpected errors arising from undefined evaluation order would be lost =
anyway trying to comprehend the intent of the code.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>I don't know; I find this to be q=
uite "correct" code:<br></div><div><span class=3D""><br><div styl=
e=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-colo=
r:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">auto</spa=
n><span style=3D"color:rgb(0,0,0)"> inserts </span><span style=3D"color:rgb=
(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> make_array</span><=
span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)=
">v</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color=
:rgb(0,0,0)">insert</span><span style=3D"color:rgb(102,102,0)">(</span><spa=
n style=3D"color:rgb(0,0,0)">v</span><span style=3D"color:rgb(102,102,0)">.=
</span><span style=3D"color:rgb(0,0,136)">end</span><span style=3D"color:rg=
b(102,102,0)">(),</span><span style=3D"color:rgb(0,0,0)"> std</span><span s=
tyle=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">for=
ward</span><span style=3D"color:rgb(102,102,0)"><</span><span style=3D"c=
olor:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102,0)">>(</s=
pan><span style=3D"color:rgb(0,0,0)">args</span><span style=3D"color:rgb(10=
2,102,0)">))...);</span></div></code></div><br></span>This code is very cle=
ar: for each item in the pack, insert it at the end, capturing those iterat=
ors in an array. I see no reason to express this code in a more verbose way=
.. Well, besides the fact that it doesn't work, but that's only due =
to a silly language rule.<br></div></div></blockquote><div><br></div><div>A=
nd there is nothing in your problem specification to say that the inserts s=
hould happen in any particular order.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
"><div dir=3D"ltr"><div>What is the "more correct" alternative? S=
how me how to write that same code in a way that is as clear and <i>concise=
</i> as this, which doesn't provoke undefined behavior.<br></div></div>=
</blockquote><div><br></div><div>auto inserts =3D {v.insert(v.end(), args).=
...};</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>And if `m=
ake_array` offends you, feel free to change it into any function that would=
take a sequence of iterators.<br></div></div></blockquote><div><br></div><=
div>I have never *seen* a function that takes a sequence of iterators. When=
is such a beast ever encountered in the wild?</div><div><br></div><div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">Also, let's not forget that, when it comes to complex exp=
ressions, C has=C2=A0<i>nothing</i>=C2=A0on C++. We have so many more tools=
to write complicated expressions than C does. That's why my example in=
volved parameter packs and fold expressions; to me, they're the poster-=
child for making sequences of complex expressions that the user will=C2=A0<=
i>expect</i>=C2=A0to evaluate in order.=C2=A0<br></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><div dir=3D"ltr"></div></blockquote></div><div><br></div><div>If you=
9;re writing already complicated expressions, why complicate them further b=
y making them order-dependent?</div></div></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/CAJnLdOb8TZw-1vr8rYoHTujXoHQ2MLVJVr0D=
BYLCXQX4_rZpsQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb8TZw-1vr8=
rYoHTujXoHQ2MLVJVr0DBYLCXQX4_rZpsQ%40mail.gmail.com</a>.<br />
--001a11493f96c2721f05377294b1--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 12:23:39 -0400
Raw View
--001a114c843a329bb2053772b27f
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 12:15 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> If you're writing already complicated expressions, why complicate them
> further by making them order-dependent?
>
Because the order should be definite, so that this is as straightforward as
depending on the ordering of statements. The notion that ambiguous order
of expression evaluation is a benefit is wrong, no matter how hard you
believe otherwise.
--
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/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGdymdMYg9hHeVHpg%40mail.gmail.com.
--001a114c843a329bb2053772b27f
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=
ue, Jul 12, 2016 at 12:15 PM, 'Edward Catmur' via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>If you're writing already complicated ex=
pressions, why complicate them further by making them order-dependent?</div=
></div></div></div></blockquote><div><br></div><div>Because the order shoul=
d be definite, so that this is as straightforward as depending on the order=
ing of statements.=C2=A0 The notion that ambiguous order of expression eval=
uation is a benefit is wrong, no matter how hard you believe otherwise.</di=
v></div></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/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGd=
ymdMYg9hHeVHpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdavQjZYLNHK=
8u4BPTq4JVKHfP5zDqGdymdMYg9hHeVHpg%40mail.gmail.com</a>.<br />
--001a114c843a329bb2053772b27f--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 17:29:01 +0100
Raw View
--001a1149dab24b281b053772c4eb
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:
>>
>> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>> >
>> > The right decision is strict left-to-right order of evaluation for all
>> expressions, with side-effects fully completed as they are evaluated.
>>
>> That sounds like a performance nightmare.
>>
>
> I've heard a lot of "sounds like" out of people defending the undefined
> order rules. I've heard far less "certainly is". Is there any genuine
> evidence of this "performance nightmare", or is it just fear of the unknown?
>
I can't speak for anyone else. In my case it is induction from observations
that many existing optimizations depend to some extent on breaking naive
intuitions of ordering.
> How many compilers actually use the undefined evaluation order rules to
> optimize code? Do they re-order expressions based on what is best for that
> specific expression? Or do they always evaluate expressions in an arbitrary
> order? Because if such flexibility is not actually making code faster, then
> the variance is pointless and should be done away with.
>
It does not matter whether compilers are currently able to exploit their
freedom. The free lunch is over. Clock speeds are not getting any faster.
If there is any prospect of the freedom being useful in future then it
should be retained until we know for sure one way or the other, especially
if new instructions could help compilers exploit it.
> > The reason for choosing strict left-to-right order is that it's trivial
>> to explain, matches the order in which code is read, and matches other
>> languages such as Java.
>>
>> Any experienced user reads code blocks as a unit, just as any proficient
>> reader of natural languages reads sentences and paragraphs in a single
>> glance.
>>
>
> Let's pretend this was true (despite the undeniable fact that "experienced
> users" make these mistakes too).
>
> So what? Are we supposed to restrict C++ to "experienced users" as you
> define it?
>
It would be better to restrict C++ to experienced users than to make it
useless to them. C++ is not in competition with Java; it is in competition
with VHDL and Verilog.
> And is making C++ more similar to Java supposed to be a *good* thing?
>>
>
> In and of itself? No. But it's not a bad thing either. A language feature
> should not be justified merely by "language X does it". But neither should
> it be dismissed for that reason either.
>
--
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/CAJnLdObKNiPtEgzqtNtw2KHkFp6X9p8C%2BbhX2xCOcJhH6kChXg%40mail.gmail.com.
--001a1149dab24b281b053772c4eb
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=
ue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<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">On Monday, J=
uly 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:<span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a rel=3D"nofollow">h=
yman...@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare.</p></blockquote></=
span><div><br>I've heard a lot of "sounds like" out of people=
defending the undefined order rules. I've heard far less "certain=
ly is". Is there any genuine evidence of this "performance nightm=
are", or is it just fear of the unknown?<br></div></div></blockquote><=
div><br></div><div>I can't speak for anyone else. In my case it is indu=
ction from observations that many existing optimizations depend to some ext=
ent on breaking naive intuitions of ordering.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>How many compilers actually u=
se the undefined evaluation order rules to optimize code? Do they re-order =
expressions based on what is best for that specific expression? Or do they =
always evaluate expressions in an arbitrary order? Because if such flexibil=
ity is not actually making code faster, then the variance is pointless and =
should be done away with.<br></div></div></blockquote><div>=C2=A0</div><div=
>It does not matter whether compilers are currently able to exploit their f=
reedom. The free lunch is over. Clock speeds are not getting any faster. If=
there is any prospect of the freedom being useful in future then it should=
be retained until we know for sure one way or the other, especially if new=
instructions could help compilers exploit it.</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div></div><span class=3D""><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance.<br></p></blockquote></span><div><br>Let's pretend this=
was true (despite the undeniable fact that "experienced users" m=
ake these mistakes too).<br><br>So what? Are we supposed to restrict C++ to=
"experienced users" as you define it?<br></div></div></blockquot=
e><div><br></div><div>It would be better to restrict C++ to experienced use=
rs than to make it useless to them. C++ is not in competition with Java; it=
is in competition with VHDL and Verilog.</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><span class=3D""><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing?<br></p></blockquote></span><div><br>In and of itself? No. But it&=
#39;s not a bad thing either. A language feature should not be justified me=
rely by "language X does it". But neither should it be dismissed =
for that reason either.</div></div></blockquote></div></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/CAJnLdObKNiPtEgzqtNtw2KHkFp6X9p8C%2Bb=
hX2xCOcJhH6kChXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObKNiPtEg=
zqtNtw2KHkFp6X9p8C%2BbhX2xCOcJhH6kChXg%40mail.gmail.com</a>.<br />
--001a1149dab24b281b053772c4eb--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 17:35:23 +0100
Raw View
--001a114038d2124051053772dbc3
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 5:23 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 12:15 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> If you're writing already complicated expressions, why complicate them
>> further by making them order-dependent?
>>
>
> Because the order should be definite, so that this is as straightforward
> as depending on the ordering of statements. The notion that ambiguous
> order of expression evaluation is a benefit is wrong, no matter how hard
> you believe otherwise.
>
Ordering of statements is straightforward, and it is that imperative subset
of the language that should be used when writing order-dependent code,
either directly or via the library. That's what it's for!
--
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/CAJnLdOZnUrDnFec64HRmpF7WP4jZFOLtT9TkzjndqTfd8UiCfw%40mail.gmail.com.
--001a114038d2124051053772dbc3
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=
ue, Jul 12, 2016 at 5:23 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>>=
;</span> wrote:<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"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue, Jul =
12, 2016 at 12:15 PM, 'Edward Catmur' via ISO C++ Standard - Future=
Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org=
" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div>If you're writing already complicated expression=
s, why complicate them further by making them order-dependent?</div></div><=
/div></div></blockquote><div><br></div></span><div>Because the order should=
be definite, so that this is as straightforward as depending on the orderi=
ng of statements.=C2=A0 The notion that ambiguous order of expression evalu=
ation is a benefit is wrong, no matter how hard you believe otherwise.</div=
></div></div></div></blockquote><div><br></div><div>Ordering of statements =
is straightforward, and it is that imperative subset of the language that s=
hould be used when writing order-dependent code, either directly or via the=
library. That's what it's for!</div></div></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/CAJnLdOZnUrDnFec64HRmpF7WP4jZFOLtT9Tk=
zjndqTfd8UiCfw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZnUrDnFec6=
4HRmpF7WP4jZFOLtT9TkzjndqTfd8UiCfw%40mail.gmail.com</a>.<br />
--001a114038d2124051053772dbc3--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 12 Jul 2016 13:03:34 -0400
Raw View
--001a1144175cdbde6a0537733f68
Content-Type: text/plain; charset=UTF-8
The fact you continually assert this without evidence as if it is fact is
what truly "beggars belief".
It is currently trivial to force a left to right ordering; simply make each
substatement its own statement, in the order you like. There is no syntax
to enforce "unordered" ordering. No one is forcing you to nest statements;
you can easily ensure your own ordering by using the current syntax.
The notion that removing expressiveness from a language is a benefit is
wrong, no matter how hard you believe otherwise...is equally valid a
statement, in that it asserts something with no actual evidence, and may
therefore be dismissed with no evidence as well.
On Tue, Jul 12, 2016 at 12:23 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 12:15 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> If you're writing already complicated expressions, why complicate them
>> further by making them order-dependent?
>>
>
> Because the order should be definite, so that this is as straightforward
> as depending on the ordering of statements. The notion that ambiguous
> order of expression evaluation is a benefit is wrong, no matter how hard
> you believe otherwise.
>
> --
> 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/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGdymdMYg9hHeVHpg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGdymdMYg9hHeVHpg%40mail.gmail.com?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/CAMD6iD-%3D_eY9gWWRzMmKY8AmaSKQOWroyVN-F4mrkUjfZvFzwQ%40mail.gmail.com.
--001a1144175cdbde6a0537733f68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The fact you continually assert this without evidence as i=
f it is fact is what truly "beggars belief".<div><br></div><div>I=
t is currently trivial to force a left to right ordering; simply make each =
substatement its own statement, in the order you like. There is no syntax t=
o enforce "unordered" ordering. No one is forcing you to nest sta=
tements; you can easily ensure your own ordering by using the current synta=
x.</div><div><br></div><div>The notion that removing expressiveness from a =
language is a benefit is wrong, no matter how hard you believe otherwise...=
is equally valid a statement, in that it asserts something with no actual e=
vidence, and may therefore be dismissed with no evidence as well.</div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 12,=
2016 at 12:23 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyma=
n.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue, Jul 12, 2016 a=
t 12:15 PM, 'Edward Catmur' via ISO C++ Standard - Future Proposals=
<span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" target=
=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>If you're writing already complicated expressions, why c=
omplicate them further by making them order-dependent?</div></div></div></d=
iv></blockquote><div><br></div></span><div>Because the order should be defi=
nite, so that this is as straightforward as depending on the ordering of st=
atements.=C2=A0 The notion that ambiguous order of expression evaluation is=
a benefit is wrong, no matter how hard you believe otherwise.</div></div><=
/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" 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@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/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGd=
ymdMYg9hHeVHpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGdymdMYg9hHeVHpg%40mail.gmail.com</=
a>.<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" 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/CAMD6iD-%3D_eY9gWWRzMmKY8AmaSKQOWroyV=
N-F4mrkUjfZvFzwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-%3D_eY9=
gWWRzMmKY8AmaSKQOWroyVN-F4mrkUjfZvFzwQ%40mail.gmail.com</a>.<br />
--001a1144175cdbde6a0537733f68--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 10:12:22 -0700
Raw View
--94eb2c0b147a6c08430537736019
Content-Type: text/plain; charset=UTF-8
You also should moderate your language. :) Most people here are rational
and not stupid, but they may value different things than you do. For
example, some people value the 4% speed improvement that
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
demonstrated a compiler could achieve on some programs by fiddling
intelligently with the evaluation order. It's not obvious to me that this
4% is worth the bugs it implies, but it's also not obvious to me that it's
not.
Please look at the technical arguments instead of calling people who
disagree with you "irrational".
On Tue, Jul 12, 2016 at 9:11 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> The "stupidity and laziness" argument demands that the programming
> language should contain constructs that must not be used, and that will act
> as traps for the unwary. The notion that this is a desirable feature again
> seems to me so irrational that it beggars belief.
>
> On Tue, Jul 12, 2016 at 12:01 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frankhb1989@gmail.com>
>> wrote:
>>>
>>> The true harm of such decision is, it encourages stupidity and laziness
>>> as the default case.
>>>
>>
>> Please try to stick to technical arguments on this mailing list, instead
>> of personally attacking ("stupidity") the people who prefer a different
>> outcome than you do.
>>
>> Jeffrey
>>
>> --
>> 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/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com?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/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFrPe_4H2y70bpW%3DSSng%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFrPe_4H2y70bpW%3DSSng%40mail.gmail.com?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/CANh-dXna4fSDWGmDFfA%3DYsoxCukY2Gp0GFqz6WaqsjQOzyBpsw%40mail.gmail.com.
--94eb2c0b147a6c08430537736019
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You also should moderate your language. :) Most people her=
e are rational and not stupid, but they may value different things than you=
do. For example, some people value the 4% speed improvement that=C2=A0<a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf"=
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf</a> de=
monstrated a compiler could achieve on some programs by fiddling intelligen=
tly with the evaluation order. It's not obvious to me that this 4% is w=
orth the bugs it implies, but it's also not obvious to me that it's=
not.<div><br></div><div>Please look at the technical arguments instead of =
calling people who disagree with you "irrational".<br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 9:1=
1 AM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyman.rosen@gmail=
..com" target=3D"_blank" class=3D"gmail-cremed cremed">hyman.rosen@gmail.com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr">The "stupidity and laziness" argument demands t=
hat the programming language should contain constructs that must not be use=
d, and that will act as traps for the unwary.=C2=A0 The notion that this is=
a desirable feature again seems to me so irrational that it beggars belief=
..</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div =
class=3D"gmail-h5">On Tue, Jul 12, 2016 at 12:01 PM, 'Jeffrey Yasskin&#=
39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank" class=3D"gmail-creme=
d cremed">std-proposals@isocpp.org</a>></span> wrote:<br></div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div><div class=3D"gmail-h5"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><sp=
an>On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <span dir=3D"ltr"><<a hr=
ef=3D"mailto:frankhb1989@gmail.com" target=3D"_blank" class=3D"gmail-cremed=
cremed">frankhb1989@gmail.com</a>></span> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div>The true harm of such deci=
sion is, it encourages stupidity and laziness as the default case.</div></d=
iv></blockquote><div><br></div></span><div>Please try to stick to technical=
arguments on this mailing list, instead of personally attacking ("stu=
pidity") the people who prefer a different outcome than you do.</div><=
/div><br></div><div class=3D"gmail_extra">Jeffrey</div></div></div></div><s=
pan>
<p></p>
-- <br><span class=3D"gmail-">
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" target=3D"_=
blank" class=3D"gmail-cremed cremed">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"gmail-cremed cremed">std-proposals@isocpp.=
org</a>.<br></span></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUG=
xHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank" class=3D"gmail-cremed cremed">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXk=
rUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com</a>.<br>
</blockquote></div><br></div><span class=3D"gmail-">
<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" target=3D"_=
blank" class=3D"gmail-cremed cremed">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"gmail-cremed cremed">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/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFrP=
e_4H2y70bpW%3DSSng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank" class=3D"gmail-cremed cremed">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFr=
Pe_4H2y70bpW%3DSSng%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></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/CANh-dXna4fSDWGmDFfA%3DYsoxCukY2Gp0GF=
qz6WaqsjQOzyBpsw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXna4fSDWG=
mDFfA%3DYsoxCukY2Gp0GFqz6WaqsjQOzyBpsw%40mail.gmail.com</a>.<br />
--94eb2c0b147a6c08430537736019--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 13:47:23 -0400
Raw View
--001a114c843aa762fd053773dd48
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> Please look at the technical arguments instead of calling people who
> disagree with you "irrational".
>
It's not a matter of technical arguments, it's a matter of values (as you
say). Science can tell you how to accomplish what you want, but it can't
tell you what to want. For me, the values involved in having a programming
language that is simply specified and deterministic and consistent far
outweigh the possible optimization benefit in letting the compiler pick
evaluation order. SImilarly, I find negative value in having unspecified
behavior in order to force programmers to be hyper-vigilant to avoid
error. I find negative value in the notion that unspecified order adds
expressiveness.
C++ can do only one thing. It cannot have evaluation order both specified
and unspecified. It cannot evaluate both the LHS and the RHS of an
assignment first. So values must necessarily come into conflict, and
battles over values are political, personal, and frequently nasty.
Besides, what constitutes a technical argument? I say that Java has strict
left-to-right evaluation, and I find that to be a technical argument -
clearly the Java designers made this a conscious choice. But others
dismiss this with "why would we want C++ to be like Java?" Or conversely,
people claim to find that some code can run 4% faster when order is not
specified, and I say that I don't care.
Ultimately, my goal is to not be silent, so that when C++ goes the wrong
(IMO) way, no one can say that this was done with the acquiescence of the
entire C++ community.
And for your amusement, or horror:
struct A { }; A f(); A g();
void operator<<(A, A);
auto shfpointer = (void(*)(A, A))&operator<<;
operator<<(f(), g()); // must evaluate f() then g()
shfpointer(f(), g()); // can evaluate f() and g() in either order
--
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/CAHSYqdZ429CvphdkgMuXpErt3HR6vC%3DaEe6ycJifYnWRaVtuUA%40mail.gmail.com.
--001a114c843aa762fd053773dd48
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=
ue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div>Please look at the technical argumen=
ts instead of calling people who disagree with you "irrational".<=
/div></div></blockquote><div><br></div><div>It's not a matter of techni=
cal arguments, it's a matter of values (as you say).=C2=A0 Science can =
tell you how to accomplish what you want, but it can't tell you what to=
want.=C2=A0 For me, the values involved in having a programming language t=
hat is simply specified and deterministic and consistent far outweigh the p=
ossible optimization benefit in letting the compiler pick evaluation order.=
=C2=A0 SImilarly, I find negative value in having unspecified behavior in o=
rder to force programmers to be hyper-vigilant to avoid error.=C2=A0 I find=
negative value in the notion that unspecified order adds expressiveness.<b=
r><br>C++ can do only one thing.=C2=A0 It cannot have evaluation order both=
specified and unspecified.=C2=A0 It cannot evaluate both the LHS and the R=
HS of an assignment first.=C2=A0 So values must necessarily come into confl=
ict, and battles over values are political, personal, and frequently nasty.=
=C2=A0 Besides, what constitutes a technical argument?=C2=A0 I say that Jav=
a has strict left-to-right evaluation, and I find that to be a technical ar=
gument - clearly the Java designers made this a conscious choice.=C2=A0 But=
others dismiss this with "why would we want C++ to be like Java?"=
; =C2=A0Or conversely, people claim to find that some code can run 4% faste=
r when order is not specified, and I say that I don't care.<br><br>Ulti=
mately, my goal is to not be silent, so that when C++ goes the wrong (IMO) =
way, no one can say that this was done with the acquiescence of the entire =
C++ community.<br><br>And for your amusement, or horror:<font face=3D"monos=
pace, monospace"><br>=C2=A0 =C2=A0 struct A { };=C2=A0A f();=C2=A0A g();<br=
>=C2=A0 =C2=A0 void operator<<(A, A);<br>=C2=A0 =C2=A0 auto=C2=A0</fo=
nt><span style=3D"font-family:monospace,monospace">shfpointer</span><font f=
ace=3D"monospace, monospace">=C2=A0=3D (void(*)(A, A))&operator<<=
;<br>=C2=A0 =C2=A0 operator<<(f(), g()); =C2=A0// must evaluate f() t=
hen g()<br>=C2=A0 =C2=A0=C2=A0</font><span style=3D"font-family:monospace,m=
onospace">shfpointer</span><font face=3D"monospace, monospace">(f(), g()); =
=C2=A0// can evaluate f() and g() in either order</font></div></div></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/CAHSYqdZ429CvphdkgMuXpErt3HR6vC%3DaEe=
6ycJifYnWRaVtuUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ429Cvph=
dkgMuXpErt3HR6vC%3DaEe6ycJifYnWRaVtuUA%40mail.gmail.com</a>.<br />
--001a114c843aa762fd053773dd48--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 19:27:50 +0100
Raw View
--94eb2c0772a238a1250537746db2
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 6:47 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> Please look at the technical arguments instead of calling people who
>> disagree with you "irrational".
>>
>
> It's not a matter of technical arguments, it's a matter of values (as you
> say). Science can tell you how to accomplish what you want, but it can't
> tell you what to want. For me, the values involved in having a programming
> language that is simply specified and deterministic and consistent far
> outweigh the possible optimization benefit in letting the compiler pick
> evaluation order.
>
We have programming languages that are simply specified and deterministic
and consistent; they just aren't called C++.
> C++ can do only one thing. It cannot have evaluation order both specified
> and unspecified. It cannot evaluate both the LHS and the RHS of an
> assignment first.
>
Absolutely it can; ask your vendor for a conforming extension.
> So values must necessarily come into conflict, and battles over values
> are political, personal, and frequently nasty. Besides, what constitutes a
> technical argument? I say that Java has strict left-to-right evaluation,
> and I find that to be a technical argument - clearly the Java designers
> made this a conscious choice.
>
What is appropriate for Java is not necessarily appropriate for C++.
> But others dismiss this with "why would we want C++ to be like Java?" Or
> conversely, people claim to find that some code can run 4% faster when
> order is not specified, and I say that I don't care.
>
But you do understand that for some people a 4% performance difference is
huge?
--
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/CAJnLdObD2%2BQV%3DpM0d%3Dqy%3D9NifrDWFZ1NTCtbjKAS315fdXjD0w%40mail.gmail.com.
--94eb2c0772a238a1250537746db2
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=
ue, Jul 12, 2016 at 6:47 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span class=3D"">On Tue, Jul 12, 2016 at 1:=
12 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals <s=
pan dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_=
blank">std-proposals@isocpp.org</a>></span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>Please look at the technical arguments instead of calling =
people who disagree with you "irrational".</div></div></blockquot=
e><div><br></div></span><div>It's not a matter of technical arguments, =
it's a matter of values (as you say).=C2=A0 Science can tell you how to=
accomplish what you want, but it can't tell you what to want.=C2=A0 Fo=
r me, the values involved in having a programming language that is simply s=
pecified and deterministic and consistent far outweigh the possible optimiz=
ation benefit in letting the compiler pick evaluation order.</div></div></d=
iv></div></blockquote><div><br></div><div><div>We have programming language=
s that are simply specified and deterministic and consistent; they just are=
n't called C++.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>C++ can=
do only one thing.=C2=A0 It cannot have evaluation order both specified an=
d unspecified.=C2=A0 It cannot evaluate both the LHS and the RHS of an assi=
gnment first.</div></div></div></div></blockquote><div><br></div><div>Absol=
utely it can; ask your vendor for a conforming extension.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div>=C2=A0 So values must necessarily come into conflict=
, and battles over values are political, personal, and frequently nasty.=C2=
=A0 Besides, what constitutes a technical argument?=C2=A0 I say that Java h=
as strict left-to-right evaluation, and I find that to be a technical argum=
ent - clearly the Java designers made this a conscious choice.</div></div><=
/div></div></blockquote><div><br></div><div>What is appropriate for Java is=
not necessarily appropriate for C++.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv> =C2=A0But others dismiss this with "why would we want C++ to be li=
ke Java?" =C2=A0Or conversely, people claim to find that some code can=
run 4% faster when order is not specified, and I say that I don't care=
..<br></div></div></div></div></blockquote><div><br></div><div>But you do un=
derstand that for some people a 4% performance difference is huge?=C2=A0</d=
iv><div>=C2=A0</div></div></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/CAJnLdObD2%2BQV%3DpM0d%3Dqy%3D9NifrDW=
FZ1NTCtbjKAS315fdXjD0w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObD=
2%2BQV%3DpM0d%3Dqy%3D9NifrDWFZ1NTCtbjKAS315fdXjD0w%40mail.gmail.com</a>.<br=
/>
--94eb2c0772a238a1250537746db2--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 21:06:35 +0200
Raw View
This is a multi-part message in MIME format.
--------------CD7276CF7527334DD930A479
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
> And there is nothing in your problem specification to say that the
> inserts should happen in any particular order.
I shouldn't have to look up the specification to know what the code is
supposed to do. This is about expectations. You with thousands of hours
of experience in C++ realized that the order is unspecified. Other
people with thousands of hours of experience in C++ do not. What matters
is what the intention of the author was and whether it matches what we
read into it. Whichever the intention was it's obviously not expressed
unambiguously. As long as the code makes the author's intentions
ambiguous it is not a win for code clarity.
> And there is nothing in your problem specification to say that the
> inserts should happen in any particular order.
>
> What is the "more correct" alternative? Show me how to write that
> same code in a way that is as clear and /concise/ as this, which
> doesn't provoke undefined behavior.
>
>
> auto inserts = {v.insert(v.end(), args)...};
That makes it an initializer_list, meaning the values are const, meaning
you cannot move them out.
Just saying.
> If you're writing already complicated expressions, why complicate them
> further by making them order-dependent?
No system becomes more complicated or harder to understand by removing
degrees of freedom.
--
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/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%40gmail.com.
--------------CD7276CF7527334DD930A479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Standard
- Future Proposals:<br>
<blockquote type=3D"cite">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.</blockquote>
I shouldn't have to look up the specification to know what the code
is supposed to do. This is about expectations. You with thousands of
hours of experience in C++ realized that the order is unspecified.
Other people with thousands of hours of experience in C++ do not.
What matters is what the intention of the author was and whether it
matches what we read into it. Whichever the intention was it's
obviously not expressed unambiguously. As long as the code makes the
author's intentions ambiguous it is not a win for code clarity.<br>
<br>
<blockquote
cite=3D"mid:CAJnLdOb8TZw-1vr8rYoHTujXoHQ2MLVJVr0DBYLCXQX4_rZpsQ@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div>What is the "more correct" alternative? Show me how
to write that same code in a way that is as clear and
<i>concise</i> as this, which doesn't provoke
undefined behavior.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>auto inserts =3D {v.insert(v.end(), args)...};</div>
</div>
</div>
</div>
</blockquote>
That makes it an initializer_list, meaning the values are const,
meaning you cannot move them out.<br>
Just saying.<br>
<br>
<blockquote type=3D"cite">If you're writing already complicated
expressions, why complicate them further by making them
order-dependent?</blockquote>
No system becomes more complicated or harder to understand by
removing degrees of freedom.<br>
<br>
</body>
</html>
<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/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%=
40gmail.com</a>.<br />
--------------CD7276CF7527334DD930A479--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 21:21:00 +0200
Raw View
Am 12.07.2016 um 19:03 schrieb Ren Industries:
> The fact you continually assert this without evidence as if it is fact
> is what truly "beggars belief".
People also constantly assert without evidence that this is somehow
"removing expresiveness" from the language. I have asked in the past and
now again for code examples that clearly, without doubt, expresses that
the author's intention was *deliberately* for code to be
order-independent and not just a lucky side effect of how the language
works. And by example I do not mean "I just wrote an expression and it
happens to not depend on order of evaluation". No, I mean "I wrote this
expression and I *intentionally* require it to be order independent
because the future of the universe depends on it".
>
> It is currently trivial to force a left to right ordering; simply make
> each substatement its own statement, in the order you like. There is
> no syntax to enforce "unordered" ordering. No one is forcing you to
> nest statements; you can easily ensure your own ordering by using the
> current syntax.
>
> The notion that removing expressiveness from a language is a benefit
> is wrong, no matter how hard you believe otherwise...is equally valid
> a statement, in that it asserts something with no actual evidence, and
> may therefore be dismissed with no evidence as well.
How many people use this expressiveness to express their intention in
such a way that every reader of the code unambiguously understands their
intention?
Fact is human brains are very bad at doing (or imagining) multiple
things happening at the same time which is why multithreading is such a
hard problem. It is easier to go through something step by step than
jumping around wildly or even doing things in parallel. Having a fixed
order makes it easier to understand the solution because we can begin at
one determined side of the expression and go through it one step at a time.
--
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/c230a40c-6c47-3af8-543c-5c45c301b6d3%40gmail.com.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 20:23:21 +0100
Raw View
--001a114e710ac350bf0537753376
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 8:06 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Standard -
> Future Proposals:
>
> And there is nothing in your problem specification to say that the inserts
> should happen in any particular order.
>
> I shouldn't have to look up the specification to know what the code is
> supposed to do.
>
Not the specification of the C++ Standard; the specification of the
problem. As stated by Nicol Bolas, the problem did not specify that the
inserts should happen in the order of increasing indices into the parameter
pack.
> What matters is what the intention of the author was and whether it
> matches what we read into it. Whichever the intention was it's obviously
> not expressed unambiguously. As long as the code makes the author's
> intentions ambiguous it is not a win for code clarity.
>
If the intent of the code is not obvious to a reader, it will also not be
obvious to a maintainer; which is why this touches on refactoring and other
maintenance tasks as well as performance and compatibility.
> auto inserts = {v.insert(v.end(), args)...};
>
> That makes it an initializer_list, meaning the values are const, meaning
> you cannot move them out.
> Just saying.
>
Moving iterators?
> If you're writing already complicated expressions, why complicate them
> further by making them order-dependent?
>
> No system becomes more complicated or harder to understand by removing
> degrees of freedom.
>
Try tying a knot in 4 dimensions.
--
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/CAJnLdOYJCWP0%3Dj-BLemhfwOS2bzQiL8RGhGWrU1yHArDQgLMMw%40mail.gmail.com.
--001a114e710ac350bf0537753376
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=
ue, Jul 12, 2016 at 8:06 PM, Miro Knejp <span dir=3D"ltr"><<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Stan=
dard
- Future Proposals:<br>
<blockquote type=3D"cite">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.</blockquote>
I shouldn't have to look up the specification to know what the code
is supposed to do.</div></blockquote><div><br></div><div>Not the specif=
ication of the C++ Standard; the specification of the problem. As stated by=
Nicol Bolas, the problem did not specify that the inserts should happen in=
the order of increasing indices into the parameter pack.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#00000=
0">What matters is what the intention of the author was and whether it
matches what we read into it. Whichever the intention was it's
obviously not expressed unambiguously. As long as the code makes the
author's intentions ambiguous it is not a win for code clarity.<br>=
</div></blockquote><div><br></div><div>If the intent of the code is not obv=
ious to a reader, it will also not be obvious to a maintainer; which is why=
this touches on refactoring and other maintenance tasks as well as perform=
ance and compatibility.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div>auto inserts =3D {v.insert(v.end(), args)...};</div>
</div>
</div>
</div>
</blockquote>
That makes it an initializer_list, meaning the values are const,
meaning you cannot move them out.<br>
Just saying.<br></div></blockquote><div><br></div><div>=C2=A0Moving ite=
rators?</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
<blockquote type=3D"cite">If you're writing already complicated
expressions, why complicate them further by making them
order-dependent?</blockquote>
No system becomes more complicated or harder to understand by
removing degrees of freedom.</div></blockquote><div><br></div><div>=C2=
=A0Try tying a knot in 4 dimensions.</div></div></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/CAJnLdOYJCWP0%3Dj-BLemhfwOS2bzQiL8RGh=
GWrU1yHArDQgLMMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYJCWP0%3=
Dj-BLemhfwOS2bzQiL8RGhGWrU1yHArDQgLMMw%40mail.gmail.com</a>.<br />
--001a114e710ac350bf0537753376--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 12 Jul 2016 15:31:11 -0400
Raw View
--001a11414c54c0a3520537754fd5
Content-Type: text/plain; charset=UTF-8
I have not asserted without evidence that it removes expressiveness; I have
stated, below that very assertion, the evidence. It is indisputable that
you are removing the ability to do something; that's the very point of what
you wish to do.
The fact you have asked for a higher burden of proof is meaningless; you
are moving goal posts, which is intellectually dishonest.
You may consider the higher goal post more meaningful; that's fine. But
I've clearly met the lower goal post that you then claimed I have not met.
On Tue, Jul 12, 2016 at 3:21 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> Am 12.07.2016 um 19:03 schrieb Ren Industries:
>
>> The fact you continually assert this without evidence as if it is fact is
>> what truly "beggars belief".
>>
> People also constantly assert without evidence that this is somehow
> "removing expresiveness" from the language. I have asked in the past and
> now again for code examples that clearly, without doubt, expresses that the
> author's intention was *deliberately* for code to be order-independent and
> not just a lucky side effect of how the language works. And by example I do
> not mean "I just wrote an expression and it happens to not depend on order
> of evaluation". No, I mean "I wrote this expression and I *intentionally*
> require it to be order independent because the future of the universe
> depends on it".
>
>>
>> It is currently trivial to force a left to right ordering; simply make
>> each substatement its own statement, in the order you like. There is no
>> syntax to enforce "unordered" ordering. No one is forcing you to nest
>> statements; you can easily ensure your own ordering by using the current
>> syntax.
>>
>> The notion that removing expressiveness from a language is a benefit is
>> wrong, no matter how hard you believe otherwise...is equally valid a
>> statement, in that it asserts something with no actual evidence, and may
>> therefore be dismissed with no evidence as well.
>>
> How many people use this expressiveness to express their intention in such
> a way that every reader of the code unambiguously understands their
> intention?
>
> Fact is human brains are very bad at doing (or imagining) multiple things
> happening at the same time which is why multithreading is such a hard
> problem. It is easier to go through something step by step than jumping
> around wildly or even doing things in parallel. Having a fixed order makes
> it easier to understand the solution because we can begin at one determined
> side of the expression and go through it one step at a time.
>
> --
> 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/c230a40c-6c47-3af8-543c-5c45c301b6d3%40gmail.com
> .
>
--
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/CAMD6iD_qfKmZBgjUQ7a9iZcsUzzCBLW-_%2B9secHbAOsJ8Jbc_Q%40mail.gmail.com.
--001a11414c54c0a3520537754fd5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have not asserted without evidence that it removes expre=
ssiveness; I have stated, below that very assertion, the evidence. It is in=
disputable that you are removing the ability to do something; that's th=
e very point of what you wish to do.<div><br></div><div>The fact you have a=
sked for a higher burden of proof is meaningless; you are moving goal posts=
, which is intellectually dishonest.</div><div><br></div><div>You may consi=
der the higher goal post more meaningful; that's fine. But I've cle=
arly met the lower goal post that you then claimed I have not met.=C2=A0</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, =
Jul 12, 2016 at 3:21 PM, Miro Knejp <span dir=3D"ltr"><<a href=3D"mailto=
:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Am 12.07.2016 u=
m 19:03 schrieb Ren Industries:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The fact you continually assert this without evidence as if it is fact is w=
hat truly "beggars belief".<br>
</blockquote></span>
People also constantly assert without evidence that this is somehow "r=
emoving expresiveness" from the language. I have asked in the past and=
now again for code examples that clearly, without doubt, expresses that th=
e author's intention was *deliberately* for code to be order-independen=
t and not just a lucky side effect of how the language works. And by exampl=
e I do not mean "I just wrote an expression and it happens to not depe=
nd on order of evaluation". No, I mean "I wrote this expression a=
nd I *intentionally* require it to be order independent because the future =
of the universe depends on it".<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
It is currently trivial to force a left to right ordering; simply make each=
substatement its own statement, in the order you like. There is no syntax =
to enforce "unordered" ordering. No one is forcing you to nest st=
atements; you can easily ensure your own ordering by using the current synt=
ax.<br>
<br>
The notion that removing expressiveness from a language is a benefit is wro=
ng, no matter how hard you believe otherwise...is equally valid a statement=
, in that it asserts something with no actual evidence, and may therefore b=
e dismissed with no evidence as well.<br>
</blockquote></span>
How many people use this expressiveness to express their intention in such =
a way that every reader of the code unambiguously understands their intenti=
on?<br>
<br>
Fact is human brains are very bad at doing (or imagining) multiple things h=
appening at the same time which is why multithreading is such a hard proble=
m. It is easier to go through something step by step than jumping around wi=
ldly or even doing things in parallel. Having a fixed order makes it easier=
to understand the solution because we can begin at one determined side of =
the expression and go through it one step at a time.<span class=3D""><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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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/c230a40c-6c47-3af8-543c-5c45c301b6d3%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/c230a40c-6c47-3af8-543c-5c45c301b6d3%40=
gmail.com</a>.<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" 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/CAMD6iD_qfKmZBgjUQ7a9iZcsUzzCBLW-_%2B=
9secHbAOsJ8Jbc_Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_qfKmZBg=
jUQ7a9iZcsUzzCBLW-_%2B9secHbAOsJ8Jbc_Q%40mail.gmail.com</a>.<br />
--001a11414c54c0a3520537754fd5--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 12 Jul 2016 15:31:59 -0400
Raw View
--001a11397e2a98519a0537755242
Content-Type: text/plain; charset=UTF-8
Complex numbers disagree; removing the degree of freedom there strictly
makes it more difficult to comprehend.
On Tue, Jul 12, 2016 at 3:06 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Standard -
> Future Proposals:
>
> And there is nothing in your problem specification to say that the inserts
> should happen in any particular order.
>
> I shouldn't have to look up the specification to know what the code is
> supposed to do. This is about expectations. You with thousands of hours of
> experience in C++ realized that the order is unspecified. Other people with
> thousands of hours of experience in C++ do not. What matters is what the
> intention of the author was and whether it matches what we read into it.
> Whichever the intention was it's obviously not expressed unambiguously. As
> long as the code makes the author's intentions ambiguous it is not a win
> for code clarity.
>
> And there is nothing in your problem specification to say that the inserts
> should happen in any particular order.
>
>
>> What is the "more correct" alternative? Show me how to write that same
>> code in a way that is as clear and *concise* as this, which doesn't
>> provoke undefined behavior.
>>
>
> auto inserts = {v.insert(v.end(), args)...};
>
> That makes it an initializer_list, meaning the values are const, meaning
> you cannot move them out.
> Just saying.
>
> If you're writing already complicated expressions, why complicate them
> further by making them order-dependent?
>
> No system becomes more complicated or harder to understand by removing
> degrees of freedom.
>
> --
> 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/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%40gmail.com?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/CAMD6iD9EWQp%2BapQ2HCWp5yYwXHNth%2BzG3P7Gdsai6qqRtC5uOA%40mail.gmail.com.
--001a11397e2a98519a0537755242
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Complex numbers disagree; removing the degree of freedom t=
here strictly makes it more difficult to comprehend.</div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 3:06 PM, M=
iro Knejp <span dir=3D"ltr"><<a href=3D"mailto:miro.knejp@gmail.com" tar=
get=3D"_blank">miro.knejp@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Stan=
dard
- Future Proposals:<br>
<blockquote type=3D"cite">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.</blockquote></span>
I shouldn't have to look up the specification to know what the code
is supposed to do. This is about expectations. You with thousands of
hours of experience in C++ realized that the order is unspecified.
Other people with thousands of hours of experience in C++ do not.
What matters is what the intention of the author was and whether it
matches what we read into it. Whichever the intention was it's
obviously not expressed unambiguously. As long as the code makes the
author's intentions ambiguous it is not a win for code clarity.<spa=
n class=3D""><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div dir=3D"ltr">
<div>What is the "more correct" alternative? Show=
me how
to write that same code in a way that is as clear and
<i>concise</i> as this, which doesn't provoke
undefined behavior.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>auto inserts =3D {v.insert(v.end(), args)...};</div>
</div>
</div>
</div>
</blockquote></span>
That makes it an initializer_list, meaning the values are const,
meaning you cannot move them out.<br>
Just saying.<span class=3D""><br>
<br>
<blockquote type=3D"cite">If you're writing already complicated
expressions, why complicate them further by making them
order-dependent?</blockquote></span>
No system becomes more complicated or harder to understand by
removing degrees of freedom.<br>
<br>
</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" 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@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/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4ddc5467-9d40-8=
7ad-fca9-dd61e4bc6ec9%40gmail.com</a>.<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" 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/CAMD6iD9EWQp%2BapQ2HCWp5yYwXHNth%2BzG=
3P7Gdsai6qqRtC5uOA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9EWQp%=
2BapQ2HCWp5yYwXHNth%2BzG3P7Gdsai6qqRtC5uOA%40mail.gmail.com</a>.<br />
--001a11397e2a98519a0537755242--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 20:33:34 +0100
Raw View
--001a114c8f584985eb05377558ae
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 8:21 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> Am 12.07.2016 um 19:03 schrieb Ren Industries:
>
>> The fact you continually assert this without evidence as if it is fact is
>> what truly "beggars belief".
>>
> People also constantly assert without evidence that this is somehow
> "removing expresiveness" from the language. I have asked in the past and
> now again for code examples that clearly, without doubt, expresses that the
> author's intention was *deliberately* for code to be order-independent and
> not just a lucky side effect of how the language works. And by example I do
> not mean "I just wrote an expression and it happens to not depend on order
> of evaluation". No, I mean "I wrote this expression and I *intentionally*
> require it to be order independent because the future of the universe
> depends on it".
>
Any time anyone has written code to use the parallel mode extensions of
libstdc++.
> Fact is human brains are very bad at doing (or imagining) multiple things
> happening at the same time which is why multithreading is such a hard
> problem. It is easier to go through something step by step than jumping
> around wildly or even doing things in parallel. Having a fixed order makes
> it easier to understand the solution because we can begin at one determined
> side of the expression and go through it one step at a time.
We're going to have to get better at it, because the 4GHz clock limit isn't
going away any time soon. I don't want to see C++ lose a natural way to
express soft parallelism because of poor choices made by programmers who
still remember the era of the free lunch.
--
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/CAJnLdOYbgrK5E75TyFxoVuV0iTc08pXD6Bmvk5jUyK2woxfAOA%40mail.gmail.com.
--001a114c8f584985eb05377558ae
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=
ue, Jul 12, 2016 at 8:21 PM, Miro Knejp <span dir=3D"ltr"><<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Am 12.07.2016 um 19:03 schri=
eb Ren Industries:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The fact you continually assert this without evidence as if it is fact is w=
hat truly "beggars belief".<br>
</blockquote>
People also constantly assert without evidence that this is somehow "r=
emoving expresiveness" from the language. I have asked in the past and=
now again for code examples that clearly, without doubt, expresses that th=
e author's intention was *deliberately* for code to be order-independen=
t and not just a lucky side effect of how the language works. And by exampl=
e I do not mean "I just wrote an expression and it happens to not depe=
nd on order of evaluation". No, I mean "I wrote this expression a=
nd I *intentionally* require it to be order independent because the future =
of the universe depends on it".<br></blockquote><div><br></div><div>An=
y time anyone has written code to use the parallel mode extensions of libst=
dc++.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fact is human brains are very bad at doing (or imagining) multiple things h=
appening at the same time which is why multithreading is such a hard proble=
m. It is easier to go through something step by step than jumping around wi=
ldly or even doing things in parallel. Having a fixed order makes it easier=
to understand the solution because we can begin at one determined side of =
the expression and go through it one step at a time.</blockquote><div><br><=
/div><div>We're going to have to get better at it, because the 4GHz clo=
ck limit isn't going away any time soon. I don't want to see C++ lo=
se a natural way to express soft parallelism because of poor choices made b=
y programmers who still remember the era of the free lunch.</div></div></di=
v></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/CAJnLdOYbgrK5E75TyFxoVuV0iTc08pXD6Bmv=
k5jUyK2woxfAOA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYbgrK5E75T=
yFxoVuV0iTc08pXD6Bmvk5jUyK2woxfAOA%40mail.gmail.com</a>.<br />
--001a114c8f584985eb05377558ae--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 21:43:51 +0200
Raw View
This is a multi-part message in MIME format.
--------------5221F8B89A5A5E6443E19830
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 21:33 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
> On Tue, Jul 12, 2016 at 8:21 PM, Miro Knejp <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
>
> Am 12.07.2016 um 19:03 schrieb Ren Industries:
>
> The fact you continually assert this without evidence as if it
> is fact is what truly "beggars belief".
>
> People also constantly assert without evidence that this is
> somehow "removing expresiveness" from the language. I have asked
> in the past and now again for code examples that clearly, without
> doubt, expresses that the author's intention was *deliberately*
> for code to be order-independent and not just a lucky side effect
> of how the language works. And by example I do not mean "I just
> wrote an expression and it happens to not depend on order of
> evaluation". No, I mean "I wrote this expression and I
> *intentionally* require it to be order independent because the
> future of the universe depends on it".
>
>
> Any time anyone has written code to use the parallel mode extensions
> of libstdc++.
Where you don't paralellize the evaluation of arguments to an algorithm
but the algorithm itself, after the arguments have been evaluated so I
don't see how this relates to evaluation order of subexpressions unless
there is a part of the extension I'm missing.
>
> Fact is human brains are very bad at doing (or imagining) multiple
> things happening at the same time which is why multithreading is
> such a hard problem. It is easier to go through something step by
> step than jumping around wildly or even doing things in parallel.
> Having a fixed order makes it easier to understand the solution
> because we can begin at one determined side of the expression and
> go through it one step at a time.
>
>
> We're going to have to get better at it, because the 4GHz clock limit
> isn't going away any time soon. I don't want to see C++ lose a natural
> way to express soft parallelism because of poor choices made by
> programmers who still remember the era of the free lunch.
I certainly do wish evolution would pick up the pace.
--
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/9c37996c-b3ff-62f1-6d8e-41f2e13f31d9%40gmail.com.
--------------5221F8B89A5A5E6443E19830
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 21:33 schrieb 'Edward Catmur' via ISO C++ Standard
- Future Proposals:<br>
<blockquote
cite=3D"mid:CAJnLdOYbgrK5E75TyFxoVuV0iTc08pXD6Bmvk5jUyK2woxfAOA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 8:21 PM, Miro
Knejp <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro=
..knejp@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Am
12.07.2016 um 19:03 schrieb Ren Industries:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
The fact you continually assert this without evidence as
if it is fact is what truly "beggars belief".<br>
</blockquote>
People also constantly assert without evidence that this
is somehow "removing expresiveness" from the language. I
have asked in the past and now again for code examples
that clearly, without doubt, expresses that the author's
intention was *deliberately* for code to be
order-independent and not just a lucky side effect of how
the language works. And by example I do not mean "I just
wrote an expression and it happens to not depend on order
of evaluation". No, I mean "I wrote this expression and I
*intentionally* require it to be order independent because
the future of the universe depends on it".<br>
</blockquote>
<div><br>
</div>
<div>Any time anyone has written code to use the parallel
mode extensions of libstdc++.</div>
</div>
</div>
</div>
</blockquote>
Where you don't paralellize the evaluation of arguments to an
algorithm but the algorithm itself, after the arguments have been
evaluated so I don't see how this relates to evaluation order of
subexpressions unless there is a part of the extension I'm missing.<br>
<blockquote
cite=3D"mid:CAJnLdOYbgrK5E75TyFxoVuV0iTc08pXD6Bmvk5jUyK2woxfAOA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Fact is human brains are very bad at doing (or imagining)
multiple things happening at the same time which is why
multithreading is such a hard problem. It is easier to go
through something step by step than jumping around wildly
or even doing things in parallel. Having a fixed order
makes it easier to understand the solution because we can
begin at one determined side of the expression and go
through it one step at a time.</blockquote>
<div><br>
</div>
<div>We're going to have to get better at it, because the
4GHz clock limit isn't going away any time soon. I don't
want to see C++ lose a natural way to express soft
parallelism because of poor choices made by programmers
who still remember the era of the free lunch.</div>
</div>
</div>
</div>
</blockquote>
I certainly do wish evolution would pick up the pace.<br>
</body>
</html>
<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/9c37996c-b3ff-62f1-6d8e-41f2e13f31d9%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9c37996c-b3ff-62f1-6d8e-41f2e13f31d9%=
40gmail.com</a>.<br />
--------------5221F8B89A5A5E6443E19830--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 21:48:34 +0200
Raw View
Am 12.07.2016 um 21:31 schrieb Ren Industries:
> I have not asserted without evidence that it removes expressiveness; I
> have stated, below that very assertion, the evidence. It is
> indisputable that you are removing the ability to do something; that's
> the very point of what you wish to do.
>
> The fact you have asked for a higher burden of proof is meaningless;
> you are moving goal posts, which is intellectually dishonest.
>
> You may consider the higher goal post more meaningful; that's fine.
> But I've clearly met the lower goal post that you then claimed I have
> not met.
I do not deny that the change is removing a degree of freedom. We are
assessing it's value here and whether it's worth keeping compared to the
problems it makes people run into repeatedly. What I am asking for is an
example where that expresiveness is used in such a way that it is
itentional by the author, necessary for the correctness of the code, and
*unambiguous* to the reader what the author's intention was.
--
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/465e6885-6199-3839-3526-5b00738f31b2%40gmail.com.
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 21:52:36 +0200
Raw View
This is a multi-part message in MIME format.
--------------E0D0BD25632F52F5DF8C8010
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 18:29 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
> On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmckesson@gmail.com
> <mailto:jmckesson@gmail.com>> wrote:
>
> On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:
>
> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com>
> wrote:
> >
> > The right decision is strict left-to-right order of
> evaluation for all expressions, with side-effects fully
> completed as they are evaluated.
>
> That sounds like a performance nightmare.
>
>
> I've heard a lot of "sounds like" out of people defending the
> undefined order rules. I've heard far less "certainly is". Is
> there any genuine evidence of this "performance nightmare", or is
> it just fear of the unknown?
>
>
> I can't speak for anyone else. In my case it is induction from
> observations that many existing optimizations depend to some extent on
> breaking naive intuitions of ordering.
>
> How many compilers actually use the undefined evaluation order
> rules to optimize code? Do they re-order expressions based on what
> is best for that specific expression? Or do they always evaluate
> expressions in an arbitrary order? Because if such flexibility is
> not actually making code faster, then the variance is pointless
> and should be done away with.
>
> It does not matter whether compilers are currently able to exploit
> their freedom. The free lunch is over. Clock speeds are not getting
> any faster. If there is any prospect of the freedom being useful in
> future then it should be retained until we know for sure one way or
> the other, especially if new instructions could help compilers exploit it.
And when would that be? When will people stop saying "but in X years
compilers might exploit it" when they still don't do it?
This discussion is all about weighing benefits versus drawbacks. If it
was purely objective, and our brains more reliable, this exchange
wouldn't exist.
--
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/92b580e5-94ab-5bf4-d1d3-fb5d583e406d%40gmail.com.
--------------E0D0BD25632F52F5DF8C8010
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 18:29 schrieb 'Edward Catmur' via ISO C++ Standard
- Future Proposals:<br>
<blockquote
cite=3D"mid:CAJnLdObKNiPtEgzqtNtw2KHkFp6X9p8C+bhX2xCOcJhH6kChXg@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 6:12 AM,
Nicol Bolas <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>></span>
wrote:<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">On Monday, July 11, 2016 at 8:27:41 PM
UTC-4, Edward Catmur wrote:<span class=3D"">
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px
#ccc solid;padding-left:1ex">
<p dir=3D"ltr">
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a
moz-do-not-send=3D"true" rel=3D"nofollow">hyman...@=
gmail.com</a>>
wrote:<br>
><br>
> The right decision is strict left-to-right
order of evaluation for all expressions, with
side-effects fully completed as they are
evaluated.</p>
<p dir=3D"ltr">That sounds like a performance
nightmare.</p>
</blockquote>
</span>
<div><br>
I've heard a lot of "sounds like" out of people
defending the undefined order rules. I've heard far
less "certainly is". Is there any genuine evidence of
this "performance nightmare", or is it just fear of
the unknown?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I can't speak for anyone else. In my case it is
induction from observations that many existing
optimizations depend to some extent on breaking naive
intuitions of ordering.</div>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>How many compilers actually use the undefined
evaluation order rules to optimize code? Do they
re-order expressions based on what is best for that
specific expression? Or do they always evaluate
expressions in an arbitrary order? Because if such
flexibility is not actually making code faster, then
the variance is pointless and should be done away
with.<br>
</div>
</div>
</blockquote>
<div>=C2=A0</div>
<div>It does not matter whether compilers are currently able
to exploit their freedom. The free lunch is over. Clock
speeds are not getting any faster. If there is any
prospect of the freedom being useful in future then it
should be retained until we know for sure one way or the
other, especially if new instructions could help compilers
exploit it.</div>
</div>
</div>
</div>
</blockquote>
And when would that be? When will people stop saying "but in X years
compilers might exploit it" when they still don't do it?<br>
This discussion is all about weighing benefits versus drawbacks. If
it was purely objective, and our brains more reliable, this exchange
wouldn't exist.<br>
</body>
</html>
<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/92b580e5-94ab-5bf4-d1d3-fb5d583e406d%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/92b580e5-94ab-5bf4-d1d3-fb5d583e406d%=
40gmail.com</a>.<br />
--------------E0D0BD25632F52F5DF8C8010--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 13:03:34 -0700
Raw View
--001a11402c7ab24f97053775c43b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 12, 2016 at 10:47 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote=
:
> On Tue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> Please look at the technical arguments instead of calling people who
>> disagree with you "irrational".
>>
>
> It's not a matter of technical arguments, it's a matter of values (as you
> say). Science can tell you how to accomplish what you want, but it can't
> tell you what to want. For me, the values involved in having a programmi=
ng
> language that is simply specified and deterministic and consistent far
> outweigh the possible optimization benefit in letting the compiler pick
> evaluation order. SImilarly, I find negative value in having unspecified
> behavior in order to force programmers to be hyper-vigilant to avoid
> error. I find negative value in the notion that unspecified order adds
> expressiveness.
>
> C++ can do only one thing. It cannot have evaluation order both specifie=
d
> and unspecified. It cannot evaluate both the LHS and the RHS of an
> assignment first. So values must necessarily come into conflict, and
> battles over values are political, personal, and frequently nasty.
>
Political's fine (although it's nice to avoid it when possible), but
personal and nasty aren't. Thanks for this last email which is totally
respectful and makes good points.
> Besides, what constitutes a technical argument? I say that Java has
> strict left-to-right evaluation, and I find that to be a technical argume=
nt
> - clearly the Java designers made this a conscious choice. But others
> dismiss this with "why would we want C++ to be like Java?" Or conversely=
,
> people claim to find that some code can run 4% faster when order is not
> specified, and I say that I don't care.
>
I'd call them both good technical arguments, which folks are valuing
differently.
Ultimately, my goal is to not be silent, so that when C++ goes the wrong
> (IMO) way, no one can say that this was done with the acquiescence of the
> entire C++ community.
>
> And for your amusement, or horror:
> struct A { }; A f(); A g();
> void operator<<(A, A);
> auto shfpointer =3D (void(*)(A, A))&operator<<;
> operator<<(f(), g()); // must evaluate f() then g()
> shfpointer(f(), g()); // can evaluate f() and g() in either order
>
If I'm reading
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
correctly (=C2=A76.4), it's only "f() << g()" that gets the sequenced-befor=
e
edge. "operator<<(f(), g())" is written like a function call and so
doesn't. You're welcome to retarget your horror to that difference. ;-)
Jeffrey
--=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/CANh-dXmMR0s%2BS0BFHc8Og%3DTx%3D_x5-TbsbjDcBpMA%=
3DMAw1Oag2w%40mail.gmail.com.
--001a11402c7ab24f97053775c43b
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=
ue, Jul 12, 2016 at 10:47 AM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"=
mailto:hyman.rosen@gmail.com" target=3D"_blank" class=3D"gmail-cremed gmail=
-cremed gmail-cremed cremed">hyman.rosen@gmail.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gmail-">On Tu=
e, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank" class=3D"gmail-cremed gmail-cremed gmail-cremed=
cremed">std-proposals@isocpp.org</a>></span> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Please look at the tech=
nical arguments instead of calling people who disagree with you "irrat=
ional".</div></div></blockquote><div><br></div></span><div>It's no=
t a matter of technical arguments, it's a matter of values (as you say)=
..=C2=A0 Science can tell you how to accomplish what you want, but it can=
9;t tell you what to want.=C2=A0 For me, the values involved in having a pr=
ogramming language that is simply specified and deterministic and consisten=
t far outweigh the possible optimization benefit in letting the compiler pi=
ck evaluation order.=C2=A0 SImilarly, I find negative value in having unspe=
cified behavior in order to force programmers to be hyper-vigilant to avoid=
error.=C2=A0 I find negative value in the notion that unspecified order ad=
ds expressiveness.<br><br>C++ can do only one thing.=C2=A0 It cannot have e=
valuation order both specified and unspecified.=C2=A0 It cannot evaluate bo=
th the LHS and the RHS of an assignment first.=C2=A0 So values must necessa=
rily come into conflict, and battles over values are political, personal, a=
nd frequently nasty.=C2=A0</div></div></div></div></blockquote><div><br></d=
iv><div>Political's fine (although it's nice to avoid it when possi=
ble), but personal and nasty aren't. Thanks for this last email which i=
s totally respectful and makes good points.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div> Besides, what constitutes a tech=
nical argument?=C2=A0 I say that Java has strict left-to-right evaluation, =
and I find that to be a technical argument - clearly the Java designers mad=
e this a conscious choice.=C2=A0 But others dismiss this with "why wou=
ld we want C++ to be like Java?" =C2=A0Or conversely, people claim to =
find that some code can run 4% faster when order is not specified, and I sa=
y that I don't care.<br></div></div></div></div></blockquote><div><br><=
/div><div>I'd call them both good technical arguments, which folks are =
valuing differently.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>Ultimately, my goal is to not be silent, so that when C++ =
goes the wrong (IMO) way, no one can say that this was done with the acquie=
scence of the entire C++ community.<br><br>And for your amusement, or horro=
r:<font face=3D"monospace, monospace"><br>=C2=A0 =C2=A0 struct A { };=C2=A0=
A f();=C2=A0A g();<br>=C2=A0 =C2=A0 void operator<<(A, A);<br>=C2=A0 =
=C2=A0 auto=C2=A0</font><span style=3D"font-family:monospace,monospace">shf=
pointer</span><font face=3D"monospace, monospace">=C2=A0=3D (void(*)(A, A))=
&operator<<;<br>=C2=A0 =C2=A0 operator<<(f(), g()); =C2=A0/=
/ must evaluate f() then g()<br>=C2=A0 =C2=A0=C2=A0</font><span style=3D"fo=
nt-family:monospace,monospace">shfpointer</span><font face=3D"monospace, mo=
nospace">(f(), g()); =C2=A0// can evaluate f() and g() in either order</fon=
t></div></div></div></div></blockquote><div></div></div><br></div><div clas=
s=3D"gmail_extra">If I'm reading=C2=A0<a href=3D"http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf">http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2016/p0145r2.pdf</a> correctly (=C2=A76.4), it's=
only "f() << g()" that gets the sequenced-before edge. &qu=
ot;operator<<(f(), g())" is written like a function call and so =
doesn't. You're welcome to retarget your horror to that difference.=
;-)</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">J=
effrey</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/CANh-dXmMR0s%2BS0BFHc8Og%3DTx%3D_x5-T=
bsbjDcBpMA%3DMAw1Oag2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmM=
R0s%2BS0BFHc8Og%3DTx%3D_x5-TbsbjDcBpMA%3DMAw1Oag2w%40mail.gmail.com</a>.<br=
/>
--001a11402c7ab24f97053775c43b--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 12 Jul 2016 15:10:03 -0500
Raw View
--001a113efc00125c4f053775dd15
Content-Type: text/plain; charset=UTF-8
On 12 July 2016 at 14:21, Miro Knejp <miro.knejp@gmail.com> wrote:
> People also constantly assert without evidence that this is somehow
> "removing expresiveness" from the language. I have asked in the past and
> now again for code examples that clearly, without doubt, expresses that the
> author's intention was *deliberately* for code to be order-independent and
> not just a lucky side effect of how the language works. And by example I do
> not mean "I just wrote an expression and it happens to not depend on order
> of evaluation". No, I mean "I wrote this expression and I *intentionally*
> require it to be order independent because the future of the universe
> depends on it".
When you compile, do you ever turn on optimizations? If so, why, as they
are known to make buggy code less deterministic.
I want the correct code I write to be as fast as possible.
I call code that is accidentally dependent on the order of evaluation a
bug. You want to call it a feature. If it is a feature people will write
both deliberate code and accidental code that takes advantage of it, since
it is impossible to tell the difference between the two.
Take the expression int a = b() + c() + d();
Where b(), c() and d() return ints. When I see an expression like that, I *as
the reader* expect it to be both commutative and associative. And in C++
today, it would be buggy code if the result were dependent on the order of
evaluation. I could, for instance, rewrite it as:
int e = c() + d()
int a = b() + e;
If the evaluation order is defined, I *as a code maintainer* can no longer
do this transformation without looking at b(), c(), d() to make sure they
are completely independent, because it is impossible to tell just from the
original expression if is dependent on the order of evaluation or not. In
the evaluation order dependent world, this refactoring is fragile and may
break code.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BMwxS1s57Pav3AhTF-YWAObKZt354%3DFhZXs48hsU_wi_g%40mail.gmail.com.
--001a113efc00125c4f053775dd15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 12 July 2016 at 14:21, Miro Knejp <span dir=3D"ltr"><=
;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail=
..com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">People also constantly assert without evidence th=
at this is somehow "removing expresiveness" from the language. I =
have asked in the past and now again for code examples that clearly, withou=
t doubt, expresses that the author's intention was *deliberately* for c=
ode to be order-independent and not just a lucky side effect of how the lan=
guage works. And by example I do not mean "I just wrote an expression =
and it happens to not depend on order of evaluation". No, I mean "=
;I wrote this expression and I *intentionally* require it to be order indep=
endent because the future of the universe depends on it".</blockquote>=
<div><br></div><div>When you compile, do you ever turn on optimizations?=C2=
=A0 If so, why, as they are known to make buggy code less deterministic.</d=
iv><div><br></div><div>I want the correct code I write to be as fast as pos=
sible.</div><div><br></div><div><div class=3D"gmail_quote">I call code that=
is accidentally dependent on the order of evaluation a bug.=C2=A0 You want=
to call it a feature. =C2=A0 If it is a feature people will write both del=
iberate code and accidental code that takes advantage of it, since it is im=
possible to tell the difference between the two.</div></div><div><br></div>=
<div><br></div><div>Take the expression int a =3D b() + c() + d();<br></div=
><div><br></div><div>Where b(), c() and d() return ints.=C2=A0 When I see a=
n expression like that, I <i>as the reader</i> expect it to be both commuta=
tive and associative.=C2=A0 And in C++ today, it would be buggy code if the=
result were dependent on the order of evaluation.=C2=A0 I could, for insta=
nce, rewrite it as:</div><div><br></div><div>int e =3D c() + d()</div><div>=
int a =3D b() + e;</div><div><br></div><div>If the evaluation order is defi=
ned, I <i>as a code maintainer</i> can no longer do this transformation wit=
hout looking at b(), c(), d() to make sure they are completely independent,=
because it is impossible to tell just from the original expression if is d=
ependent on the order of evaluation or not.=C2=A0 In the evaluation order d=
ependent world, this refactoring is fragile and may break code.</div><div>-=
-=C2=A0<br></div></div><div class=3D"gmail_signature" data-smartmail=3D"gma=
il_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin "=
;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</di=
v></div></div></div></div>
</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/CAGg_6%2BMwxS1s57Pav3AhTF-YWAObKZt354=
%3DFhZXs48hsU_wi_g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMwxS=
1s57Pav3AhTF-YWAObKZt354%3DFhZXs48hsU_wi_g%40mail.gmail.com</a>.<br />
--001a113efc00125c4f053775dd15--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 16:15:30 -0400
Raw View
--94eb2c123a105d350a053775ef88
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 12, 2016 at 4:03 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> If I'm reading
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
> correctly (=C2=A76.4), it's only "f() << g()" that gets the sequenced-bef=
ore
> edge. "operator<<(f(), g())" is written like a function call and so
> doesn't. You're welcome to retarget your horror to that difference. ;-)
>
Ah, I missed that. OK, retargeted :-)
Seriously, though, how can having different evaluation order requirements
for each of
a() << (b() << c())
a() << (b() =3D c())
a() + (b() + c())
strike anyone as good programming language design? What do you say when
teaching this to someone?
Not to mention the difference between these:
a() << (b() << c())
a() <<=3D (b() <<=3D c())
--=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/CAHSYqdY6i%3DoDdurSv%2B_At_cAz5SRn_HvzuFAfnHLRrs=
W0XzLgg%40mail.gmail.com.
--94eb2c123a105d350a053775ef88
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=
ue, Jul 12, 2016 at 4:03 PM, 'Jeffrey Yasskin' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">If I'm rea=
ding=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
6/p0145r2.pdf" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2016/p0145r2.pdf</a> correctly (=C2=A76.4), it's only "f(=
) << g()" that gets the sequenced-before edge. "operator<=
;<(f(), g())" is written like a function call and so doesn't. Y=
ou're welcome to retarget your horror to that difference. ;-)</div></di=
v></blockquote><div><br>Ah, I missed that.=C2=A0 OK, retargeted :-)<br><br>=
Seriously, though, how can having different evaluation order requirements f=
or each of<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 a() <<=
; (b() << c())<br>=C2=A0 =C2=A0 a() << (b() =3D =C2=A0c())<br>=
=C2=A0 =C2=A0 a() + =C2=A0(b() + =C2=A0c())</font><br>strike anyone as good=
programming language design?=C2=A0 What do you say when teaching this to s=
omeone?<br>Not to mention the difference between these:<br><span style=3D"f=
ont-family:monospace,monospace">=C2=A0 =C2=A0 a() << =C2=A0(b() <&=
lt; =C2=A0c())<br></span><span style=3D"font-family:monospace,monospace">=
=C2=A0 =C2=A0 a() <<=3D (b() <<=3D c())</span><br></div></div><=
/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/CAHSYqdY6i%3DoDdurSv%2B_At_cAz5SRn_Hv=
zuFAfnHLRrsW0XzLgg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY6i%3D=
oDdurSv%2B_At_cAz5SRn_HvzuFAfnHLRrsW0XzLgg%40mail.gmail.com</a>.<br />
--94eb2c123a105d350a053775ef88--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 16:28:14 -0400
Raw View
--94eb2c048e44ecd63a0537761c25
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 4:10 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> Take the expression int a = b() + c() + d();
>
> Where b(), c() and d() return ints. When I see an expression like that, I *as
> the reader* expect it to be both commutative and associative. And in C++
> today, it would be buggy code if the result were dependent on the order of
> evaluation. I could, for instance, rewrite it as:
>
> int e = c() + d()
> int a = b() + e;
>
> If the evaluation order is defined, I *as a code maintainer* can no
> longer do this transformation without looking at b(), c(), d() to make sure
> they are completely independent, because it is impossible to tell just from
> the original expression if is dependent on the order of evaluation or not.
> In the evaluation order dependent world, this refactoring is fragile and
> may break code.
>
In C++ today this code is not associative. For example, even if all
functions return int values, if b() returns 1, c() returns -1, and d()
returns INT_MIN, reordering the computations (at the source level) to add
c() and d() before adding b() would result in undefined behavior. If the
functions return float values, reordering can lead to utterly wrong results.
Your incorrect intuition about how to rewrite this code could lead you to
insert undefined behavior into the program. That's not surprising;
programmers have been led astray by incorrect beliefs about order of
evaluation for literally decades. That's why strict left-to-right order is
the only correct way to fix things. One simple rule that's trivial to
learn and impossible to forget.
--
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/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com.
--94eb2c048e44ecd63a0537761c25
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=
ue, Jul 12, 2016 at 4:10 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Take the expression int a =
=3D b() + c() + d();<br></div><div><br></div><div>Where b(), c() and d() re=
turn ints.=C2=A0 When I see an expression like that, I <i>as the reader</i>=
expect it to be both commutative and associative.=C2=A0 And in C++ today, =
it would be buggy code if the result were dependent on the order of evaluat=
ion.=C2=A0 I could, for instance, rewrite it as:</div><div><br></div><div>i=
nt e =3D c() + d()</div><div>int a =3D b() + e;</div><div><br></div><div>If=
the evaluation order is defined, I <i>as a code maintainer</i> can no long=
er do this transformation without looking at b(), c(), d() to make sure the=
y are completely independent, because it is impossible to tell just from th=
e original expression if is dependent on the order of evaluation or not.=C2=
=A0 In the evaluation order dependent world, this refactoring is fragile an=
d may break code.</div></div></div></div></blockquote><div><br>In C++ today=
this code is not associative.=C2=A0 For example, even if all functions ret=
urn <font face=3D"monospace, monospace">int</font> values, if <font face=3D=
"monospace, monospace">b()</font> returns <font face=3D"monospace, monospac=
e">1</font>, <font face=3D"monospace, monospace">c()</font> returns <font f=
ace=3D"monospace, monospace">-1</font>, and <font face=3D"monospace, monosp=
ace">d()</font> returns <font face=3D"monospace, monospace">INT_MIN</font>,=
reordering the computations (at the source level) to add <font face=3D"mon=
ospace, monospace">c()</font> and <font face=3D"monospace, monospace">d()</=
font> before adding <font face=3D"monospace, monospace">b()</font> would re=
sult in undefined behavior.=C2=A0 If the functions return <font face=3D"mon=
ospace, monospace">float</font> values, reordering can lead to utterly wron=
g results.<br><br>Your incorrect intuition about how to rewrite this code c=
ould lead you to insert undefined behavior into the program.=C2=A0 That'=
;s not surprising; programmers have been led astray by incorrect beliefs ab=
out order of evaluation for literally decades.=C2=A0 That's why strict =
left-to-right order is the only correct way to fix things.=C2=A0 One simple=
rule that's trivial to learn and impossible to forget.</div></div></di=
v></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/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJ=
BNqtaD7zFRKBNQOahg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbttJcP=
Le%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com</a>.<br />
--94eb2c048e44ecd63a0537761c25--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 12 Jul 2016 16:31:28 -0400
Raw View
--001a11378e1a5d0dc40537762738
Content-Type: text/plain; charset=UTF-8
This applies equally well to right-to-left order (which is currently
Clang's ordering, I believe). It in no way proves that left-to-right is
somehow the *only* correct way.
On Tue, Jul 12, 2016 at 4:28 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 4:10 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>>
>> Take the expression int a = b() + c() + d();
>>
>> Where b(), c() and d() return ints. When I see an expression like that,
>> I *as the reader* expect it to be both commutative and associative. And
>> in C++ today, it would be buggy code if the result were dependent on the
>> order of evaluation. I could, for instance, rewrite it as:
>>
>> int e = c() + d()
>> int a = b() + e;
>>
>> If the evaluation order is defined, I *as a code maintainer* can no
>> longer do this transformation without looking at b(), c(), d() to make sure
>> they are completely independent, because it is impossible to tell just from
>> the original expression if is dependent on the order of evaluation or not.
>> In the evaluation order dependent world, this refactoring is fragile and
>> may break code.
>>
>
> In C++ today this code is not associative. For example, even if all
> functions return int values, if b() returns 1, c() returns -1, and d()
> returns INT_MIN, reordering the computations (at the source level) to add
> c() and d() before adding b() would result in undefined behavior. If the
> functions return float values, reordering can lead to utterly wrong
> results.
>
> Your incorrect intuition about how to rewrite this code could lead you to
> insert undefined behavior into the program. That's not surprising;
> programmers have been led astray by incorrect beliefs about order of
> evaluation for literally decades. That's why strict left-to-right order is
> the only correct way to fix things. One simple rule that's trivial to
> learn and impossible to forget.
>
> --
> 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/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com?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/CAMD6iD-Bm%2BUbU9sjewnHch_yrAecnPLEQWPGoJq3DeEiEp%3DmMw%40mail.gmail.com.
--001a11378e1a5d0dc40537762738
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This applies equally well to right-to-left order (which is=
currently Clang's ordering, I believe). It in no way proves that left-=
to-right is somehow the <i>only</i>=C2=A0correct way.</div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 4:28 PM, =
Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyman.rosen@gmail.com" =
target=3D"_blank">hyman.rosen@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D"">On Tue, Jul 12, 2016 at 4:10 PM, Nevin Li=
ber <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>></span> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>Take the expression int a =3D b() + c() + d();<br></div><div=
><br></div><div>Where b(), c() and d() return ints.=C2=A0 When I see an exp=
ression like that, I <i>as the reader</i> expect it to be both commutative =
and associative.=C2=A0 And in C++ today, it would be buggy code if the resu=
lt were dependent on the order of evaluation.=C2=A0 I could, for instance, =
rewrite it as:</div><div><br></div><div>int e =3D c() + d()</div><div>int a=
=3D b() + e;</div><div><br></div><div>If the evaluation order is defined, =
I <i>as a code maintainer</i> can no longer do this transformation without =
looking at b(), c(), d() to make sure they are completely independent, beca=
use it is impossible to tell just from the original expression if is depend=
ent on the order of evaluation or not.=C2=A0 In the evaluation order depend=
ent world, this refactoring is fragile and may break code.</div></div></div=
></div></blockquote></span><div><br>In C++ today this code is not associati=
ve.=C2=A0 For example, even if all functions return <font face=3D"monospace=
, monospace">int</font> values, if <font face=3D"monospace, monospace">b()<=
/font> returns <font face=3D"monospace, monospace">1</font>, <font face=3D"=
monospace, monospace">c()</font> returns <font face=3D"monospace, monospace=
">-1</font>, and <font face=3D"monospace, monospace">d()</font> returns <fo=
nt face=3D"monospace, monospace">INT_MIN</font>, reordering the computation=
s (at the source level) to add <font face=3D"monospace, monospace">c()</fon=
t> and <font face=3D"monospace, monospace">d()</font> before adding <font f=
ace=3D"monospace, monospace">b()</font> would result in undefined behavior.=
=C2=A0 If the functions return <font face=3D"monospace, monospace">float</f=
ont> values, reordering can lead to utterly wrong results.<br><br>Your inco=
rrect intuition about how to rewrite this code could lead you to insert und=
efined behavior into the program.=C2=A0 That's not surprising; programm=
ers have been led astray by incorrect beliefs about order of evaluation for=
literally decades.=C2=A0 That's why strict left-to-right order is the =
only correct way to fix things.=C2=A0 One simple rule that's trivial to=
learn and impossible to forget.</div></div></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" 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@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/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJ=
BNqtaD7zFRKBNQOahg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gma=
il.com</a>.<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" 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/CAMD6iD-Bm%2BUbU9sjewnHch_yrAecnPLEQW=
PGoJq3DeEiEp%3DmMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-Bm%2B=
UbU9sjewnHch_yrAecnPLEQWPGoJq3DeEiEp%3DmMw%40mail.gmail.com</a>.<br />
--001a11378e1a5d0dc40537762738--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 13:32:18 -0700
Raw View
--001a1140f7766f6d4c0537762b44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 12, 2016 at 1:15 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 4:03 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> If I'm reading
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
>> correctly (=C2=A76.4), it's only "f() << g()" that gets the sequenced-be=
fore
>> edge. "operator<<(f(), g())" is written like a function call and so
>> doesn't. You're welcome to retarget your horror to that difference. ;-)
>>
>
> Ah, I missed that. OK, retargeted :-)
>
> Seriously, though, how can having different evaluation order requirements
> for each of
> a() << (b() << c())
> a() << (b() =3D c())
> a() + (b() + c())
> strike anyone as good programming language design? What do you say when
> teaching this to someone?
> Not to mention the difference between these:
> a() << (b() << c())
> a() <<=3D (b() <<=3D c())
>
I'd love to see some real code that looks like those examples. It's hard to
figure out what I expect when the functions are just a(), b(), and c(), but
seeing real code could help folks figure out if the weird bits are "don't
do that" or "we need to change the sequencing of assignments."
I do think it's on the table to make the sequencing stricter for C++20,
once folks have had time to investigate more of the implications. The
change for C++17 was just cautious.
Jeffrey
--=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/CANh-dX%3DVTP8gZZ_2L4OMytLVefzYx7dUs-JQ_CuGanRD4=
CVAGg%40mail.gmail.com.
--001a1140f7766f6d4c0537762b44
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=
ue, Jul 12, 2016 at 1:15 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank" class=3D"cremed">hyman.rosen=
@gmail.com</a>></span> wrote:<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"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D"">On Tue, Jul 12, 2016 at 4:03 PM, 'Jeffrey Yasskin' via ISO C+=
+ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-p=
roposals@isocpp.org" target=3D"_blank" class=3D"cremed">std-proposals@isocp=
p.org</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra">If I'm reading=C2=A0<a href=3D"http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2016/p0145r2.pdf" target=3D"_blank" class=3D"cremed=
">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf</a> c=
orrectly (=C2=A76.4), it's only "f() << g()" that gets =
the sequenced-before edge. "operator<<(f(), g())" is writte=
n like a function call and so doesn't. You're welcome to retarget y=
our horror to that difference. ;-)</div></div></blockquote></span><div><br>=
Ah, I missed that.=C2=A0 OK, retargeted :-)<br><br>Seriously, though, how c=
an having different evaluation order requirements for each of<br><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 a() << (b() << c())<br>=
=C2=A0 =C2=A0 a() << (b() =3D =C2=A0c())<br>=C2=A0 =C2=A0 a() + =C2=
=A0(b() + =C2=A0c())</font><br>strike anyone as good programming language d=
esign?=C2=A0 What do you say when teaching this to someone?<br>Not to menti=
on the difference between these:<br><span style=3D"font-family:monospace,mo=
nospace">=C2=A0 =C2=A0 a() << =C2=A0(b() << =C2=A0c())<br></spa=
n><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 a() <<=
;=3D (b() <<=3D c())</span></div></div></div></div></blockquote><div>=
<br></div></div>I'd love to see some real code that looks like those ex=
amples. It's hard to figure out what I expect when the functions are ju=
st a(), b(), and c(), but seeing real code could help folks figure out if t=
he weird bits are "don't do that" or "we need to change =
the sequencing of assignments."</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra">I do think it's on the table to make the=
sequencing stricter for C++20, once folks have had time to investigate mor=
e of the implications. The change for C++17 was just cautious.</div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jeffrey</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/CANh-dX%3DVTP8gZZ_2L4OMytLVefzYx7dUs-=
JQ_CuGanRD4CVAGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DVTP8g=
ZZ_2L4OMytLVefzYx7dUs-JQ_CuGanRD4CVAGg%40mail.gmail.com</a>.<br />
--001a1140f7766f6d4c0537762b44--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 16:35:19 -0400
Raw View
--001a1149c49c38c5a20537763604
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 4:31 PM, Ren Industries <renindustries@gmail.com>
wrote:
> This applies equally well to right-to-left order (which is currently
> Clang's ordering, I believe). It in no way proves that left-to-right is
> somehow the *only* correct way.
>
Having more than one way is wrong. C++ is written and read from left to
right. Evaluation should mirror that. (I believe that g++ does
right-to-left for function arguments and clang does them left-to-right.)
--
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/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9f1TT2ypN_vHi7A%40mail.gmail.com.
--001a1149c49c38c5a20537763604
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=
ue, Jul 12, 2016 at 4:31 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>This applies equally well to right-to-left order (which is currently Clang=
's ordering, I believe). It in no way proves that left-to-right is some=
how the <i>only</i>=C2=A0correct way.</div></blockquote><div><br></div><div=
>Having more than one way is wrong.=C2=A0 C++ is written and read from left=
to right.=C2=A0 Evaluation should mirror that. =C2=A0(I believe that g++ d=
oes right-to-left for function arguments and clang does them left-to-right.=
)</div></div></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/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9=
f1TT2ypN_vHi7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaQKCdgo-Hj=
AAH6KcLZ6Xghetv1PbW9f1TT2ypN_vHi7A%40mail.gmail.com</a>.<br />
--001a1149c49c38c5a20537763604--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 16:37:32 -0400
Raw View
--001a1141ca482cb6df0537763e45
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 4:32 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> I do think it's on the table to make the sequencing stricter for C++20,
> once folks have had time to investigate more of the implications. The
> change for C++17 was just cautious.
>
The problem is that the ordering for assignment, once specified as
right-to-left in C++17, can never be fixed. That's heinous.
--
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/CAHSYqdaV4VVZ3gC6dtrf92ZxLLtspeDNZnpsKCtYPKBhJw_x3A%40mail.gmail.com.
--001a1141ca482cb6df0537763e45
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=
ue, Jul 12, 2016 at 4:32 PM, 'Jeffrey Yasskin' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<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">=
I do think it's on the table to make the sequencing stricter for C++20,=
once folks have had time to investigate more of the implications. The chan=
ge for C++17 was just cautious.</div></div></blockquote><div><br>The proble=
m is that the ordering for assignment, once specified as right-to-left in C=
++17, can never be fixed.=C2=A0 That's heinous.</div></div></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/CAHSYqdaV4VVZ3gC6dtrf92ZxLLtspeDNZnps=
KCtYPKBhJw_x3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaV4VVZ3gC6=
dtrf92ZxLLtspeDNZnpsKCtYPKBhJw_x3A%40mail.gmail.com</a>.<br />
--001a1141ca482cb6df0537763e45--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 12 Jul 2016 15:38:19 -0500
Raw View
--001a1145f22a2fbf180537764232
Content-Type: text/plain; charset=UTF-8
On 12 July 2016 at 15:28, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> In C++ today this code is not associative. For example, even if all
> functions return int values, if b() returns 1, c() returns -1, and d()
> returns INT_MIN, reordering the computations (at the source level) to add
> c() and d() before adding b() would result in undefined behavior. If the
> functions return float values, reordering can lead to utterly wrong
> results.
>
In other words, when you write code that doesn't obey the rules of
commutativity and associativity, you make it harder for humans to
understand. Great point!
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BPuYK__%2BE2vTTHnXguTtDna%2BtNq0e_6-_sCXPWMCPuYwA%40mail.gmail.com.
--001a1145f22a2fbf180537764232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 12 July 2016 at 15:28, Hyman Rosen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gm=
ail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>In C++ today this code is not a=
ssociative.=C2=A0 For example, even if all functions return <font face=3D"m=
onospace, monospace">int</font> values, if <font face=3D"monospace, monospa=
ce">b()</font> returns <font face=3D"monospace, monospace">1</font>, <font =
face=3D"monospace, monospace">c()</font> returns <font face=3D"monospace, m=
onospace">-1</font>, and <font face=3D"monospace, monospace">d()</font> ret=
urns <font face=3D"monospace, monospace">INT_MIN</font>, reordering the com=
putations (at the source level) to add <font face=3D"monospace, monospace">=
c()</font> and <font face=3D"monospace, monospace">d()</font> before adding=
<font face=3D"monospace, monospace">b()</font> would result in undefined b=
ehavior.=C2=A0 If the functions return <font face=3D"monospace, monospace">=
float</font> values, reordering can lead to utterly wrong results.<br></div=
></div></div></div></blockquote><div><br></div><div>In other words, when yo=
u write code that doesn't obey the rules of commutativity and associati=
vity, you make it harder for humans to understand.=C2=A0 Great point!</div>=
</div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signatu=
re"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)"=
Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></=
div></div></div>
</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/CAGg_6%2BPuYK__%2BE2vTTHnXguTtDna%2Bt=
Nq0e_6-_sCXPWMCPuYwA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPu=
YK__%2BE2vTTHnXguTtDna%2BtNq0e_6-_sCXPWMCPuYwA%40mail.gmail.com</a>.<br />
--001a1145f22a2fbf180537764232--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 13:38:54 -0700
Raw View
--001a1140f776154c9005377643b7
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 1:35 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 4:31 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> This applies equally well to right-to-left order (which is currently
>> Clang's ordering, I believe). It in no way proves that left-to-right is
>> somehow the *only* correct way.
>>
>
> Having more than one way is wrong. C++ is written and read from left to
> right. Evaluation should mirror that. (I believe that g++ does
> right-to-left for function arguments and clang does them left-to-right.)
>
> At this point (after the mailing comes out with the newest working draft),
you should probably write a paper proposing to switch the sequencing of
assignment operations to left-to-right, and try to find a National Body to
write a comment on the CD endorsing your change. Arguing more on this list
won't get you clear agreement one way or the other, but it's possible
you've convinced enough people.
Jeffrey
--
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/CANh-dX%3Dh3WqWxEfmDbtML0FV_QGX-xqNki-y3URburKsTCDQCQ%40mail.gmail.com.
--001a1140f776154c9005377643b7
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=
ue, Jul 12, 2016 at 1:35 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank" class=3D"cremed">hyman.rosen=
@gmail.com</a>></span> wrote:<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"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D"">On Tue, Jul 12, 2016 at 4:31 PM, Ren Industries <span dir=3D"ltr"><=
;<a href=3D"mailto:renindustries@gmail.com" target=3D"_blank" class=3D"crem=
ed">renindustries@gmail.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">This applies equally well to right-to-left order =
(which is currently Clang's ordering, I believe). It in no way proves t=
hat left-to-right is somehow the <i>only</i>=C2=A0correct way.</div></block=
quote><div><br></div></span><div>Having more than one way is wrong.=C2=A0 C=
++ is written and read from left to right.=C2=A0 Evaluation should mirror t=
hat. =C2=A0(I believe that g++ does right-to-left for function arguments an=
d clang does them left-to-right.)</div></div></div></div><span class=3D"">
<p></p>
</span></blockquote><div>At this point (after the mailing comes out with th=
e newest working draft), you should probably write a paper proposing to swi=
tch the sequencing of assignment operations to left-to-right, and try to fi=
nd a National Body to write a comment on the CD endorsing your change. Argu=
ing more on this list won't get you clear agreement one way or the othe=
r, but it's possible you've convinced enough people.</div><div><br>=
</div><div>Jeffrey</div></div></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/CANh-dX%3Dh3WqWxEfmDbtML0FV_QGX-xqNki=
-y3URburKsTCDQCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3Dh3WqW=
xEfmDbtML0FV_QGX-xqNki-y3URburKsTCDQCQ%40mail.gmail.com</a>.<br />
--001a1140f776154c9005377643b7--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 12 Jul 2016 16:45:41 -0400
Raw View
--001a114e52f832ee700537765a15
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I've made this comment in the past, and did not expect the discussion to
come back two weeks after we voted on the issue, but as a complement to
Nevin's comment, I'm glad, from a code review perpsective, that code
written as x =3D h(f(),g()); where there are side-effects to f() and g() ca=
n
be considered as something that's buggy and requires rewriting, not as
something potentially correct and that needs to be investigated. Said
investigation is sometimes painful, costly, requires expertise, and access
to source code which we do not always have.
Guaranteeing the relative evaluation ordering of f() and g() in h(f(),g())
impacts code in many ways, and the belief that simplification is one of
them is not something I share. Some strong proponents of imposing an
ordering in such situations consider the imposition of this order to
simplify coding, particularly for beginners; I spend a significant amount
of time with undergrads every semester, have done so for close to twenty
years now, and again, this argument does not correspond to my experience
(this is an observation, not a statistic, but it does explain my position).
Stating that such code is error-prone and a bad idea is in my view much,
much simpler that considering it correct and investigating it, particularly
when beginners are involved. It's never been difficult to understand so
far. I sympathize with those who would impose ordering even then, but am
glad it was not accepted. Other languages (e.g. C#) make complex nested
expressions with lots of subexpressions meaningful, and I have had the
displeasure of debugging people using that =C2=ABfeature=C2=BB in the last =
few years.
I'm glad we escaped these difficulties with C++; it has made my personal
life and work significantly simpler.
I'd be curious to know how people from SG14 (low-latency, embedded systems)
would see a possible performance loss of 2-4% in practice.
On the positive side, I'm glad the other parts of the ordering proposal
passed, as they seemed to be to be beneficial. I'm happy with the
conclusion we collectively reached. If there's problems with pack expansion
ordering, it's probably a better idea to address this separately. Papers
would be welcome.
Thanks, Jeffrey, for the efforts invested in keeping the overall tone civil=
..
2016-07-12 16:32 GMT-04:00 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:
> On Tue, Jul 12, 2016 at 1:15 PM, Hyman Rosen <hyman.rosen@gmail.com>
> wrote:
>
>> On Tue, Jul 12, 2016 at 4:03 PM, 'Jeffrey Yasskin' via ISO C++ Standard =
-
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>>
>>> If I'm reading
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
>>> correctly (=C2=A76.4), it's only "f() << g()" that gets the sequenced-b=
efore
>>> edge. "operator<<(f(), g())" is written like a function call and so
>>> doesn't. You're welcome to retarget your horror to that difference. ;-)
>>>
>>
>> Ah, I missed that. OK, retargeted :-)
>>
>> Seriously, though, how can having different evaluation order requirement=
s
>> for each of
>> a() << (b() << c())
>> a() << (b() =3D c())
>> a() + (b() + c())
>> strike anyone as good programming language design? What do you say when
>> teaching this to someone?
>> Not to mention the difference between these:
>> a() << (b() << c())
>> a() <<=3D (b() <<=3D c())
>>
>
> I'd love to see some real code that looks like those examples. It's hard
> to figure out what I expect when the functions are just a(), b(), and c()=
,
> but seeing real code could help folks figure out if the weird bits are
> "don't do that" or "we need to change the sequencing of assignments."
>
> I do think it's on the table to make the sequencing stricter for C++20,
> once folks have had time to investigate more of the implications. The
> change for C++17 was just cautious.
>
> Jeffrey
>
> --
> 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/CANh-dX%3DVT=
P8gZZ_2L4OMytLVefzYx7dUs-JQ_CuGanRD4CVAGg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DV=
TP8gZZ_2L4OMytLVefzYx7dUs-JQ_CuGanRD4CVAGg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=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/CAKiZDp3fH%2BVvww8ZXpm9TrkonMDPUAZtu%3Dqo7OCEe9B=
x0XGG6w%40mail.gmail.com.
--001a114e52f832ee700537765a15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I've made this comment in the past, and did =
not expect the=20
discussion to come back two weeks after we voted on the issue, but as a=20
complement to Nevin's comment, I'm glad, from a code review perpsec=
tive,
that code written as x =3D h(f(),g()); where there are side-effects to=20
f() and g() can be considered as something that's buggy and requires=20
rewriting, not as something potentially correct and that needs to be=20
investigated. Said investigation is sometimes painful, costly, requires=20
expertise, and access to source code which we do not always have.<br><br>Gu=
aranteeing the relative evaluation ordering of f() and g() in h(f(),g()) im=
pacts code in many=20
ways, and the belief that simplification is one of them is not something I =
share. Some strong=20
proponents of imposing an ordering in such situations consider the=20
imposition of this order to simplify coding, particularly for beginners; I =
spend a significant amount of time=20
with undergrads every semester, have done so for close to twenty years=20
now, and again, this argument does not correspond to my experience (this is=
an observation, not a statistic, but it does explain my position).=20
Stating that such code is error-prone and a bad idea is in my view much,
much simpler that considering it correct and investigating it,=20
particularly when beginners are involved. It's never been difficult to =
understand so far. I sympathize with those who would impose ordering even t=
hen, but am glad it was not accepted. Other languages (e.g. C#) make comple=
x nested expressions with lots of
subexpressions meaningful, and I have had the displeasure of debugging=20
people using that =C2=ABfeature=C2=BB in the last few years. I'm glad w=
e escaped=20
these difficulties with C++; it has made my personal life and work signific=
antly simpler.<br><br></div><div>I'd be curious to know how people from=
SG14 (low-latency, embedded systems) would see a possible performance loss=
of 2-4% in practice.<br></div><div><br>On the positive side, I'm glad =
the other parts=20
of the ordering proposal passed, as they seemed to be to be beneficial.=20
I'm happy with the conclusion we collectively reached. If
there's problems with pack expansion ordering, it's probably a bet=
ter=20
idea to address this separately. Papers would be welcome.<br></div></div><d=
iv><br></div>Thanks, Jeffrey, for the efforts invested in keeping the overa=
ll tone civil.<br><br></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2016-07-12 16:32 GMT-04:00 'Jeffrey Yasskin' via ISO C++=
Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-pr=
oposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></spa=
n>:<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"><div class=3D"gmail_=
extra"><span class=3D""><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at =
1:15 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyman.rosen@gm=
ail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span> wrote:<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"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><span>On Tue, Jul 12, 2016 at 4:03 PM, 'Jeffr=
ey Yasskin' via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&=
lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-propos=
als@isocpp.org</a>></span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra">If I'm reading=C2=A0<a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf" target=3D"_blank">http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf</a> correctly=
(=C2=A76.4), it's only "f() << g()" that gets the sequ=
enced-before edge. "operator<<(f(), g())" is written like a=
function call and so doesn't. You're welcome to retarget your horr=
or to that difference. ;-)</div></div></blockquote></span><div><br>Ah, I mi=
ssed that.=C2=A0 OK, retargeted :-)<br><br>Seriously, though, how can havin=
g different evaluation order requirements for each of<br><font face=3D"mono=
space, monospace">=C2=A0 =C2=A0 a() << (b() << c())<br>=C2=A0 =
=C2=A0 a() << (b() =3D =C2=A0c())<br>=C2=A0 =C2=A0 a() + =C2=A0(b() +=
=C2=A0c())</font><br>strike anyone as good programming language design?=C2=
=A0 What do you say when teaching this to someone?<br>Not to mention the di=
fference between these:<br><span style=3D"font-family:monospace,monospace">=
=C2=A0 =C2=A0 a() << =C2=A0(b() << =C2=A0c())<br></span><span s=
tyle=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 a() <<=3D (b()=
<<=3D c())</span></div></div></div></div></blockquote><div><br></div=
></div></span>I'd love to see some real code that looks like those exam=
ples. It's hard to figure out what I expect when the functions are just=
a(), b(), and c(), but seeing real code could help folks figure out if the=
weird bits are "don't do that" or "we need to change th=
e sequencing of assignments."</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">I do think it's on the table to make the s=
equencing stricter for C++20, once folks have had time to investigate more =
of the implications. The change for C++17 was just cautious.</div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jeffrey</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" 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@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/CANh-dX%3DVTP8gZZ_2L4OMytLVefzYx7dUs-=
JQ_CuGanRD4CVAGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CANh-dX%3DVTP8gZZ_2L4OMytLVefzYx7dUs-JQ_CuGanRD4CVAGg%40mail.gmail.c=
om</a>.<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" 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/CAKiZDp3fH%2BVvww8ZXpm9TrkonMDPUAZtu%=
3Dqo7OCEe9Bx0XGG6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3fH%2B=
Vvww8ZXpm9TrkonMDPUAZtu%3Dqo7OCEe9Bx0XGG6w%40mail.gmail.com</a>.<br />
--001a114e52f832ee700537765a15--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 16:52:03 -0400
Raw View
--001a114fda9c121c6b05377672d4
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> In other words, when you write code that doesn't obey the rules of
> commutativity and associativity, you make it harder for humans to
> understand. Great point!
>
When you apply the incorrect mental model to a programming language, you
will fail to understand the program. When you apply transformations to a
program while failing to understand it, you will break it. When you break
the program and it fails, the excuse that the program failed to fit your
model is not going to make the program work again.
Programming is already hard enough without deliberately throwing
unspecified behavior into the mix.
--
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/CAHSYqdbJs%2BL2_C-NSgX96yabKZV%2BPUqQkvr7h3-s0Qtc0UT%2BMw%40mail.gmail.com.
--001a114fda9c121c6b05377672d4
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=
ue, Jul 12, 2016 at 4:38 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>In other words, when you w=
rite code that doesn't obey the rules of commutativity and associativit=
y, you make it harder for humans to understand.=C2=A0 Great point!</div></d=
iv></div></div></blockquote><div><br>When you apply the incorrect mental mo=
del to a programming language, you will fail to understand the program.=C2=
=A0 When you apply transformations to a program while failing to understand=
it, you will break it.=C2=A0 When you break the program and it fails, the =
excuse that the program failed to fit your model is not going to make the p=
rogram work again.<br><br>Programming is already hard enough without delibe=
rately throwing unspecified behavior into the mix.</div></div></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/CAHSYqdbJs%2BL2_C-NSgX96yabKZV%2BPUqQ=
kvr7h3-s0Qtc0UT%2BMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbJs%=
2BL2_C-NSgX96yabKZV%2BPUqQkvr7h3-s0Qtc0UT%2BMw%40mail.gmail.com</a>.<br />
--001a114fda9c121c6b05377672d4--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 22:59:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------08664E1B98884940BFEE238A
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 22:10 schrieb Nevin Liber:
> On 12 July 2016 at 14:21, Miro Knejp <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
>
> People also constantly assert without evidence that this is
> somehow "removing expresiveness" from the language. I have asked
> in the past and now again for code examples that clearly, without
> doubt, expresses that the author's intention was *deliberately*
> for code to be order-independent and not just a lucky side effect
> of how the language works. And by example I do not mean "I just
> wrote an expression and it happens to not depend on order of
> evaluation". No, I mean "I wrote this expression and I
> *intentionally* require it to be order independent because the
> future of the universe depends on it".
>
>
> When you compile, do you ever turn on optimizations? If so, why, as
> they are known to make buggy code less deterministic.
>
> I want the correct code I write to be as fast as possible.
Obviously if code is broken, it's broken. It depende on UB, so there is
no helping it. It has no correct answer. It is only "buggy" because the
language allows it to be due to ambiguities.
>
> I call code that is accidentally dependent on the order of evaluation
> a bug. You want to call it a feature. If it is a feature people
> will write both deliberate code and accidental code that takes
> advantage of it, since it is impossible to tell the difference between
> the two.
I want the buggy code to *always* fail, not *sometimes* depending on the
compiler's mood that morning.
>
>
> Take the expression int a = b() + c() + d();
>
> Where b(), c() and d() return ints. When I see an expression like
> that, I /as the reader/ expect it to be both commutative and
> associative. And in C++ today, it would be buggy code if the result
> were dependent on the order of evaluation. I could, for instance,
> rewrite it as:
>
> int e = c() + d()
> int a = b() + e;
>
> If the evaluation order is defined, I /as a code maintainer/ can no
> longer do this transformation without looking at b(), c(), d() to make
> sure they are completely independent, because it is impossible to tell
> just from the original expression if is dependent on the order of
> evaluation or not. In the evaluation order dependent world, this
> refactoring is fragile and may break code.
In a world without fixed evaluation order this change might also break
code if the compiler decides to evaluate b(), c(), d() in different
orders before and after the change and the author accidentally relied on
it. You can only do this change if you trust the code not to be buggy.
It is certainly a better argument than the philosophical stuff others
have presented in past discussions and I thank you for that. It made me
think. Now I wonder if the expectation about commutativity and
associativity is not a naive intuition. These properties only hold for
the operations with the values of the subexpression, why should it
transitively establish these relationships between the subexpressions.
Commutativity certainly holds for ints (in theory), but not for much
else. So as soon as other types are involved with operator+ implying
commutativity or associativity can be just as fragile. You also state
"in C++ today, it would be buggy code". Well yes, because the language
rules allow it to be. If the order is fixed the code is either always
correct or always incorrect. It is primarily this bug trap that concerns
me the most and that even experts fall into occasionally.
So I do accept the maintainer's dilemma. I feel like the real issue is
the absence of a way for the author to convene whether the order
mattered in the first place or not, regardless of whether evaluation
order is fixed or not. In a world without fixed order the author might
have accidentally relied on it in which case the transformation is a
bugfix. In a world with fixed evaluation order the author might not have
cared about it in which case it's an improvement to
readability/efficiency. In both cases it is the maintainer's problem to
figure it out. And in both cases they have to consult the source or
documentation of b(), c(), d() to judge the consequences of the
transformation. (A function purity annotation would really help with that.)
--
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/1d85909b-c207-7612-b6cd-bb2bd0f05b36%40gmail.com.
--------------08664E1B98884940BFEE238A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 22:10 schrieb Nevin Liber:<br>
<blockquote
cite=3D"mid:CAGg_6+MwxS1s57Pav3AhTF-YWAObKZt354=3DFhZXs48hsU_wi_g@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">On 12 July 2016 at 14:21, Miro Knejp <span
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.kne=
jp@gmail.com</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">People
also constantly assert without evidence that this is
somehow "removing expresiveness" from the language. I have
asked in the past and now again for code examples that
clearly, without doubt, expresses that the author's
intention was *deliberately* for code to be
order-independent and not just a lucky side effect of how
the language works. And by example I do not mean "I just
wrote an expression and it happens to not depend on order
of evaluation". No, I mean "I wrote this expression and I
*intentionally* require it to be order independent because
the future of the universe depends on it".</blockquote>
<div><br>
</div>
<div>When you compile, do you ever turn on optimizations?=C2=A0
If so, why, as they are known to make buggy code less
deterministic.</div>
<div><br>
</div>
<div>I want the correct code I write to be as fast as
possible.</div>
</div>
</div>
</div>
</blockquote>
Obviously if code is broken, it's broken. It depende on UB, so there
is no helping it. It has no correct answer. It is only "buggy"
because the language allows it to be due to ambiguities.<br>
<blockquote
cite=3D"mid:CAGg_6+MwxS1s57Pav3AhTF-YWAObKZt354=3DFhZXs48hsU_wi_g@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>
<div class=3D"gmail_quote">I call code that is accidentally
dependent on the order of evaluation a bug.=C2=A0 You want =
to
call it a feature. =C2=A0 If it is a feature people will
write both deliberate code and accidental code that
takes advantage of it, since it is impossible to tell
the difference between the two.</div>
</div>
</div>
</div>
</div>
</blockquote>
I want the buggy code to *always* fail, not *sometimes* depending on
the compiler's mood that morning.<br>
<blockquote
cite=3D"mid:CAGg_6+MwxS1s57Pav3AhTF-YWAObKZt354=3DFhZXs48hsU_wi_g@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>Take the expression int a =3D b() + c() + d();<br>
</div>
<div><br>
</div>
<div>Where b(), c() and d() return ints.=C2=A0 When I see an
expression like that, I <i>as the reader</i> expect it to
be both commutative and associative.=C2=A0 And in C++ today, =
it
would be buggy code if the result were dependent on the
order of evaluation.=C2=A0 I could, for instance, rewrite it
as:</div>
<div><br>
</div>
<div>int e =3D c() + d()</div>
<div>int a =3D b() + e;</div>
<div><br>
</div>
<div>If the evaluation order is defined, I <i>as a code
maintainer</i> can no longer do this transformation
without looking at b(), c(), d() to make sure they are
completely independent, because it is impossible to tell
just from the original expression if is dependent on the
order of evaluation or not.=C2=A0 In the evaluation order
dependent world, this refactoring is fragile and may break
code.</div>
</div>
</div>
</div>
</blockquote>
In a world without fixed evaluation order this change might also
break code if the compiler decides to evaluate b(), c(), d() in
different orders before and after the change and the author
accidentally relied on it. You can only do this change if you trust
the code not to be buggy.<br>
<br>
It is certainly a better argument than the philosophical stuff
others have presented in past discussions and I thank you for that.
It made me think. Now I wonder if the expectation about
commutativity and associativity is not a naive intuition. These
properties only hold for the operations with the values of the
subexpression, why should it transitively establish these
relationships between the subexpressions. Commutativity certainly
holds for ints (in theory), but not for much else. So as soon as
other types are involved with operator+ implying commutativity or
associativity can be just as fragile. You also state "in C++ today,
it would be buggy code". Well yes, because the language rules allow
it to be. If the order is fixed the code is either always correct or
always incorrect. It is primarily this bug trap that concerns me the
most and that even experts fall into occasionally.<br>
<br>
So I do accept the maintainer's dilemma. I feel like the real issue
is the absence of a way for the author to convene whether the order
mattered in the first place or not, regardless of whether evaluation
order is fixed or not. In a world without fixed order the author
might have accidentally relied on it in which case the
transformation is a bugfix. In a world with fixed evaluation order
the author might not have cared about it in which case it's an
improvement to readability/efficiency. In both cases it is the
maintainer's problem to figure it out. And in both cases they have
to consult the source or documentation of b(), c(), d() to judge the
consequences of the transformation. (A function purity annotation
would really help with that.)<br>
</body>
</html>
<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/1d85909b-c207-7612-b6cd-bb2bd0f05b36%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1d85909b-c207-7612-b6cd-bb2bd0f05b36%=
40gmail.com</a>.<br />
--------------08664E1B98884940BFEE238A--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 17:09:26 -0400
Raw View
--001a114a84983992de053776b0f3
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 4:45 PM, Patrice Roy <patricer@gmail.com> wrote:
> I've made this comment in the past, and did not expect the discussion to
> come back two weeks after we voted on the issue, but as a complement to
> Nevin's comment, I'm glad, from a code review perpsective, that code
> written as x = h(f(),g()); where there are side-effects to f() and g() can
> be considered as something that's buggy and requires rewriting, not as
> something potentially correct and that needs to be investigated.
>
In a language with a properly defined evaluation order, the following code
works as obviously as it reads.
template <typename T> T get(istream &in) { T t; in >> t; return t; }
auto point = make_pair(get<int>(cin), get<int>(cin));
It's the way the code works in C++ today if I write
int xy[2] = { get<int>(cin), get<int>(cin) };
so the language is inconsistent with itself with respect to when it defines
order and when it doesn't.
I've said it before - C and C++ programmers have developed Stockholm
Syndrome with respect to evaluation order. The rules have been wrong for
so long that programmers have come to believe that this is the way they
must be, and then accuse reasonable-looking code of being broken, stupid,
error-prone, and lazy when it's really the language that's that 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/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM9G_5rFXNj%3DngFw%40mail.gmail.com.
--001a114a84983992de053776b0f3
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=
ue, Jul 12, 2016 at 4:45 PM, Patrice Roy <span dir=3D"ltr"><<a href=3D"m=
ailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I=
9;ve made this comment in the past, and did not expect the=20
discussion to come back two weeks after we voted on the issue, but as a=20
complement to Nevin's comment, I'm glad, from a code review perpsec=
tive,
that code written as x =3D h(f(),g()); where there are side-effects to=20
f() and g() can be considered as something that's buggy and requires=20
rewriting, not as something potentially correct and that needs to be=20
investigated.</div></div></div></blockquote><div><br>In a language with a p=
roperly defined evaluation order, the following code works as obviously as =
it reads.<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template <=
;typename T> T get(istream &in) { T t; in >> t; return t; }</f=
ont><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto point =3D ma=
ke_pair(get<int>(cin), get<int>(cin));</font><br><br><font face=
=3D"arial, helvetica, sans-serif">It's the way the code works in C++ to=
day if I write</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
int xy[2] =3D { get<int>(cin), get<int>(cin) };</font></div><di=
v><font face=3D"arial, helvetica, sans-serif">so the language is inconsiste=
nt with itself with respect to when it defines order and when it doesn'=
t.<br><br>I've said it before - C and C++ programmers have developed St=
ockholm Syndrome with respect to evaluation order.=C2=A0 The rules have bee=
n wrong for so long that programmers have come to believe that this is the =
way they must be, and then accuse reasonable-looking code of being broken, =
stupid, error-prone, and lazy when it's really the language that's =
that way.</font></div></div></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/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM=
9G_5rFXNj%3DngFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfEEs_Nm=
r4xZg76caDsH0gVb07qmNM9G_5rFXNj%3DngFw%40mail.gmail.com</a>.<br />
--001a114a84983992de053776b0f3--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 23:15:38 +0200
Raw View
This is a multi-part message in MIME format.
--------------50A3C79A5201BB04B8D7E810
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 21:23 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>> auto inserts = {v.insert(v.end(), args)...};
> That makes it an initializer_list, meaning the values are const,
> meaning you cannot move them out.
> Just saying.
>
>
> Moving iterators?
The values in an initializer_list are const, so there is no moving the
values out of it without const_cast and a deep sip of UB.
--
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/93fd3c1a-89a2-3057-f8fa-e11f6d23ec92%40gmail.com.
--------------50A3C79A5201BB04B8D7E810
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 21:23 schrieb 'Edward Catmur' via ISO C++ Standard
- Future Proposals:<br>
<blockquote
cite=3D"mid:CAJnLdOYJCWP0=3Dj-BLemhfwOS2bzQiL8RGhGWrU1yHArDQgLMMw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">=C2=A0
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>auto inserts =3D {v.insert(v.end(),
args)...};</div>
</div>
</div>
</div>
</blockquote>
That makes it an initializer_list, meaning the values
are const, meaning you cannot move them out.<br>
Just saying.<br>
</div>
</blockquote>
<div><br>
</div>
<div>=C2=A0Moving iterators?</div>
</div>
</div>
</div>
</blockquote>
The values in an initializer_list are const, so there is no moving
the values out of it without const_cast and a deep sip of UB.<br>
<br>
</body>
</html>
<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/93fd3c1a-89a2-3057-f8fa-e11f6d23ec92%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/93fd3c1a-89a2-3057-f8fa-e11f6d23ec92%=
40gmail.com</a>.<br />
--------------50A3C79A5201BB04B8D7E810--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 17:14:47 -0400
Raw View
--001a1149c49c64583c053776c35d
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 4:59 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
>
> I feel like the real issue is the absence of a way for the author to
> convene whether the order mattered in the first place or not, regardless of
> whether evaluation order is fixed or not.
>
Why? If you write a = f(); b = g(); do you worry that there's no way to
tell the compiler that you don't care about the order of the two statements?
--
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/CAHSYqdZJF5%3DQ4y8x5TUZRH4hLTuHpN1JHN6Ln317MY0J4xwaDw%40mail.gmail.com.
--001a1149c49c64583c053776c35d
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=
ue, Jul 12, 2016 at 4:59 PM, Miro Knejp <span dir=3D"ltr"><<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D=
"#000000">I feel like the real issue
is the absence of a way for the author to convene whether the order
mattered in the first place or not, regardless of whether evaluation
order is fixed or not.</div></blockquote><div><br>Why?=C2=A0 If you wri=
te <font face=3D"monospace, monospace">a =3D f(); b =3D g();</font> do you =
worry that there's no way to tell the compiler that you don't care =
about the order of the two statements?</div></div></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/CAHSYqdZJF5%3DQ4y8x5TUZRH4hLTuHpN1JHN=
6Ln317MY0J4xwaDw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZJF5%3DQ=
4y8x5TUZRH4hLTuHpN1JHN6Ln317MY0J4xwaDw%40mail.gmail.com</a>.<br />
--001a1149c49c64583c053776c35d--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 12 Jul 2016 17:19:08 -0400
Raw View
--94eb2c06623adadc74053776d17b
Content-Type: text/plain; charset=UTF-8
Having more than one way is no more wrong than anything else; as you said,
it is a *value judgement*. Your "should" is not justified merely because
you assert it.
I don't have Stockholm syndrome; I wish to have a way to express I don't
care about the order of evaluation and the compiler may evaluate as it
likes. You wish to take that away without replacing it. That is
fundamentally the problem; I value speed as much as you value correctness.
In my field (game design), correctness is an unnecessary and burdensome
requirement; you cannot have real time games and correct lighting, for
example. That results in a difference of opinion on where the chips should
fall, but at least I don't assert my way is the absolute correct way
without evidence like you do.
On Tue, Jul 12, 2016 at 4:35 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 4:31 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> This applies equally well to right-to-left order (which is currently
>> Clang's ordering, I believe). It in no way proves that left-to-right is
>> somehow the *only* correct way.
>>
>
> Having more than one way is wrong. C++ is written and read from left to
> right. Evaluation should mirror that. (I believe that g++ does
> right-to-left for function arguments and clang does them left-to-right.)
>
> --
> 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/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9f1TT2ypN_vHi7A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9f1TT2ypN_vHi7A%40mail.gmail.com?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/CAMD6iD8sAr0eVwN2sXbCPcxqueBjmsfGqa%3DOEF58%3DGQmyR3OuA%40mail.gmail.com.
--94eb2c06623adadc74053776d17b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Having more than one way is no more wrong than anything el=
se; as you said, it is a <i>value judgement</i>. Your "should" is=
not justified merely because you assert it.=C2=A0<div><br></div><div>I don=
't have Stockholm syndrome; I wish to have a way to express I don't=
care about the order of evaluation and the compiler may evaluate as it lik=
es. You wish to take that away without replacing it. That is fundamentally =
the problem; I value speed as much as you value correctness. In my field (g=
ame design), correctness is an unnecessary and burdensome requirement; you =
cannot have real time games and correct lighting, for example. That results=
in a difference of opinion on where the chips should fall, but at least I =
don't assert my way is the absolute correct way without evidence like y=
ou do.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Tue, Jul 12, 2016 at 4:35 PM, Hyman Rosen <span dir=3D"ltr"><<a href=
=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</=
a>></span> wrote:<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"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue,=
Jul 12, 2016 at 4:31 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"m=
ailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a=
>></span> wrote:<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">This=
applies equally well to right-to-left order (which is currently Clang'=
s ordering, I believe). It in no way proves that left-to-right is somehow t=
he <i>only</i>=C2=A0correct way.</div></blockquote><div><br></div></span><d=
iv>Having more than one way is wrong.=C2=A0 C++ is written and read from le=
ft to right.=C2=A0 Evaluation should mirror that. =C2=A0(I believe that g++=
does right-to-left for function arguments and clang does them left-to-righ=
t.)</div></div></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" 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@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/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9=
f1TT2ypN_vHi7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9f1TT2ypN_vHi7A%40mail.gmail.com</=
a>.<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" 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/CAMD6iD8sAr0eVwN2sXbCPcxqueBjmsfGqa%3=
DOEF58%3DGQmyR3OuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8sAr0e=
VwN2sXbCPcxqueBjmsfGqa%3DOEF58%3DGQmyR3OuA%40mail.gmail.com</a>.<br />
--94eb2c06623adadc74053776d17b--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 12 Jul 2016 23:20:07 +0200
Raw View
This is a multi-part message in MIME format.
--------------9A2F883678AED9191E16E75D
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 23:14 schrieb Hyman Rosen:
> On Tue, Jul 12, 2016 at 4:59 PM, Miro Knejp <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
>
> I feel like the real issue is the absence of a way for the author
> to convene whether the order mattered in the first place or not,
> regardless of whether evaluation order is fixed or not.
>
>
> Why? If you write a = f(); b = g(); do you worry that there's no way
> to tell the compiler that you don't care about the order of the two
> statements?
Within an expression. That's what this all about. And I didn't target
the compiler but the human maintainer. There is explicit syntax to tell
the compiler and people that code is *intentionally ordered*:
semicolons. And commas, sometimes, but not always, you better remember
the rules. There is no explicit syntax to tell them that code is
*intentionally unordered*.
--
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/c63f2f33-4692-94bb-ec27-9ab8b2bdcde2%40gmail.com.
--------------9A2F883678AED9191E16E75D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 23:14 schrieb Hyman Rosen:<br>
<blockquote
cite=3D"mid:CAHSYqdZJF5=3DQ4y8x5TUZRH4hLTuHpN1JHN6Ln317MY0J4xwaDw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 4:59 PM, Miro
Knejp <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro=
..knejp@gmail.com</a>></span>
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I feel like the rea=
l
issue is the absence of a way for the author to convene
whether the order mattered in the first place or not,
regardless of whether evaluation order is fixed or not.</di=
v>
</blockquote>
<div><br>
Why?=C2=A0 If you write <font face=3D"monospace, monospace">a=
=3D
f(); b =3D g();</font> do you worry that there's no way to
tell the compiler that you don't care about the order of
the two statements?</div>
</div>
</div>
</div>
</blockquote>
Within an expression. That's what this all about. And I didn't
target the compiler but the human maintainer. There is explicit
syntax to tell the compiler and people that code is *intentionally
ordered*: semicolons. And commas, sometimes, but not always, you
better remember the rules. There is no explicit syntax to tell them
that code is *intentionally unordered*.<br>
</body>
</html>
<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/c63f2f33-4692-94bb-ec27-9ab8b2bdcde2%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c63f2f33-4692-94bb-ec27-9ab8b2bdcde2%=
40gmail.com</a>.<br />
--------------9A2F883678AED9191E16E75D--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 13 Jul 2016 00:22:08 +0300
Raw View
On 13 July 2016 at 00:09, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> I've said it before - C and C++ programmers have developed Stockholm
> Syndrome with respect to evaluation order. The rules have been wrong for so
> long that programmers have come to believe that this is the way they must
> be, and then accuse reasonable-looking code of being broken, stupid,
> error-prone, and lazy when it's really the language that's that way.
Well, I don't know what evidence makes you think programmers have such
a syndrome, but the committee
was convinced by implementation vendors and high-performance
programming audiences reporting that
the optimization opportunities in unspecified function argument
evaluation are of significant importance
to 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/CAFk2RUbpOdv%3DV1eJ%2BW4JW8xUnACpxaa7dDLM-v3E%2BfU3ZcgQ0Q%40mail.gmail.com.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 14:27:12 -0700
Raw View
--001a114ea688adcf48053776ee51
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 2:09 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
> In a language with a properly defined evaluation order, the following code
> works as obviously as it reads.
>
No, not "properly" nor "obviously". You keep asserting your own position as
"proper" because it is the position you hold and you do not counter Nevin's
or Patrice's (frankly compelling) points with anything other than more
blanket assertions. I realize that you are frustrated, but you appear to be
simply writing off the other view point and that is not fair. This is not
as simple a decision as you make it out to be.
On Tue, Jul 12, 2016 at 2:09 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> I've said it before - C and C++ programmers have developed Stockholm
> Syndrome with respect to evaluation order. The rules have been wrong for
> so long that programmers have come to believe that this is the way they
> must be, and then accuse reasonable-looking code of being broken, stupid,
> error-prone, and lazy when it's really the language that's that way.
>
You aren't giving the opposing position the credit it deserves. If you
think this is somehow purely "Stockholm Syndrome" then please try to better
understand the arguments that were made and address them appropriately,
otherwise you aren't going to convince anyone of anything.
--
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/CANh8DEmyvYcbk8n0791HKPW4QVR26AKPMxRGUaS_PuAxGXqSZQ%40mail.gmail.com.
--001a114ea688adcf48053776ee51
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=
ue, Jul 12, 2016 at 2:09 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div>In a language with a properly defined eval=
uation order, the following code works as obviously as it reads.<br></div><=
/div></div></div></blockquote><div><br></div><div>No, not "properly&qu=
ot; nor "obviously". You keep asserting your own position as &quo=
t;proper" because it is the position you hold and you do not counter N=
evin's or Patrice's (frankly compelling) points with anything other=
than more blanket assertions. I realize that you are frustrated, but you a=
ppear to be simply writing off the other view point and that is not fair. T=
his is not as simple a decision as you make it out to be.</div><div><br></d=
iv><div>On Tue, Jul 12, 2016 at 2:09 PM, Hyman Rosen=C2=A0<span dir=3D"ltr"=
><<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen=
@gmail.com</a>></span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style=
:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><font face=3D"=
arial, helvetica, sans-serif">I've said it before - C and C++ programme=
rs have developed Stockholm Syndrome with respect to evaluation order.=C2=
=A0 The rules have been wrong for so long that programmers have come to bel=
ieve that this is the way they must be, and then accuse reasonable-looking =
code of being broken, stupid, error-prone, and lazy when it's really th=
e language that's that way.</font></div></div></div></div></blockquote>=
<div><br></div><div>You aren't giving the opposing position the credit =
it deserves. If you think this is somehow purely "Stockholm Syndrome&q=
uot; then please try to better understand the arguments that were made and =
address them appropriately, otherwise you aren't going to convince anyo=
ne of anything.</div></div></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/CANh8DEmyvYcbk8n0791HKPW4QVR26AKPMxRG=
UaS_PuAxGXqSZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmyvYcbk8n0=
791HKPW4QVR26AKPMxRGUaS_PuAxGXqSZQ%40mail.gmail.com</a>.<br />
--001a114ea688adcf48053776ee51--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 12 Jul 2016 17:36:23 -0400
Raw View
--001a114e52f88dac370537770fe5
Content-Type: text/plain; charset=UTF-8
I'm sorry to say I don't share your belief as to the obviousness of these
examples.The relative obviousness-or-not of such statements is probably not
where we want the discussion to go in order to be productive. I'll let the
rest of the rant lay, as it does not seem to be an appropriate forum for
these words.
I think anyone who feels as strongly as you seem to do about this topic
should write a proposal for it, or push for a NB comment. Scientific
arguments would be more convincing than arguments based on what people seem
to think is obvious, at least in my view.
I wish you good luck; as previously stated, I think the agreement we
reached in Oulu was satisfactory. Should there be convincing arguments to
the contrary, we'll see, but it will be a tough sell given there are
measurable and measured performance losses, and given that for some of us
it increases the maintenance burden in a noticeable way. I'll gladly read
your proposal should you decide to write it.
2016-07-12 17:09 GMT-04:00 Hyman Rosen <hyman.rosen@gmail.com>:
> On Tue, Jul 12, 2016 at 4:45 PM, Patrice Roy <patricer@gmail.com> wrote:
>
>> I've made this comment in the past, and did not expect the discussion to
>> come back two weeks after we voted on the issue, but as a complement to
>> Nevin's comment, I'm glad, from a code review perpsective, that code
>> written as x = h(f(),g()); where there are side-effects to f() and g() can
>> be considered as something that's buggy and requires rewriting, not as
>> something potentially correct and that needs to be investigated.
>>
>
> In a language with a properly defined evaluation order, the following code
> works as obviously as it reads.
> template <typename T> T get(istream &in) { T t; in >> t; return t; }
> auto point = make_pair(get<int>(cin), get<int>(cin));
>
> It's the way the code works in C++ today if I write
> int xy[2] = { get<int>(cin), get<int>(cin) };
> so the language is inconsistent with itself with respect to when it
> defines order and when it doesn't.
>
> I've said it before - C and C++ programmers have developed Stockholm
> Syndrome with respect to evaluation order. The rules have been wrong for
> so long that programmers have come to believe that this is the way they
> must be, and then accuse reasonable-looking code of being broken, stupid,
> error-prone, and lazy when it's really the language that's that 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/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM9G_5rFXNj%3DngFw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM9G_5rFXNj%3DngFw%40mail.gmail.com?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/CAKiZDp3A0sDd3qdthkkB9uMv34QWhT%2B52iybrN%3DYJBjCoWXaxQ%40mail.gmail.com.
--001a114e52f88dac370537770fe5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I'm sorry to say I don't share your beli=
ef as to the obviousness of these examples.The relative obviousness-or-not =
of such statements is probably not where we want the discussion to go in or=
der to be productive. I'll let the rest of the rant lay, as it does not=
seem to be an appropriate forum for these words.<br><br></div>I think anyo=
ne who feels as strongly as you seem to do about this topic should write a =
proposal for it, or push for a NB comment. Scientific arguments would be mo=
re convincing than arguments based on what people seem to think is obvious,=
at least in my view.<br><br></div>I wish you good luck; as previously stat=
ed, I think the agreement we reached in Oulu was satisfactory. Should there=
be convincing arguments to the contrary, we'll see, but it will be a t=
ough sell given there are measurable and measured performance losses, and g=
iven that for some of us it increases the maintenance burden in a noticeabl=
e way. I'll gladly read your proposal should you decide to write it.<br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-07-12=
17:09 GMT-04:00 Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyman.=
rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><span class=3D"">On Tue, Jul 12, 2016 at 4:45 P=
M, Patrice Roy <span dir=3D"ltr"><<a href=3D"mailto:patricer@gmail.com" =
target=3D"_blank">patricer@gmail.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div>I've made this comment in =
the past, and did not expect the=20
discussion to come back two weeks after we voted on the issue, but as a=20
complement to Nevin's comment, I'm glad, from a code review perpsec=
tive,
that code written as x =3D h(f(),g()); where there are side-effects to=20
f() and g() can be considered as something that's buggy and requires=20
rewriting, not as something potentially correct and that needs to be=20
investigated.</div></div></div></blockquote></span><div><br>In a language w=
ith a properly defined evaluation order, the following code works as obviou=
sly as it reads.<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 templ=
ate <typename T> T get(istream &in) { T t; in >> t; return =
t; }</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto point=
=3D make_pair(get<int>(cin), get<int>(cin));</font><br><br><fo=
nt face=3D"arial, helvetica, sans-serif">It's the way the code works in=
C++ today if I write</font><br><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 int xy[2] =3D { get<int>(cin), get<int>(cin) };</font></=
div><div><font face=3D"arial, helvetica, sans-serif">so the language is inc=
onsistent with itself with respect to when it defines order and when it doe=
sn't.<br><br>I've said it before - C and C++ programmers have devel=
oped Stockholm Syndrome with respect to evaluation order.=C2=A0 The rules h=
ave been wrong for so long that programmers have come to believe that this =
is the way they must be, and then accuse reasonable-looking code of being b=
roken, stupid, error-prone, and lazy when it's really the language that=
's that way.</font></div></div></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" 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@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/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM=
9G_5rFXNj%3DngFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM9G_5rFXNj%3DngFw%40mail.gmail.c=
om</a>.<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" 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/CAKiZDp3A0sDd3qdthkkB9uMv34QWhT%2B52i=
ybrN%3DYJBjCoWXaxQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3A0sDd=
3qdthkkB9uMv34QWhT%2B52iybrN%3DYJBjCoWXaxQ%40mail.gmail.com</a>.<br />
--001a114e52f88dac370537770fe5--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 12 Jul 2016 14:41:29 -0700 (PDT)
Raw View
------=_Part_433_791444942.1468359689821
Content-Type: multipart/alternative;
boundary="----=_Part_434_206037079.1468359689821"
------=_Part_434_206037079.1468359689821
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 4:52:25 PM UTC-4, Hyman Rosen wrote:
>
> On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
>>
>> In other words, when you write code that doesn't obey the rules of
>> commutativity and associativity, you make it harder for humans to
>> understand. Great point!
>>
>
> When you apply the incorrect mental model to a programming language, you
> will fail to understand the program.
>
People should not conform to their programming languages; programming
languages should conform to people.
--
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/9dd07c8c-70bb-455b-8062-7350306fccf3%40isocpp.org.
------=_Part_434_206037079.1468359689821
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 12, 2016 at 4:52:25 PM UTC-4, Hyman Rosen=
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 class=3D"gmail_quote">On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <spa=
n dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"IaYLhp3ACgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">ne...@eviloverlord.com</a>></span> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>In othe=
r words, when you write code that doesn't obey the rules of commutativi=
ty and associativity, you make it harder for humans to understand.=C2=A0 Gr=
eat point!</div></div></div></div></blockquote><div><br>When you apply the =
incorrect mental model to a programming language, you will fail to understa=
nd the program.</div></div></div></div></blockquote><div><br>People should =
not conform to their programming languages; programming languages should co=
nform to people.</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/9dd07c8c-70bb-455b-8062-7350306fccf3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9dd07c8c-70bb-455b-8062-7350306fccf3=
%40isocpp.org</a>.<br />
------=_Part_434_206037079.1468359689821--
------=_Part_433_791444942.1468359689821--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Tue, 12 Jul 2016 17:42:57 -0400
Raw View
--001a114a72de052c490537772735
Content-Type: text/plain; charset=UTF-8
Tell that to those who espouse functional programming languages, which have
a decidedly anti-human mind model bent.
To some degree, we're doing something quite unnatural; people and
programming languages need to meet in the middle.
On Tue, Jul 12, 2016 at 5:41 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, July 12, 2016 at 4:52:25 PM UTC-4, Hyman Rosen wrote:
>>
>> On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <ne...@eviloverlord.com>
>> wrote:
>>>
>>> In other words, when you write code that doesn't obey the rules of
>>> commutativity and associativity, you make it harder for humans to
>>> understand. Great point!
>>>
>>
>> When you apply the incorrect mental model to a programming language, you
>> will fail to understand the program.
>>
>
> People should not conform to their programming languages; programming
> languages should conform to people.
>
> --
> 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/9dd07c8c-70bb-455b-8062-7350306fccf3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9dd07c8c-70bb-455b-8062-7350306fccf3%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/CAMD6iD8pNxL_mhvJemtxdOTcnhGqoo6EJ8zt3NaPoay%2Bc80Y2A%40mail.gmail.com.
--001a114a72de052c490537772735
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Tell that to those who espouse functional programming lang=
uages, which have a decidedly anti-human mind model bent.<div>To some degre=
e, we're doing something quite unnatural; people and programming langua=
ges need to meet in the middle.</div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 5:41 PM, Nicol Bolas <spa=
n dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">=
jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">On Tuesday, July 12, 2016 at 4:52:25 PM UTC-4, Hyman Rose=
n wrote:<span class=3D""><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 class=3D"gmail_quote">On Tue, Jul 12, 2016 at 4:38 PM, N=
evin Liber <span dir=3D"ltr"><<a rel=3D"nofollow">ne...@eviloverlord.com=
</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote"><div>In other words, when you write code that do=
esn't obey the rules of commutativity and associativity, you make it ha=
rder for humans to understand.=C2=A0 Great point!</div></div></div></div></=
blockquote><div><br>When you apply the incorrect mental model to a programm=
ing language, you will fail to understand the program.</div></div></div></d=
iv></blockquote></span><div><br>People should not conform to their programm=
ing languages; programming languages should conform to people.</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" 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@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/9dd07c8c-70bb-455b-8062-7350306fccf3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9dd07c8c-70bb-=
455b-8062-7350306fccf3%40isocpp.org</a>.<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" 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/CAMD6iD8pNxL_mhvJemtxdOTcnhGqoo6EJ8zt=
3NaPoay%2Bc80Y2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8pNxL_mh=
vJemtxdOTcnhGqoo6EJ8zt3NaPoay%2Bc80Y2A%40mail.gmail.com</a>.<br />
--001a114a72de052c490537772735--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 12 Jul 2016 14:47:13 -0700 (PDT)
Raw View
------=_Part_380_910761023.1468360033636
Content-Type: multipart/alternative;
boundary="----=_Part_381_1796015009.1468360033636"
------=_Part_381_1796015009.1468360033636
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
>
> You also should moderate your language. :) Most people here are rational
> and not stupid, but they may value different things than you do. For
> example, some people value the 4% speed improvement that
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
> demonstrated a compiler could achieve on some programs by fiddling
> intelligently with the evaluation order. It's not obvious to me that this
> 4% is worth the bugs it implies, but it's also not obvious to me that it's
> not.
>
What 4% improvement? The paper discussed a 4% *variance*. Performance
changed plus or *minus* 4%, depending on the various conditions.
Nowhere in that paper was it stated that undefined order caused a flat 4%
speed improvement.
--
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/ae024454-b8c0-4208-a107-f4a6e248684f%40isocpp.org.
------=_Part_381_1796015009.1468360033636
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jef=
frey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">You also should moderate your language. :) Most people here are ratio=
nal and not stupid, but they may value different things than you do. For ex=
ample, some people value the 4% speed improvement that=C2=A0<a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2016%2Fp0145r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEv2nK7ZYo=
lVGD7e_uQ78o0-WyYHQ';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fpapers%2F2016%2Fp0145r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NEv2nK7ZYolVGD7e_uQ78o0-WyYHQ';return true;">http://www.open-std.org/<w=
br>jtc1/sc22/wg21/docs/papers/<wbr>2016/p0145r2.pdf</a> demonstrated a comp=
iler could achieve on some programs by fiddling intelligently with the eval=
uation order. It's not obvious to me that this 4% is worth the bugs it =
implies, but it's also not obvious to me that it's not.</div></bloc=
kquote><div><br>What 4% improvement? The paper discussed a 4% <i>variance</=
i>. Performance changed plus or <i>minus</i> 4%, depending on the various c=
onditions.<br><br>Nowhere in that paper was it stated that undefined order =
caused a flat 4% speed improvement.</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/ae024454-b8c0-4208-a107-f4a6e248684f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae024454-b8c0-4208-a107-f4a6e248684f=
%40isocpp.org</a>.<br />
------=_Part_381_1796015009.1468360033636--
------=_Part_380_910761023.1468360033636--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 14:55:42 -0700
Raw View
On Tue, Jul 12, 2016 at 2:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> You also should moderate your language. :) Most people here are rational
>> and not stupid, but they may value different things than you do. For
>> example, some people value the 4% speed improvement that
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
>> demonstrated a compiler could achieve on some programs by fiddling
>> intelligently with the evaluation order. It's not obvious to me that this 4%
>> is worth the bugs it implies, but it's also not obvious to me that it's not.
>
>
> What 4% improvement? The paper discussed a 4% variance. Performance changed
> plus or minus 4%, depending on the various conditions.
>
> Nowhere in that paper was it stated that undefined order caused a flat 4%
> speed improvement.
Right, the paper shows a +/-4% variance, meaning there's at least 4%
performance on the table for some programs if the optimizers can be
made smarter. In particular, if the optimizer can identify the
programs for which reversing the argument evaluation order causes a 4%
improvement, it could do that and get the 4% improvement.
Folks are worried about closing off that possibility. It's true that
optimizers haven't been taught to do this in the many years they've
been allowed to, but now there's evidence people should be looking
harder in this direction. If folks look over the next 3 years and
nothing materializes, that becomes a stronger argument to nail down
the left-to-right order in C++20.
Jeffrey
--
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/CANh-dX%3DTZ74tj8h1f4j%2B_vcPYx0N92CsCz-uVnMJSTxDed7OqQ%40mail.gmail.com.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 22:56:48 +0100
Raw View
--001a114038d285290c053777582d
Content-Type: text/plain; charset=UTF-8
On 12 Jul 2016 10:47 p.m., "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
>
>
> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> You also should moderate your language. :) Most people here are rational
and not stupid, but they may value different things than you do. For
example, some people value the 4% speed improvement that
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
demonstrated a compiler could achieve on some programs by fiddling
intelligently with the evaluation order. It's not obvious to me that this
4% is worth the bugs it implies, but it's also not obvious to me that it's
not.
>
>
> What 4% improvement? The paper discussed a 4% variance. Performance
changed plus or minus 4%, depending on the various conditions.
>
> Nowhere in that paper was it stated that undefined order caused a flat 4%
speed improvement.
>
So an oracle or perfect PGO would get that 4% in its entirety. And that's
just a binary choice between LTR and RTL, not full permutation of ordering.
--
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/CAJnLdOYKdfOKrqAZNaKY0%3DwQ-YszEEwNvUhaRr0oPizb3ecznw%40mail.gmail.com.
--001a114038d285290c053777582d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 12 Jul 2016 10:47 p.m., "Nicol Bolas" <<a href=3D"mailto:jm=
ckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:<=
br>
>><br>
>> You also should moderate your language. :) Most people here are ra=
tional and not stupid, but they may value different things than you do. For=
example, some people value the 4% speed improvement that=C2=A0<a href=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf">http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf</a> demonstrat=
ed a compiler could achieve on some programs by fiddling intelligently with=
the evaluation order. It's not obvious to me that this 4% is worth the=
bugs it implies, but it's also not obvious to me that it's not.<br=
>
><br>
><br>
> What 4% improvement? The paper discussed a 4% variance. Performance ch=
anged plus or minus 4%, depending on the various conditions.<br>
><br>
> Nowhere in that paper was it stated that undefined order caused a flat=
4% speed improvement.<br>
></p>
<p dir=3D"ltr">So an oracle or perfect PGO would get that 4% in its entiret=
y. And that's just a binary choice between LTR and RTL, not full permut=
ation of ordering. </p>
<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/CAJnLdOYKdfOKrqAZNaKY0%3DwQ-YszEEwNvU=
haRr0oPizb3ecznw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYKdfOKrq=
AZNaKY0%3DwQ-YszEEwNvUhaRr0oPizb3ecznw%40mail.gmail.com</a>.<br />
--001a114038d285290c053777582d--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 22:59:32 +0100
Raw View
--94eb2c0762c242afb505377762de
Content-Type: text/plain; charset=UTF-8
On 12 Jul 2016 10:14 p.m., "Miro Knejp" <miro.knejp@gmail.com> wrote:
>
> Am 12.07.2016 um 21:23 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>>
>>
>>>>
>>>> auto inserts = {v.insert(v.end(), args)...};
>>>
>>> That makes it an initializer_list, meaning the values are const,
meaning you cannot move them out.
>>> Just saying.
>>
>>
>> Moving iterators?
>
> The values in an initializer_list are const, so there is no moving the
values out of it without const_cast and a deep sip of UB.
In the example, the values of the initializer_list are iterators. I'm
questioning whether moving an iterator (at least one to a normal container)
is ever something one would wish to do.
--
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/CAJnLdObNU2cqcv0utM1OkFjB7dVvaVPBThE-kBdKap0da4_5oQ%40mail.gmail.com.
--94eb2c0762c242afb505377762de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 12 Jul 2016 10:14 p.m., "Miro Knejp" <<a href=3D"mailto:mir=
o.knejp@gmail.com">miro.knejp@gmail.com</a>> wrote:<br>
><br>
> Am 12.07.2016 um 21:23 schrieb 'Edward Catmur' via ISO C++ Sta=
ndard - Future Proposals:<br>
>><br>
>> =C2=A0<br>
>>>><br>
>>>> auto inserts =3D {v.insert(v.end(), args)...};<br>
>>><br>
>>> That makes it an initializer_list, meaning the values are cons=
t, meaning you cannot move them out.<br>
>>> Just saying.<br>
>><br>
>><br>
>> =C2=A0Moving iterators?<br>
><br>
> The values in an initializer_list are const, so there is no moving the=
values out of it without const_cast and a deep sip of UB.</p>
<p dir=3D"ltr">In the example, the values of the initializer_list are itera=
tors. I'm questioning whether moving an iterator (at least one to a nor=
mal container) is ever something one would wish to do. </p>
<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/CAJnLdObNU2cqcv0utM1OkFjB7dVvaVPBThE-=
kBdKap0da4_5oQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObNU2cqcv0u=
tM1OkFjB7dVvaVPBThE-kBdKap0da4_5oQ%40mail.gmail.com</a>.<br />
--94eb2c0762c242afb505377762de--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 12 Jul 2016 15:00:41 -0700 (PDT)
Raw View
------=_Part_7800_942665946.1468360841466
Content-Type: multipart/alternative;
boundary="----=_Part_7801_2040781900.1468360841467"
------=_Part_7801_2040781900.1468360841467
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 12:29:04 PM UTC-4, Edward Catmur wrote:
>
> On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:
>>>
>>> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>>> >
>>> > The right decision is strict left-to-right order of evaluation for all
>>> expressions, with side-effects fully completed as they are evaluated.
>>>
>>> That sounds like a performance nightmare.
>>>
>>
>> I've heard a lot of "sounds like" out of people defending the undefined
>> order rules. I've heard far less "certainly is". Is there any genuine
>> evidence of this "performance nightmare", or is it just fear of the unknown?
>>
>
> I can't speak for anyone else. In my case it is induction from
> observations that many existing optimizations depend to some extent on
> breaking naive intuitions of ordering.
>
>
>> How many compilers actually use the undefined evaluation order rules to
>> optimize code? Do they re-order expressions based on what is best for that
>> specific expression? Or do they always evaluate expressions in an arbitrary
>> order? Because if such flexibility is not actually making code faster, then
>> the variance is pointless and should be done away with.
>>
>
> It does not matter whether compilers are currently able to exploit their
> freedom.
>
Yes it does matter.
On one side, we have a very clear fact: this "feature" of C++ is very
difficult to use correctly. The evidence for this is the fact that people *keep
using it wrong*.
On the other side, you put forth, not a factual performance lost, but a
*prediction* that future compilers won't be able to compile code as well as
they might.
Why should we value a *possible* future which may never come to past more
than a certain present that we have to live with daily?
The free lunch is over. Clock speeds are not getting any faster. If there
> is any prospect of the freedom being useful in future then it should be
> retained until we know for sure one way or the other, especially if new
> instructions could help compilers exploit it.
>
If there is any *genuine* prospect of such freedom being useful in the
future, then we can add specific syntax to loosen the rules in those places
where you could see a performance gain.
> The reason for choosing strict left-to-right order is that it's trivial
>>> to explain, matches the order in which code is read, and matches other
>>> languages such as Java.
>>>
>>> Any experienced user reads code blocks as a unit, just as any proficient
>>> reader of natural languages reads sentences and paragraphs in a single
>>> glance.
>>>
>>
>> Let's pretend this was true (despite the undeniable fact that
>> "experienced users" make these mistakes too).
>>
>> So what? Are we supposed to restrict C++ to "experienced users" as you
>> define it?
>>
>
> It would be better to restrict C++ to experienced users than to make it
> useless to them.
>
Hyperbole is not helpful in proving your point. The largest variance
measured for this feature was 4%. A 4% performance drop is not going to
make C++ "useless".
--
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/572a183b-0e61-4d9d-8bd2-73addd76989f%40isocpp.org.
------=_Part_7801_2040781900.1468360841467
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 12, 2016 at 12:29:04 PM UTC-4, Edward Cat=
mur 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"><di=
v><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"z24Jcz6yCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">On Monday, July 11, 2016 at 8:27:41 PM UTC-=
4, Edward Catmur wrote:<span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a rel=3D"nofollow">h=
yman...@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare.</p></blockquote></=
span><div><br>I've heard a lot of "sounds like" out of people=
defending the undefined order rules. I've heard far less "certain=
ly is". Is there any genuine evidence of this "performance nightm=
are", or is it just fear of the unknown?<br></div></div></blockquote><=
div><br></div><div>I can't speak for anyone else. In my case it is indu=
ction from observations that many existing optimizations depend to some ext=
ent on breaking naive intuitions of ordering.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>How many compilers actually u=
se the undefined evaluation order rules to optimize code? Do they re-order =
expressions based on what is best for that specific expression? Or do they =
always evaluate expressions in an arbitrary order? Because if such flexibil=
ity is not actually making code faster, then the variance is pointless and =
should be done away with.<br></div></div></blockquote><div>=C2=A0</div><div=
>It does not matter whether compilers are currently able to exploit their f=
reedom.</div></div></div></div></blockquote><div><br>Yes it does matter.<br=
><br>On one side, we have a very clear fact: this "feature" of C+=
+ is very difficult to use correctly. The evidence for this is the fact tha=
t people <i>keep using it wrong</i>.<br><br>On the other side, you put fort=
h, not a factual performance lost, but a <i>prediction</i> that future comp=
ilers won't be able to compile code as well as they might.<br><br>Why s=
hould we value a <i>possible</i> future which may never come to past more t=
han a certain present that we have to live with daily?<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote"><div>The free lunch is over. Clock speeds are not getting any f=
aster. If there is any prospect of the freedom being useful in future then =
it should be retained until we know for sure one way or the other, especial=
ly if new instructions could help compilers exploit it.</div></div></div></=
div></blockquote><div><br>If there is any <i>genuine</i> prospect of such f=
reedom being useful in the future, then we can add specific syntax to loose=
n the rules in those places where you could see a performance gain.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance.<br></p></blockquote></span><div><br>Let's pretend this=
was true (despite the undeniable fact that "experienced users" m=
ake these mistakes too).<br><br>So what? Are we supposed to restrict C++ to=
"experienced users" as you define it?<br></div></div></blockquot=
e><div><br></div><div>It would be better to restrict C++ to experienced use=
rs than to make it useless to them.</div></div></div></div></blockquote><di=
v><br>Hyperbole is not helpful in proving your point. The largest variance =
measured for this feature was 4%. A 4% performance drop is not going to mak=
e C++ "useless".</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/572a183b-0e61-4d9d-8bd2-73addd76989f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/572a183b-0e61-4d9d-8bd2-73addd76989f=
%40isocpp.org</a>.<br />
------=_Part_7801_2040781900.1468360841467--
------=_Part_7800_942665946.1468360841466--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Wed, 13 Jul 2016 00:03:01 +0200
Raw View
This is a multi-part message in MIME format.
--------------C3059558696A86CD0D3979BA
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 12.07.2016 um 23:59 schrieb 'Edward Catmur' via ISO C++ Standard -
Future Proposals:
>
>
> On 12 Jul 2016 10:14 p.m., "Miro Knejp" <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
> >
> > Am 12.07.2016 um 21:23 schrieb 'Edward Catmur' via ISO C++ Standard
> - Future Proposals:
> >>
> >>
> >>>>
> >>>> auto inserts = {v.insert(v.end(), args)...};
> >>>
> >>> That makes it an initializer_list, meaning the values are const,
> meaning you cannot move them out.
> >>> Just saying.
> >>
> >>
> >> Moving iterators?
> >
> > The values in an initializer_list are const, so there is no moving
> the values out of it without const_cast and a deep sip of UB.
>
> In the example, the values of the initializer_list are iterators. I'm
> questioning whether moving an iterator (at least one to a normal
> container) is ever something one would wish to do.
>
Ah right I missed that part. Nevermind.
--
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/312b98fb-d60d-9c71-983e-fa6aa0c9a4f7%40gmail.com.
--------------C3059558696A86CD0D3979BA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 23:59 schrieb 'Edward Catmur' via ISO C++ Standard
- Future Proposals:<br>
<blockquote
cite=3D"mid:CAJnLdObNU2cqcv0utM1OkFjB7dVvaVPBThE-kBdKap0da4_5oQ@mail.gmail.=
com"
type=3D"cite">
<p dir=3D"ltr"><br>
On 12 Jul 2016 10:14 p.m., "Miro Knejp" <<a
moz-do-not-send=3D"true" href=3D"mailto:miro.knejp@gmail.com">mir=
o.knejp@gmail.com</a>>
wrote:<br>
><br>
> Am 12.07.2016 um 21:23 schrieb 'Edward Catmur' via ISO C++
Standard - Future Proposals:<br>
>><br>
>> =C2=A0<br>
>>>><br>
>>>> auto inserts =3D {v.insert(v.end(), args)...};<br>
>>><br>
>>> That makes it an initializer_list, meaning the
values are const, meaning you cannot move them out.<br>
>>> Just saying.<br>
>><br>
>><br>
>> =C2=A0Moving iterators?<br>
><br>
> The values in an initializer_list are const, so there is no
moving the values out of it without const_cast and a deep sip of
UB.</p>
<p dir=3D"ltr">In the example, the values of the initializer_list
are iterators. I'm questioning whether moving an iterator (at
least one to a normal container) is ever something one would
wish to do. </p>
</blockquote>
Ah right I missed that part. Nevermind.<br>
<br>
</body>
</html>
<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/312b98fb-d60d-9c71-983e-fa6aa0c9a4f7%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/312b98fb-d60d-9c71-983e-fa6aa0c9a4f7%=
40gmail.com</a>.<br />
--------------C3059558696A86CD0D3979BA--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 12 Jul 2016 15:08:04 -0700 (PDT)
Raw View
------=_Part_1008_99383956.1468361284477
Content-Type: multipart/alternative;
boundary="----=_Part_1009_1166215578.1468361284478"
------=_Part_1009_1166215578.1468361284478
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 5:56:04 PM UTC-4, Jeffrey Yasskin wrote:
>
> On Tue, Jul 12, 2016 at 2:47 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> >
> >
> > On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
> >>
> >> You also should moderate your language. :) Most people here are
> rational
> >> and not stupid, but they may value different things than you do. For
> >> example, some people value the 4% speed improvement that
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
> >> demonstrated a compiler could achieve on some programs by fiddling
> >> intelligently with the evaluation order. It's not obvious to me that
> this 4%
> >> is worth the bugs it implies, but it's also not obvious to me that it's
> not.
> >
> >
> > What 4% improvement? The paper discussed a 4% variance. Performance
> changed
> > plus or minus 4%, depending on the various conditions.
> >
> > Nowhere in that paper was it stated that undefined order caused a flat
> 4%
> > speed improvement.
>
> Right, the paper shows a +/-4% variance, meaning there's at least 4%
> performance on the table for some programs if the optimizers can be
> made smarter. In particular, if the optimizer can identify the
> programs for which reversing the argument evaluation order causes a 4%
> improvement, it could do that and get the 4% improvement.
>
My point is that there are also cases where there is a 4% performance *loss*
compared to LTR. That LTR gives up-to-4% better performance in some cases.
If performance is the primary opposing argument, then that fact needs to be
weighed as well.
> Folks are worried about closing off that possibility. It's true that
> optimizers haven't been taught to do this in the many years they've
> been allowed to, but now there's evidence people should be looking
> harder in this direction. If folks look over the next 3 years and
> nothing materializes, that becomes a stronger argument to nail down
> the left-to-right order in C++20.
>
If this was a firm promise that, if nobody has *proven* otherwise, then
we'd close things up in C++20, I'd be fine with it. But it isn't.
The problem with this reasoning is that this argument will be no less valid
in 2019 than it is in 2016. You can *always* say that in "3-5 years",
compilers will take greater advantage of this.
What arguments can you use against this in 2019 that you *couldn't* in
2016? The only argument you can use is that it's 3 years later, but that's
not a strong argument. After all, it's been 18 years since C++98, and these
things have yet to materialize.
There's always going to be some excuse to keep kicking the can along. To
put it off for another standard cycle. To say that we'll get those
optimizations any year now.
What is the end-game here? What is the critical point where we can make
this sort of things *stop*?
--
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/f2ec86e9-16f9-42cb-bc7f-5b38c95b0ba2%40isocpp.org.
------=_Part_1009_1166215578.1468361284478
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, July 12, 2016 at 5:56:04 PM UTC-4, Jef=
frey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Jul=
12, 2016 at 2:47 PM, Nicol Bolas <<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"musElRbECgAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">jmck...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wro=
te:
<br>>>
<br>>> You also should moderate your language. :) Most people here ar=
e rational
<br>>> and not stupid, but they may value different things than you d=
o. For
<br>>> example, some people value the 4% speed improvement that
<br>>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2016/p0145r2.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0145r2.pdf\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNEv2nK7ZYolVGD7e_uQ78o0-WyYHQ';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0145r2.pdf\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNEv2nK7ZYolVGD7e_uQ78o0-WyYHQ';return true=
;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0145r=
2.pdf</a>
<br>>> demonstrated a compiler could achieve on some programs by fidd=
ling
<br>>> intelligently with the evaluation order. It's not obvious =
to me that this 4%
<br>>> is worth the bugs it implies, but it's also not obvious to=
me that it's not.
<br>>
<br>>
<br>> What 4% improvement? The paper discussed a 4% variance. Performanc=
e changed
<br>> plus or minus 4%, depending on the various conditions.
<br>>
<br>> Nowhere in that paper was it stated that undefined order caused a =
flat 4%
<br>> speed improvement.
<br>
<br>Right, the paper shows a +/-4% variance, meaning there's at least 4=
%
<br>performance on the table for some programs if the optimizers can be
<br>made smarter. In particular, if the optimizer can identify the
<br>programs for which reversing the argument evaluation order causes a 4%
<br>improvement, it could do that and get the 4% improvement.<br></blockquo=
te><div><br>My point is that there are also cases where there is a 4% perfo=
rmance <i>loss</i> compared to LTR. That LTR gives up-to-4% better performa=
nce in some cases. If performance is the primary opposing argument, then th=
at fact needs to be weighed as well.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
Folks are worried about closing off that possibility. It's true that
<br>optimizers haven't been taught to do this in the many years they=
9;ve
<br>been allowed to, but now there's evidence people should be looking
<br>harder in this direction. If folks look over the next 3 years and
<br>nothing materializes, that becomes a stronger argument to nail down
<br>the left-to-right order in C++20.<br></blockquote><div><br>If this was =
a firm promise that, if nobody has <i>proven</i> otherwise, then we'd c=
lose things up in C++20, I'd be fine with it. But it isn't.<br><br>=
The problem with this reasoning is that this argument will be no less valid=
in 2019 than it is in 2016. You can <i>always</i> say that in "3-5 ye=
ars", compilers will take greater advantage of this.<br><br>What argum=
ents can you use against this in 2019 that you <i>couldn't</i> in 2016?=
The only argument you can use is that it's 3 years later, but that'=
;s not a strong argument. After all, it's been 18 years since C++98, an=
d these things have yet to materialize.<br><br>There's always going to =
be some excuse to keep kicking the can along. To put it off for another sta=
ndard cycle. To say that we'll get those optimizations any year now.<br=
><br>What is the end-game here? What is the critical point where we can mak=
e this sort of things <i>stop</i>?<br></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/f2ec86e9-16f9-42cb-bc7f-5b38c95b0ba2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2ec86e9-16f9-42cb-bc7f-5b38c95b0ba2=
%40isocpp.org</a>.<br />
------=_Part_1009_1166215578.1468361284478--
------=_Part_1008_99383956.1468361284477--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 12 Jul 2016 15:10:55 -0700 (PDT)
Raw View
------=_Part_2049_1660562287.1468361455353
Content-Type: multipart/alternative;
boundary="----=_Part_2050_1010767805.1468361455353"
------=_Part_2050_1010767805.1468361455353
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 5:56:53 PM UTC-4, Edward Catmur wrote:
>
>
> On 12 Jul 2016 10:47 p.m., "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
> >
> >
> >
> > On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
> >>
> >> You also should moderate your language. :) Most people here are
> rational and not stupid, but they may value different things than you do.
> For example, some people value the 4% speed improvement that
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
> demonstrated a compiler could achieve on some programs by fiddling
> intelligently with the evaluation order. It's not obvious to me that this
> 4% is worth the bugs it implies, but it's also not obvious to me that it's
> not.
> >
> >
> > What 4% improvement? The paper discussed a 4% variance. Performance
> changed plus or minus 4%, depending on the various conditions.
> >
> > Nowhere in that paper was it stated that undefined order caused a flat
> 4% speed improvement.
> >
>
> So an oracle or perfect PGO would get that 4% in its entirety.
>
"Could", not "would". After all, there are plenty of times where order is
entirely irrelevant to performance.
--
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/aea09237-dcba-47c1-8952-b636303cf99f%40isocpp.org.
------=_Part_2050_1010767805.1468361455353
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 12, 2016 at 5:56:53 PM UTC-4, Edward Catm=
ur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><br>
On 12 Jul 2016 10:47 p.m., "Nicol Bolas" <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"SjtyBiLECgAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>&g=
t; wrote:<br>
><br>
><br>
><br>
> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:<=
br>
>><br>
>> You also should moderate your language. :) Most people here are ra=
tional and not stupid, but they may value different things than you do. For=
example, some people value the 4% speed improvement that=C2=A0<a href=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%=
2Fpapers%2F2016%2Fp0145r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEv2nK=
7ZYolVGD7e_uQ78o0-WyYHQ';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg=
21%2Fdocs%2Fpapers%2F2016%2Fp0145r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNEv2nK7ZYolVGD7e_uQ78o0-WyYHQ';return true;">http://www.open-std.or=
g/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2016/p0145r2.pdf</a> demonstrated a =
compiler could achieve on some programs by fiddling intelligently with the =
evaluation order. It's not obvious to me that this 4% is worth the bugs=
it implies, but it's also not obvious to me that it's not.<br>
><br>
><br>
> What 4% improvement? The paper discussed a 4% variance. Performance ch=
anged plus or minus 4%, depending on the various conditions.<br>
><br>
> Nowhere in that paper was it stated that undefined order caused a flat=
4% speed improvement.<br>
></p>
<p dir=3D"ltr">So an oracle or perfect PGO would get that 4% in its entiret=
y.</p></blockquote><div><br>"Could", not "would". After=
all, there are plenty of times where order is entirely irrelevant to perfo=
rmance.<br></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/aea09237-dcba-47c1-8952-b636303cf99f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aea09237-dcba-47c1-8952-b636303cf99f=
%40isocpp.org</a>.<br />
------=_Part_2050_1010767805.1468361455353--
------=_Part_2049_1660562287.1468361455353--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 18:38:47 -0400
Raw View
--001a1141ca48cbe20b053777ef95
Content-Type: text/plain; charset=UTF-8
How can defining the order of evaluation increase the maintenance burden?
When you tell people not to write h(f(), g()) because that can cause
problems, you are doing so because you are using a language that causes the
problems and you have internalized this knowledge. (That's what I mean by
Stockholm Syndrome.) But it's a fact (that we have encountered in our
company, not just in theory) that such code can easily enter production and
work "correctly" for years before an environment change alters the
evaluation order and breaks it. WIth a defined order, code either works or
doesn't, and it's immediately apparent.
I accept that there are people who believe that not specifying function
argument evaluation order is important for optimization
Nevin's point, that a programmer should feel free to reorder a = b() + c()
+ d() as a = b() + (c() + d()) at the source level is wrong and can lead to
undefined behavior, so that is not evidence against defined evaluation
order. Quite the contrary.
I do not agree at all that the C++ should treat a() << b(), a() = b(), and a()
+ b() differently.
As to the obviousness of the examples, find naifs and ask what they think
something like
Point p = Point(read<int>(), read<int>());
does.
--
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/CAHSYqdbRuuzTJ7NpFDHjiAK7ytM7o3CY2xR5bgMBvd9VsurXbg%40mail.gmail.com.
--001a1141ca48cbe20b053777ef95
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">How =
can defining the order of evaluation increase the maintenance burden?=C2=A0=
When you tell people not to write <font face=3D"monospace, monospace">h(f(=
), g())</font> because that can cause problems, you are doing so because yo=
u are using a language that causes the problems and you have internalized t=
his knowledge. =C2=A0(That's what I mean by Stockholm Syndrome.) =C2=A0=
But it's a fact (that we have encountered in our company, not just in t=
heory) that such code can easily enter production and work "correctly&=
quot; for years before an environment change alters the evaluation order an=
d breaks it.=C2=A0 WIth a defined order, code either works or doesn't, =
and it's immediately apparent.<br><br>I accept that there are people wh=
o believe that not specifying function argument evaluation order is importa=
nt for optimization<br><br>Nevin's point, that a programmer should feel=
free to reorder <font face=3D"monospace, monospace">a =3D b() + c() + d()<=
/font> as <font face=3D"monospace, monospace">a =3D b() + (c() + d())</font=
> at the source level is wrong and can lead to undefined behavior, so that =
is not evidence against defined evaluation order.=C2=A0 Quite the contrary.=
<br><br>I do not agree at all that the C++ should treat <font face=3D"monos=
pace, monospace">a() << b()</font>, <font face=3D"monospace, monospac=
e">a() =3D b()</font>, and <font face=3D"monospace, monospace">a() + b()</f=
ont> differently.<br><br>As to the obviousness of the examples, find naifs =
and ask what they think something like<br><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 Point p =3D Point(read<int>(), read<int>());</=
font><br>does.<br></div></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/CAHSYqdbRuuzTJ7NpFDHjiAK7ytM7o3CY2xR5=
bgMBvd9VsurXbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbRuuzTJ7Np=
FDHjiAK7ytM7o3CY2xR5bgMBvd9VsurXbg%40mail.gmail.com</a>.<br />
--001a1141ca48cbe20b053777ef95--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 12 Jul 2016 16:12:58 -0700
Raw View
--94eb2c063e9e0ddb340537786a8f
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 3:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Tuesday, July 12, 2016 at 5:56:04 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> On Tue, Jul 12, 2016 at 2:47 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> >
>> >
>> > On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
>> >>
>> >> You also should moderate your language. :) Most people here are
>> rational
>> >> and not stupid, but they may value different things than you do. For
>> >> example, some people value the 4% speed improvement that
>> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
>> >> demonstrated a compiler could achieve on some programs by fiddling
>> >> intelligently with the evaluation order. It's not obvious to me that
>> this 4%
>> >> is worth the bugs it implies, but it's also not obvious to me that
>> it's not.
>> >
>> >
>> > What 4% improvement? The paper discussed a 4% variance. Performance
>> changed
>> > plus or minus 4%, depending on the various conditions.
>> >
>> > Nowhere in that paper was it stated that undefined order caused a flat
>> 4%
>> > speed improvement.
>>
>> Right, the paper shows a +/-4% variance, meaning there's at least 4%
>> performance on the table for some programs if the optimizers can be
>> made smarter. In particular, if the optimizer can identify the
>> programs for which reversing the argument evaluation order causes a 4%
>> improvement, it could do that and get the 4% improvement.
>>
>
> My point is that there are also cases where there is a 4% performance
> *loss* compared to LTR. That LTR gives up-to-4% better performance in
> some cases. If performance is the primary opposing argument, then that fact
> needs to be weighed as well.
>
That's why I said "some programs" and "if the optimizer can identify the
programs".
Folks are worried about closing off that possibility. It's true that
>> optimizers haven't been taught to do this in the many years they've
>> been allowed to, but now there's evidence people should be looking
>> harder in this direction. If folks look over the next 3 years and
>> nothing materializes, that becomes a stronger argument to nail down
>> the left-to-right order in C++20.
>>
>
> If this was a firm promise that, if nobody has *proven* otherwise, then
> we'd close things up in C++20, I'd be fine with it. But it isn't.
>
> The problem with this reasoning is that this argument will be no less
> valid in 2019 than it is in 2016. You can *always* say that in "3-5
> years", compilers will take greater advantage of this.
>
> What arguments can you use against this in 2019 that you *couldn't* in
> 2016? The only argument you can use is that it's 3 years later, but that's
> not a strong argument. After all, it's been 18 years since C++98, and these
> things have yet to materialize.
>
> There's always going to be some excuse to keep kicking the can along. To
> put it off for another standard cycle. To say that we'll get those
> optimizations any year now.
>
> What is the end-game here? What is the critical point where we can make
> this sort of things *stop*?
>
There is no guaranteed end-game. It stops when the committee becomes
convinced to make a change. That's kinda the nature of standardization work.
Jeffrey
--
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/CANh-dX%3D6sv36yHA4cR5kxTR6NucVV-tL1%2BTqSQYvMxsHwXcAjQ%40mail.gmail.com.
--94eb2c063e9e0ddb340537786a8f
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=
ue, Jul 12, 2016 at 3:08 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank" class=3D"gmail-cremed gmail-cr=
emed cremed">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday, July =
12, 2016 at 5:56:04 PM UTC-4, Jeffrey Yasskin wrote:<span class=3D"gmail-">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 12, 2016 at 2=
:47 PM, Nicol Bolas <<a rel=3D"nofollow" class=3D"gmail-cremed gmail-cre=
med cremed">jmck...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wro=
te:
<br>>>
<br>>> You also should moderate your language. :) Most people here ar=
e rational
<br>>> and not stupid, but they may value different things than you d=
o. For
<br>>> example, some people value the 4% speed improvement that
<br>>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2016/p0145r2.pdf" rel=3D"nofollow" target=3D"_blank" class=3D"gmail-cremed =
gmail-cremed cremed">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
6/p0145r2.pdf</a>
<br>>> demonstrated a compiler could achieve on some programs by fidd=
ling
<br>>> intelligently with the evaluation order. It's not obvious =
to me that this 4%
<br>>> is worth the bugs it implies, but it's also not obvious to=
me that it's not.
<br>>
<br>>
<br>> What 4% improvement? The paper discussed a 4% variance. Performanc=
e changed
<br>> plus or minus 4%, depending on the various conditions.
<br>>
<br>> Nowhere in that paper was it stated that undefined order caused a =
flat 4%
<br>> speed improvement.
<br>
<br>Right, the paper shows a +/-4% variance, meaning there's at least 4=
%
<br>performance on the table for some programs if the optimizers can be
<br>made smarter. In particular, if the optimizer can identify the
<br>programs for which reversing the argument evaluation order causes a 4%
<br>improvement, it could do that and get the 4% improvement.<br></blockquo=
te></span><div><br>My point is that there are also cases where there is a 4=
% performance <i>loss</i> compared to LTR. That LTR gives up-to-4% better p=
erformance in some cases. If performance is the primary opposing argument, =
then that fact needs to be weighed as well.<br></div></div></blockquote><di=
v><br></div><div>That's why I said "some programs" and "=
if the optimizer can identify the programs".</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Folks are worried about closing off that possibility. It's true that
<br>optimizers haven't been taught to do this in the many years they=
9;ve
<br>been allowed to, but now there's evidence people should be looking
<br>harder in this direction. If folks look over the next 3 years and
<br>nothing materializes, that becomes a stronger argument to nail down
<br>the left-to-right order in C++20.<br></blockquote></span><div><br>If th=
is was a firm promise that, if nobody has <i>proven</i> otherwise, then we&=
#39;d close things up in C++20, I'd be fine with it. But it isn't.<=
br><br>The problem with this reasoning is that this argument will be no les=
s valid in 2019 than it is in 2016. You can <i>always</i> say that in "=
;3-5 years", compilers will take greater advantage of this.<br><br>Wha=
t arguments can you use against this in 2019 that you <i>couldn't</i> i=
n 2016? The only argument you can use is that it's 3 years later, but t=
hat's not a strong argument. After all, it's been 18 years since C+=
+98, and these things have yet to materialize.<br><br>There's always go=
ing to be some excuse to keep kicking the can along. To put it off for anot=
her standard cycle. To say that we'll get those optimizations any year =
now.<br><br>What is the end-game here? What is the critical point where we =
can make this sort of things <i>stop</i>?</div></div></blockquote><div>=C2=
=A0</div></div>There is no guaranteed end-game. It stops when the committee=
becomes convinced to make a change. That's kinda the nature of standar=
dization work.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">Jeffrey</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/CANh-dX%3D6sv36yHA4cR5kxTR6NucVV-tL1%=
2BTqSQYvMxsHwXcAjQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3D6sv=
36yHA4cR5kxTR6NucVV-tL1%2BTqSQYvMxsHwXcAjQ%40mail.gmail.com</a>.<br />
--94eb2c063e9e0ddb340537786a8f--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 12 Jul 2016 19:27:36 -0400
Raw View
--001a11415a045052550537789d87
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I don't really want to do the rounds over these arguments again, having
done so before. The reason I expressed myself earlier today was to leave a
trace since we are re-doing a thread that I thought had been processed.
I accept that in your perspective, Point p =3D Point(read<int>(),
read<int>()); should have definite meaning even if read<int>() has
side-effects, and even replacing read<int>() by something more abstract to
make the situation less-evidently suspicious given the existing language. I
take it that should problem arise due to someone writing such code, you and
your colleagues find it worthwhile to open up the side-effecting functions
and investigate their sources to make sense of the then-non-unspecified
code. I understand that its seems obvious to you that such code is easier
to maintaint, It's not a willingness I share, the obviousness does not
strike me, and it does not seem beneficial to me. I also use languages
where these expressions are fully-ordered, do debugging for beginners that
make such dependencies idiomatic, and appreciate being able to tell them
=C2=ABjust no=C2=BB with C++.
I look forward to reading your proposal.
2016-07-12 18:38 GMT-04:00 Hyman Rosen <hyman.rosen@gmail.com>:
> How can defining the order of evaluation increase the maintenance burden?
> When you tell people not to write h(f(), g()) because that can cause
> problems, you are doing so because you are using a language that causes t=
he
> problems and you have internalized this knowledge. (That's what I mean b=
y
> Stockholm Syndrome.) But it's a fact (that we have encountered in our
> company, not just in theory) that such code can easily enter production a=
nd
> work "correctly" for years before an environment change alters the
> evaluation order and breaks it. WIth a defined order, code either works =
or
> doesn't, and it's immediately apparent.
>
> I accept that there are people who believe that not specifying function
> argument evaluation order is important for optimization
>
> Nevin's point, that a programmer should feel free to reorder a =3D b() +
> c() + d() as a =3D b() + (c() + d()) at the source level is wrong and can
> lead to undefined behavior, so that is not evidence against defined
> evaluation order. Quite the contrary.
>
> I do not agree at all that the C++ should treat a() << b(), a() =3D b(),
> and a() + b() differently.
>
> As to the obviousness of the examples, find naifs and ask what they think
> something like
> Point p =3D Point(read<int>(), read<int>());
> does.
>
> --
> 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/CAHSYqdbRuuz=
TJ7NpFDHjiAK7ytM7o3CY2xR5bgMBvd9VsurXbg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbRuu=
zTJ7NpFDHjiAK7ytM7o3CY2xR5bgMBvd9VsurXbg%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>
--=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/CAKiZDp3ri%3DvTC71wnczOvJK9sEC2rho%3Dgho0nzyqMB4=
sEQimUQ%40mail.gmail.com.
--001a11415a045052550537789d87
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I don't really want to do the rounds over th=
ese arguments again, having done so before. The reason I expressed myself e=
arlier today was to leave a trace since we are re-doing a thread that I tho=
ught had been processed.<br><br></div>I accept that in your perspective, <f=
ont face=3D"monospace, monospace">Point p =3D Point(read<int>(), read=
<int>()); </font>should have definite meaning even if read<int>=
() has side-effects, and even replacing read<int>() by something more=
abstract to make the situation less-evidently suspicious given the existin=
g language. I take it that should problem arise due to someone writing such=
code, you and your colleagues find it worthwhile to open up the side-effec=
ting functions and investigate their sources to make sense of the then-non-=
unspecified code. I understand that its seems obvious to you that such code=
is easier to maintaint, It's not a willingness I share, the obviousnes=
s does not strike me, and it does not seem beneficial to me. I also use lan=
guages where these expressions are fully-ordered, do debugging for beginner=
s that make such dependencies idiomatic, and appreciate being able to tell =
them =C2=ABjust no=C2=BB with C++.<br><br></div>I look forward to reading y=
our proposal.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">2016-07-12 18:38 GMT-04:00 Hyman Rosen <span dir=3D"ltr"><<a href=
=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</=
a>></span>:<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"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote">How can defining the order of =
evaluation increase the maintenance burden?=C2=A0 When you tell people not =
to write <font face=3D"monospace, monospace">h(f(), g())</font> because tha=
t can cause problems, you are doing so because you are using a language tha=
t causes the problems and you have internalized this knowledge. =C2=A0(That=
's what I mean by Stockholm Syndrome.) =C2=A0But it's a fact (that =
we have encountered in our company, not just in theory) that such code can =
easily enter production and work "correctly" for years before an =
environment change alters the evaluation order and breaks it.=C2=A0 WIth a =
defined order, code either works or doesn't, and it's immediately a=
pparent.<br><br>I accept that there are people who believe that not specify=
ing function argument evaluation order is important for optimization<br><br=
>Nevin's point, that a programmer should feel free to reorder <font fac=
e=3D"monospace, monospace">a =3D b() + c() + d()</font> as <font face=3D"mo=
nospace, monospace">a =3D b() + (c() + d())</font> at the source level is w=
rong and can lead to undefined behavior, so that is not evidence against de=
fined evaluation order.=C2=A0 Quite the contrary.<br><br>I do not agree at =
all that the C++ should treat <font face=3D"monospace, monospace">a() <&=
lt; b()</font>, <font face=3D"monospace, monospace">a() =3D b()</font>, and=
<font face=3D"monospace, monospace">a() + b()</font> differently.<br><br>A=
s to the obviousness of the examples, find naifs and ask what they think so=
mething like<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 Point p =
=3D Point(read<int>(), read<int>());</font><br>does.<br></div><=
/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" 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@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/CAHSYqdbRuuzTJ7NpFDHjiAK7ytM7o3CY2xR5=
bgMBvd9VsurXbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAHSYqdbRuuzTJ7NpFDHjiAK7ytM7o3CY2xR5bgMBvd9VsurXbg%40mail.gmail.com</=
a>.<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" 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/CAKiZDp3ri%3DvTC71wnczOvJK9sEC2rho%3D=
gho0nzyqMB4sEQimUQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3ri%3D=
vTC71wnczOvJK9sEC2rho%3Dgho0nzyqMB4sEQimUQ%40mail.gmail.com</a>.<br />
--001a11415a045052550537789d87--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 12 Jul 2016 16:43:12 -0700
Raw View
Em ter=C3=A7a-feira, 12 de julho de 2016, =C3=A0s 18:38:47 PDT, Hyman Rosen=
escreveu:
> As to the obviousness of the examples, find naifs and ask what they think
> something like
> Point p =3D Point(read<int>(), read<int>());
> does.
Well, naifs won't be able to read it because they don't know the language i=
n=20
the first place. They have to learn the language before they can express an=
=20
opinion.
As someone who programmed in the early 1990s, it's "obvious" to me that=20
arguments are pushed right to left, because it's the C calling convention. =
The=20
point being: what's obvious to me is not obvious to you.
--=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/2795482.aWeKmJMqgD%40tjmaciei-mobl1.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 12 Jul 2016 21:24:38 -0400
Raw View
--001a114a8498c306fe05377a3f3c
Content-Type: text/plain; charset=UTF-8
On Jul 12, 2016 7:27 PM, "Patrice Roy" <patricer@gmail.com> wrote:
> I look forward to reading your proposal.
Don't be disingenuous. You know very well that such a proposal would not
pass. It is impossible to convince enough people that l-to-r should be
adopted. The "but optimization!" folks hold too much sway. The fact that
r-to-l for assignments passed in C++17 is further evidence that there is no
hope. And then there are the people who just like the status quo.
I am just the lone crackpot shouting in the wilderness.
--
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/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMfLOaQQWV7We7-uGHQ%40mail.gmail.com.
--001a114a8498c306fe05377a3f3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Jul 12, 2016 7:27 PM, "Patrice Roy" <<a href=3D"mailto:patr=
icer@gmail.com">patricer@gmail.com</a>> wrote:</p>
<p dir=3D"ltr">> I look forward to reading your proposal.<br></p>
<p dir=3D"ltr">Don't be disingenuous.=C2=A0 You know very well that suc=
h a proposal would not pass.=C2=A0 It is impossible to convince enough peop=
le that l-to-r should be adopted.=C2=A0 The "but optimization!" f=
olks hold too much sway.=C2=A0 The fact that r-to-l for assignments passed =
in C++17 is further evidence that there is no hope.=C2=A0 And then there ar=
e the people who just like the status quo.</p>
<p dir=3D"ltr">I am just the lone crackpot shouting in the wilderness.</p>
<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/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMf=
LOaQQWV7We7-uGHQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbP%2BoJv=
aNNc69DqPg2qcD9hEJZhMfLOaQQWV7We7-uGHQ%40mail.gmail.com</a>.<br />
--001a114a8498c306fe05377a3f3c--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 12 Jul 2016 23:05:48 -0400
Raw View
--001a11467f9ea752b405377ba9c7
Content-Type: text/plain; charset=UTF-8
There were debates in Oulu, and there were people for and against what you
care so much about. Maybe you'll be able to find convincing arguments; I
don't pretend to know what the outcome will be should a strong proposal be
presented, and I was being sincere when I said wrote that I'm looking
forward to it. I, and others, are reasonable beings, given arguments we
find convincing. I don't doubt you're convinced, I think that shows
strongly.
Good luck, should you decide to go forward with this. If there is a
proposal, particularly if the proposal's a strong one, I'm sure it will be
examined and discussed rigorously.
2016-07-12 21:24 GMT-04:00 Hyman Rosen <hyman.rosen@gmail.com>:
>
> On Jul 12, 2016 7:27 PM, "Patrice Roy" <patricer@gmail.com> wrote:
>
> > I look forward to reading your proposal.
>
> Don't be disingenuous. You know very well that such a proposal would not
> pass. It is impossible to convince enough people that l-to-r should be
> adopted. The "but optimization!" folks hold too much sway. The fact that
> r-to-l for assignments passed in C++17 is further evidence that there is no
> hope. And then there are the people who just like the status quo.
>
> I am just the lone crackpot shouting in the wilderness.
>
> --
> 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/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMfLOaQQWV7We7-uGHQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMfLOaQQWV7We7-uGHQ%40mail.gmail.com?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/CAKiZDp1YDrP%3Dk_DBq8tBdRzXK_nPBy1_mMFAcsp-QiU%3DwEoZYQ%40mail.gmail.com.
--001a11467f9ea752b405377ba9c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>There were debates in Oulu, and there were people for=
and against what you care so much about. Maybe you'll be able to find =
convincing arguments; I don't pretend to know what the outcome will be =
should a strong proposal be presented, and I was being sincere when I said =
wrote that I'm looking forward to it. I, and others, are reasonable bei=
ngs, given arguments we find convincing. I don't doubt you're convi=
nced, I think that shows strongly.<br><br></div>Good luck, should you decid=
e to go forward with this. If there is a proposal, particularly if the prop=
osal's a strong one, I'm sure it will be examined and discussed rig=
orously.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>2016-07-12 21:24 GMT-04:00 Hyman Rosen <span dir=3D"ltr"><<a href=3D"ma=
ilto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>>=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr">=
<br>
On Jul 12, 2016 7:27 PM, "Patrice Roy" <<a href=3D"mailto:patr=
icer@gmail.com" target=3D"_blank">patricer@gmail.com</a>> wrote:</p>
<p dir=3D"ltr">> I look forward to reading your proposal.<br></p>
</span><p dir=3D"ltr">Don't be disingenuous.=C2=A0 You know very well t=
hat such a proposal would not pass.=C2=A0 It is impossible to convince enou=
gh people that l-to-r should be adopted.=C2=A0 The "but optimization!&=
quot; folks hold too much sway.=C2=A0 The fact that r-to-l for assignments =
passed in C++17 is further evidence that there is no hope.=C2=A0 And then t=
here are the people who just like the status quo.</p>
<p dir=3D"ltr">I am just the lone crackpot shouting in the wilderness.</p><=
span class=3D"">
<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" target=3D"_=
blank">std-proposals+unsubscribe@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/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMf=
LOaQQWV7We7-uGHQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMfLOaQQWV7We7-uGHQ%40mail.gmail.c=
om</a>.<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" 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/CAKiZDp1YDrP%3Dk_DBq8tBdRzXK_nPBy1_mM=
FAcsp-QiU%3DwEoZYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1YDrP%=
3Dk_DBq8tBdRzXK_nPBy1_mMFAcsp-QiU%3DwEoZYQ%40mail.gmail.com</a>.<br />
--001a11467f9ea752b405377ba9c7--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Tue, 12 Jul 2016 20:19:10 -0700 (PDT)
Raw View
------=_Part_12241_1009388834.1468379950192
Content-Type: multipart/alternative;
boundary="----=_Part_12242_237976104.1468379950192"
------=_Part_12242_237976104.1468379950192
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:
>
> There were debates in Oulu, and there were people for and against what you
> care so much about.
>
We don't have access to the discussions, so we only know what is reported
here.
Was there discussion about whether assignment should be RTL vs LTR, or only
about whether or not to provide an order for function arguments?
If there were reasons brought up to have it be RTL instead of LTR, then any
paper suggesting to change that would need to address those reasons.
--
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/f4445b47-0552-473d-a68c-2c97b7965ff3%40isocpp.org.
------=_Part_12242_237976104.1468379950192
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 12, 2016 at 11:05:52 PM UTC-4, Patrice Ro=
y 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>=
There were debates in Oulu, and there were people for and against what you =
care so much about. </div></div></blockquote><div><br></div><div>We don'=
;t have access to the discussions, so we only know what is reported here.<b=
r></div><div>Was there discussion about whether assignment should be RTL vs=
LTR, or only about whether or not to provide an order for function argumen=
ts?</div><div>If there were reasons brought up to have it be RTL instead of=
LTR, then any paper suggesting to change that would need to address those =
reasons.</div><div><br></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/f4445b47-0552-473d-a68c-2c97b7965ff3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3=
%40isocpp.org</a>.<br />
------=_Part_12242_237976104.1468379950192--
------=_Part_12241_1009388834.1468379950192--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 12 Jul 2016 23:59:49 -0400
Raw View
--001a11431d34cf416705377c6a48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Discussions are not public (to leave people maximal freedom of expression),
and they are held in subgroups as well as in plenary if needed (sometimes,
it's just something simple or something that everyone agrees on).
In this specific case, the paper on expression ordering suggested fixing
seven orderings (if my memory's correct) and only one was (highly)
problematic in the eyes of many, including myself. The proposal was split,
the other six (again, from memory) were accepted, and this one was not. The
arguments for and against are well-known to those who read this list.
Committee members represent various application domains and do not hold a
uniform or homogeneous view of what =C2=ABgood programming=C2=BB is, but th=
ey all
care for the language and its users (being users themselves), so even if
some might not agree with their decisions (which is fair), know that the
debates are held and when subjects are debated like this one, it's
reasonable to expect debates are held by committee members too.
In the end, it's a consensus decision, and consensus was not reached for
this part of the ordering proposal. As Jeffreay and others stated, should
people care enough to try to convince the committee to revisit its position
on this specific issue, there are mechanisms that allow this (NB Comments,
for example, or a proposal targeted towards C++20).
2016-07-12 23:19 GMT-04:00 Greg Marr <gregmmarr@gmail.com>:
> On Tuesday, July 12, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:
>>
>> There were debates in Oulu, and there were people for and against what
>> you care so much about.
>>
>
> We don't have access to the discussions, so we only know what is reported
> here.
> Was there discussion about whether assignment should be RTL vs LTR, or
> only about whether or not to provide an order for function arguments?
> If there were reasons brought up to have it be RTL instead of LTR, then
> any paper suggesting to change that would need to address those reasons.
>
> --
> 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/f4445b47-055=
2-473d-a68c-2c97b7965ff3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-05=
52-473d-a68c-2c97b7965ff3%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAKiZDp3owHC9XuAvWzv5rCi1SO3meQhwtMvVYhz%3DN9iUL=
CtNAg%40mail.gmail.com.
--001a11431d34cf416705377c6a48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Discussions are not public (to leave people maximal freedo=
m of expression), and they are held in subgroups as well as in plenary if n=
eeded (sometimes, it's just something simple or something that everyone=
agrees on).<br><br>In this specific case, the paper on expression ordering=
suggested fixing seven orderings (if my memory's correct) and only one=
was (highly) problematic in the eyes of many, including myself. The propos=
al was split, the other six (again, from memory) were accepted, and this on=
e was not. The arguments for and against are well-known to those who read t=
his list.<br><br>Committee members represent various application domains an=
d do not hold a uniform or homogeneous view of what =C2=ABgood programming=
=C2=BB is, but they all care for the language and its users (being users th=
emselves), so even if some might not agree with their decisions (which is f=
air), know that the debates are held and when subjects are debated like thi=
s one, it's reasonable to expect debates are held by committee members =
too.<br><br>In the end, it's a consensus decision, and consensus was no=
t reached for this part of the ordering proposal. As Jeffreay and others st=
ated, should people care enough to try to convince the committee to revisit=
its position on this specific issue, there are mechanisms that allow this =
(NB Comments, for example, or a proposal targeted towards C++20).<br></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-07-12 23:19 =
GMT-04:00 Greg Marr <span dir=3D"ltr"><<a href=3D"mailto:gregmmarr@gmail=
..com" target=3D"_blank">gregmmarr@gmail.com</a>></span>:<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"><span class=3D"">On Tuesday, July 12, 2=
016 at 11:05:52 PM UTC-4, Patrice Roy wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>There were debates in Oulu, and there were p=
eople for and against what you care so much about. </div></div></blockquote=
><div><br></div></span><div>We don't have access to the discussions, so=
we only know what is reported here.<br></div><div>Was there discussion abo=
ut whether assignment should be RTL vs LTR, or only about whether or not to=
provide an order for function arguments?</div><div>If there were reasons b=
rought up to have it be RTL instead of LTR, then any paper suggesting to ch=
ange that would need to address those reasons.</div><div><br></div></div><s=
pan class=3D"">
<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" target=3D"_=
blank">std-proposals+unsubscribe@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/f4445b47-0552-473d-a68c-2c97b7965ff3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-=
473d-a68c-2c97b7965ff3%40isocpp.org</a>.<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" 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/CAKiZDp3owHC9XuAvWzv5rCi1SO3meQhwtMvV=
Yhz%3DN9iULCtNAg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3owHC9Xu=
AvWzv5rCi1SO3meQhwtMvVYhz%3DN9iULCtNAg%40mail.gmail.com</a>.<br />
--001a11431d34cf416705377c6a48--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 12 Jul 2016 22:09:46 -0700
Raw View
Em ter=C3=A7a-feira, 12 de julho de 2016, =C3=A0s 21:24:38 PDT, Hyman Rosen=
escreveu:
> The fact that
> r-to-l for assignments passed in C++17 is further evidence that there is =
no
> hope.
Note that this RTL for assignments was done like that to match the=20
associativity of the operator in question:
man 7 operator:
Operator Associativity
() [] -> . left to right
! ~ ++ -- + - (type) * & sizeof right to left
* / % left to right
+ - left to right
<< >> left to right
< <=3D > >=3D left to right
=3D=3D !=3D left to right
& left to right
^ left to right
| left to right
&& left to right
|| left to right
?: right to left
=3D +=3D -=3D *=3D /=3D %=3D <<=3D >>=3D &=3D ^=3D |=3D right to =
left
, left to right
--=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/2612056.zWaNbkkGAy%40tjmaciei-mobl1.
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Wed, 13 Jul 2016 10:11:48 +0200
Raw View
> I do not agree at all that the C++ should treat a() << b(), a() = b(), and
> a() + b() differently.
Hi,
I've been following this thread on and off for a while now and am
still surprised at the above statement and that LTR for everything is
the only logical thing to do.
As Thiago already noted that RTL for assignments matches the
associativity of the operator in question.
Also one other thing why I would find LTR for everything counter
intuitive is because of my mental model:
- you take a stone (variable)
- you carve something into it (LTR operation on that variable)
- you carve some more (LTR operation on that variable)
- you decide to box the resulting statue (RTL so now I can create the
box - get a variable from for e.g. a function)
- you box the statue
First part is LTR and the assignment switches to RTL since that's the
order you would use in real life.
For everything LTR it would be:
- you create a box
- you create a statue
- you want to put the statue into the box and find out that you have
to remove the hands from the statue because the box is not of the
right size/type
Creating a box before I know what I'll put in is not what I'd do in
real life so I never read code from left to right for assignment but
first glance the variable and move straight to the right part and then
back the left one and I'd expect the language to behave the same way
if the order is defined.
On the other hand because most (all?) of the time I don't like code
that depends on the order anyway it would take a while before the all
LTR surprise would hit me... It's possible that I'd never even noticed
that the order exists...
Teaching this would for me be more intuitive (since it's from real
life) than saying that everything is defined LTR (hey grab me a box,
it doesn't matter that you don't know what I'll use it for) and ignore
my natural mental model (and yes I get the left and right confused all
the time - there's a reason why people don't like me to navigate while
they're driving - so using left and right to describe something is not
as natural for all of us as you'd think so unifying it for the sake of
unification doesn't help me much).
Regards,
Domen
--
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/CAKgx6BLA2cDhBCsphnTpuznGsMvBi33_TD0OQ%3DVZ4-5MYUpTiA%40mail.gmail.com.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 13 Jul 2016 11:14:41 -0400
Raw View
--001a114fda9c6921c7053785d967
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Note that this RTL for assignments was done like that to match the
> associativity of the operator in question:
But why? Associativity (and precedence) tell you how to fully parenthesize
an expression. Why should that inform the order in which subexpressions
are evaluated? If I begin with the fully parenthesized expressions a() =
(b() = c()) and ((a() = b()) = c()) the first parenthesized as for right
associativity and the second for left, the new standard requires that the
order of evaluation for both is c(), b(), a(), so how does associativity
even matter? And why should a() << b() require a different order than a()
<<= b() while a() + b() remains unspecified? How does that help people to
read and write C++?
DV's explanation that intuition suggests that the RHS be evaluated first
for assignments seems more reasonable, but I don't find it sufficiently
compelling to overcome the simplicity of teaching that evaluation is
left-to-right, always. Even if it runs counter to intuition, it's a
mistake that you can only make once because when you learn the rule, it's
so sharp and easy that you can't forget it.
--
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/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com.
--001a114fda9c6921c7053785d967
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 W=
ed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Note that this RTL for assig=
nments was done like that to match the<br>
associativity of the operator in question:</blockquote><div><br>But why?=C2=
=A0 Associativity (and precedence) tell you how to fully parenthesize an ex=
pression.=C2=A0 Why should that inform the order in which subexpressions ar=
e evaluated?=C2=A0 If I begin with the fully parenthesized expressions=C2=
=A0<font face=3D"monospace, monospace">a() =3D (b() =3D c())</font> and <fo=
nt face=3D"monospace, monospace">((a() =3D b()) =3D c()) </font>the first p=
arenthesized as for right associativity and the second for left, the new st=
andard requires that the order of evaluation for both is <font face=3D"mono=
space, monospace">c(), b(), a()</font>, so how does associativity even matt=
er?=C2=A0 And why should <font face=3D"monospace, monospace">a() << b=
()</font> require a different order than <font face=3D"monospace, monospace=
">a() <<=3D b()</font>=C2=A0while <font face=3D"monospace, monospace"=
>a() + b()</font> remains unspecified?=C2=A0 How does that help people to r=
ead and write C++?<br><br>DV's explanation that intuition suggests that=
the RHS be evaluated first for assignments seems more reasonable, but I do=
n't find it sufficiently compelling to overcome the simplicity of teach=
ing that evaluation is left-to-right, always.=C2=A0 Even if it runs counter=
to intuition, it's a mistake that you can only make once because when =
you learn the rule, it's so sharp and easy that you can't forget it=
..<br>=C2=A0</div></div></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/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx=
4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy4gvUm=
YCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com</a>.<br />
--001a114fda9c6921c7053785d967--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Wed, 13 Jul 2016 11:36:52 -0400
Raw View
--001a11490e3aab917905378627cb
Content-Type: text/plain; charset=UTF-8
Why would the simplicity of teaching anything matter more than anything
else? IEEE 754 is incredibly hard to teach, with many odd nuances to it,
yet it is used because those nuances lead to better results. Modeling after
the mathematical concepts underlying the operations may lead to more
difficult to teach, but also has clear benefits, as DV explained.
On Wed, Jul 13, 2016 at 11:14 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Wed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>>
>> Note that this RTL for assignments was done like that to match the
>> associativity of the operator in question:
>
>
> But why? Associativity (and precedence) tell you how to fully
> parenthesize an expression. Why should that inform the order in which
> subexpressions are evaluated? If I begin with the fully parenthesized
> expressions a() = (b() = c()) and ((a() = b()) = c()) the first
> parenthesized as for right associativity and the second for left, the new
> standard requires that the order of evaluation for both is c(), b(), a(),
> so how does associativity even matter? And why should a() << b() require
> a different order than a() <<= b() while a() + b() remains unspecified?
> How does that help people to read and write C++?
>
> DV's explanation that intuition suggests that the RHS be evaluated first
> for assignments seems more reasonable, but I don't find it sufficiently
> compelling to overcome the simplicity of teaching that evaluation is
> left-to-right, always. Even if it runs counter to intuition, it's a
> mistake that you can only make once because when you learn the rule, it's
> so sharp and easy that you can't forget it.
>
>
> --
> 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/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com?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/CAMD6iD_YO2RfUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com.
--001a11490e3aab917905378627cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why would the simplicity of teaching anything matter more =
than anything else? IEEE 754 is incredibly hard to teach, with many odd nua=
nces to it, yet it is used because those nuances lead to better results. Mo=
deling after the mathematical concepts underlying the operations may lead t=
o more difficult to teach, but also has clear benefits, as DV explained.=C2=
=A0<div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Wed, Jul 13, 2016 at 11:14 AM, Hyman Rosen <span dir=3D"ltr"><=
<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmai=
l.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">=
On Wed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <span dir=3D"ltr"><<a h=
ref=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a=
>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">Note that this RTL for as=
signments was done like that to match the<br>
associativity of the operator in question:</blockquote></span><div><br>But =
why?=C2=A0 Associativity (and precedence) tell you how to fully parenthesiz=
e an expression.=C2=A0 Why should that inform the order in which subexpress=
ions are evaluated?=C2=A0 If I begin with the fully parenthesized expressio=
ns=C2=A0<font face=3D"monospace, monospace">a() =3D (b() =3D c())</font> an=
d <font face=3D"monospace, monospace">((a() =3D b()) =3D c()) </font>the fi=
rst parenthesized as for right associativity and the second for left, the n=
ew standard requires that the order of evaluation for both is <font face=3D=
"monospace, monospace">c(), b(), a()</font>, so how does associativity even=
matter?=C2=A0 And why should <font face=3D"monospace, monospace">a() <&=
lt; b()</font> require a different order than <font face=3D"monospace, mono=
space">a() <<=3D b()</font>=C2=A0while <font face=3D"monospace, monos=
pace">a() + b()</font> remains unspecified?=C2=A0 How does that help people=
to read and write C++?<br><br>DV's explanation that intuition suggests=
that the RHS be evaluated first for assignments seems more reasonable, but=
I don't find it sufficiently compelling to overcome the simplicity of =
teaching that evaluation is left-to-right, always.=C2=A0 Even if it runs co=
unter to intuition, it's a mistake that you can only make once because =
when you learn the rule, it's so sharp and easy that you can't forg=
et it.<br>=C2=A0</div></div></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" 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@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/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx=
4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.c=
om</a>.<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" 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/CAMD6iD_YO2RfUQGRJvEuhoFGtmp5vd-FHsjg=
OOfcL91r1V2YWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2RfUQGR=
JvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com</a>.<br />
--001a11490e3aab917905378627cb--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Wed, 13 Jul 2016 11:51:25 -0400
Raw View
--001a113e40b8aeb8ff0537865b86
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Not to get everything off-topic; I know everything can be taught, as was
pointed out to me on another occasion, but caring about the =C2=ABteachabil=
ity=C2=BB
of the language is not without interest. That being said, what is more
=C2=ABteachable=C2=BB is highly subjective in some cases (this one included=
, as both
Hyman and myself care for it, but don't agree as to what is easier to
explain in some aspects).
That being said, instructor and teachers have a responsibility here, and
the current rules can be taught (they have been for a while), just as new
ones could. I think we should go for more objective arguments should this
discussion continue. And I really would prefer to discuss over an actual
proposal (it helps organize and focus discussions).
Cheers!
2016-07-13 11:36 GMT-04:00 Ren Industries <renindustries@gmail.com>:
> Why would the simplicity of teaching anything matter more than anything
> else? IEEE 754 is incredibly hard to teach, with many odd nuances to it,
> yet it is used because those nuances lead to better results. Modeling aft=
er
> the mathematical concepts underlying the operations may lead to more
> difficult to teach, but also has clear benefits, as DV explained.
>
>
> On Wed, Jul 13, 2016 at 11:14 AM, Hyman Rosen <hyman.rosen@gmail.com>
> wrote:
>
>> On Wed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <thiago@macieira.org>
>> wrote:
>>>
>>> Note that this RTL for assignments was done like that to match the
>>> associativity of the operator in question:
>>
>>
>> But why? Associativity (and precedence) tell you how to fully
>> parenthesize an expression. Why should that inform the order in which
>> subexpressions are evaluated? If I begin with the fully parenthesized
>> expressions a() =3D (b() =3D c()) and ((a() =3D b()) =3D c()) the first
>> parenthesized as for right associativity and the second for left, the ne=
w
>> standard requires that the order of evaluation for both is c(), b(), a()=
,
>> so how does associativity even matter? And why should a() << b()
>> require a different order than a() <<=3D b() while a() + b() remains
>> unspecified? How does that help people to read and write C++?
>>
>> DV's explanation that intuition suggests that the RHS be evaluated first
>> for assignments seems more reasonable, but I don't find it sufficiently
>> compelling to overcome the simplicity of teaching that evaluation is
>> left-to-right, always. Even if it runs counter to intuition, it's a
>> mistake that you can only make once because when you learn the rule, it'=
s
>> so sharp and easy that you can't forget it.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CAHSYqdZQy4=
gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy=
4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
> --
> 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/CAMD6iD_YO2R=
fUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2=
RfUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>
--=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/CAKiZDp2EUJ0h4hUr-dBrHPN8A7veOMAVJMzc-YE1ON1ZGN5=
xtw%40mail.gmail.com.
--001a113e40b8aeb8ff0537865b86
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Not to get everything off-topic; I know everything ca=
n be taught, as was pointed out to me on another occasion, but caring about=
the =C2=ABteachability=C2=BB of the language is not without interest. That=
being said, what is more =C2=ABteachable=C2=BB is highly subjective in som=
e cases (this one included, as both Hyman and myself care for it, but don&#=
39;t agree as to what is easier to explain in some aspects).<br><br></div><=
div>That being said, instructor and teachers have a responsibility here, an=
d the current rules can be taught (they have been for a while), just as new=
ones could. I think we should go for more objective arguments should this =
discussion continue. And I really would prefer to discuss over an actual pr=
oposal (it helps organize and focus discussions).<br><br></div><div>Cheers!=
<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2=
016-07-13 11:36 GMT-04:00 Ren Industries <span dir=3D"ltr"><<a href=3D"m=
ailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a=
>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why would =
the simplicity of teaching anything matter more than anything else? IEEE 75=
4 is incredibly hard to teach, with many odd nuances to it, yet it is used =
because those nuances lead to better results. Modeling after the mathematic=
al concepts underlying the operations may lead to more difficult to teach, =
but also has clear benefits, as DV explained.=C2=A0<div><br></div></div><di=
v><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Wed, Jul 13, 2016 at 11:14 AM, Hyman Rosen <span dir=3D"ltr"><<a h=
ref=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Wed, Jul 13,=
2016 at 1:09 AM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:t=
hiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Note that this RTL for assignments was d=
one like that to match the<br>
associativity of the operator in question:</blockquote></span><div><br>But =
why?=C2=A0 Associativity (and precedence) tell you how to fully parenthesiz=
e an expression.=C2=A0 Why should that inform the order in which subexpress=
ions are evaluated?=C2=A0 If I begin with the fully parenthesized expressio=
ns=C2=A0<font face=3D"monospace, monospace">a() =3D (b() =3D c())</font> an=
d <font face=3D"monospace, monospace">((a() =3D b()) =3D c()) </font>the fi=
rst parenthesized as for right associativity and the second for left, the n=
ew standard requires that the order of evaluation for both is <font face=3D=
"monospace, monospace">c(), b(), a()</font>, so how does associativity even=
matter?=C2=A0 And why should <font face=3D"monospace, monospace">a() <&=
lt; b()</font> require a different order than <font face=3D"monospace, mono=
space">a() <<=3D b()</font>=C2=A0while <font face=3D"monospace, monos=
pace">a() + b()</font> remains unspecified?=C2=A0 How does that help people=
to read and write C++?<br><br>DV's explanation that intuition suggests=
that the RHS be evaluated first for assignments seems more reasonable, but=
I don't find it sufficiently compelling to overcome the simplicity of =
teaching that evaluation is left-to-right, always.=C2=A0 Even if it runs co=
unter to intuition, it's a mistake that you can only make once because =
when you learn the rule, it's so sharp and easy that you can't forg=
et it.<br>=C2=A0</div></div></div></div><span>
<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" target=3D"_=
blank">std-proposals+unsubscribe@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/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx=
4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.c=
om</a>.<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" 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@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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2RfUQGRJvEuhoFGtmp5vd-FHsjg=
OOfcL91r1V2YWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAMD6iD_YO2RfUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com</=
a>.<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" 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/CAKiZDp2EUJ0h4hUr-dBrHPN8A7veOMAVJMzc=
-YE1ON1ZGN5xtw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2EUJ0h4hUr=
-dBrHPN8A7veOMAVJMzc-YE1ON1ZGN5xtw%40mail.gmail.com</a>.<br />
--001a113e40b8aeb8ff0537865b86--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Wed, 13 Jul 2016 08:59:43 -0700 (PDT)
Raw View
------=_Part_10635_867339335.1468425583355
Content-Type: multipart/alternative;
boundary="----=_Part_10636_1914075248.1468425583355"
------=_Part_10636_1914075248.1468425583355
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 12, 2016 at 11:59:52 PM UTC-4, Patrice Roy wrote:
>
> Discussions are not public (to leave people maximal freedom of
> expression), and they are held in subgroups as well as in plenary if needed
> (sometimes, it's just something simple or something that everyone agrees
> on).
>
I understand, and understand why. I was just reminding people that many
people here don't have access.
> In this specific case, the paper on expression ordering suggested fixing
> seven orderings (if my memory's correct) and only one was (highly)
> problematic in the eyes of many, including myself. The proposal was split,
> the other six (again, from memory) were accepted, and this one was not. The
> arguments for and against are well-known to those who read this list.
>
I think you might have missed the point of my question. I know that
function argument evaluation order is controversial and was discussed. I'm
not asking about this, as no order was chosen at this point, and as has
been mentioned in this thread, passing C++17 as-is won't prevent this from
being changed in the future.
I asked whether anyone knows whether RTL vs LTR for assignment was ever
controversial and discussed, or just accepted as it was specified in the
initial proposal. This is because as has been pointed out, once C++17 is
passed with this order, then it's fixed forever.
I'm not sure at this point whether one way is "better" than the other, just
asking whether it was discussed, and if so, if there were particular
reasons why RTL was chosen over LTR. It has always made sense to me for
the reasons given here, but the reasons given by Hyman Rosen for why LTR is
better are definitely compelling.
In the end, it's a consensus decision, and consensus was not reached for
> this part of the ordering proposal. As Jeffreay and others stated, should
> people care enough to try to convince the committee to revisit its position
> on this specific issue, there are mechanisms that allow this (NB Comments,
> for example, or a proposal targeted towards C++20).
>
The RTL vs LTR for assignment would have to be a NB Comment at this point.
In order for a change to be accepted, I would imagine that it would need
to address any reasons that RTL vs LTR was chosen.
> 2016-07-12 23:19 GMT-04:00 Greg Marr <greg...@gmail.com <javascript:>>:
>
>> On Tuesday, July 12, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:
>>>
>>> There were debates in Oulu, and there were people for and against what
>>> you care so much about.
>>>
>>
>> We don't have access to the discussions, so we only know what is reported
>> here.
>> Was there discussion about whether assignment should be RTL vs LTR, or
>> only about whether or not to provide an order for function arguments?
>> If there were reasons brought up to have it be RTL instead of LTR, then
>> any paper suggesting to change that would need to address those reasons.
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%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/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c%40isocpp.org.
------=_Part_10636_1914075248.1468425583355
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 12, 2016 at 11:59:52 PM UTC-4, Patrice Ro=
y 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">Discu=
ssions are not public (to leave people maximal freedom of expression), and =
they are held in subgroups as well as in plenary if needed (sometimes, it&#=
39;s just something simple or something that everyone agrees on).<br></div>=
</blockquote><div><br></div><div>I understand, and understand why. =C2=A0I =
was just reminding people that many people here don't have access.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">In this specific case, the paper on expression ordering suggested fixi=
ng seven orderings (if my memory's correct) and only one was (highly) p=
roblematic in the eyes of many, including myself. The proposal was split, t=
he other six (again, from memory) were accepted, and this one was not. The =
arguments for and against are well-known to those who read this list.<br></=
div></blockquote><div><br></div><div>I think you might have missed the poin=
t of my question. =C2=A0I know that function argument evaluation order is c=
ontroversial and was discussed. =C2=A0I'm not asking about this, as no =
order was chosen at this point, and as has been mentioned in this thread, p=
assing C++17 as-is won't prevent this from being changed in the future.=
</div><div><br></div><div>I asked whether anyone knows whether RTL vs LTR f=
or assignment was ever controversial and discussed, or just accepted as it =
was specified in the initial proposal. =C2=A0This is because as has been po=
inted out, once C++17 is passed with this order, then it's fixed foreve=
r.</div><div><br></div><div>I'm not sure at this point whether one way =
is "better" than the other, just asking whether it was discussed,=
and if so, if there were particular reasons why RTL was chosen over LTR. =
=C2=A0It has always made sense to me for the reasons given here, but the re=
asons given by Hyman Rosen for why LTR is better are definitely compelling.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">In the end, it's a consensus decision, and consensus was not r=
eached for this part of the ordering proposal. As Jeffreay and others state=
d, should people care enough to try to convince the committee to revisit it=
s position on this specific issue, there are mechanisms that allow this (NB=
Comments, for example, or a proposal targeted towards C++20).<br></div></b=
lockquote><div><br></div><div>The RTL vs LTR for assignment would have to b=
e a NB Comment at this point. =C2=A0In order for a change to be accepted, I=
would imagine that it would need to address any reasons that RTL vs LTR wa=
s chosen.</div><div>=C2=A0<br></div><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 class=3D"gmail_quote">2016-07-12 23:=
19 GMT-04:00 Greg Marr <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"pYV76vDXCgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">greg...@gmail.com</a>></span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, July 12=
, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>There were debates in Oulu, and there wer=
e people for and against what you care so much about. </div></div></blockqu=
ote><div><br></div></span><div>We don't have access to the discussions,=
so we only know what is reported here.<br></div><div>Was there discussion =
about whether assignment should be RTL vs LTR, or only about whether or not=
to provide an order for function arguments?</div><div>If there were reason=
s brought up to have it be RTL instead of LTR, then any paper suggesting to=
change that would need to address those reasons.</div><div><br></div></div=
><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
pYV76vDXCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"pYV76vDXCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/f4445b47-0552-473d-a68c-2c97b7965ff3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f4445b47-0552-473d-<wbr>a68c-=
2c97b7965ff3%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></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/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c=
%40isocpp.org</a>.<br />
------=_Part_10636_1914075248.1468425583355--
------=_Part_10635_867339335.1468425583355--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Wed, 13 Jul 2016 13:13:50 -0400
Raw View
--001a11431d346ac4580537878261
Content-Type: text/plain; charset=UTF-8
The orderings that were discussed were those proposed in wg21.link/p0145
The eight forms found on page 3 and 4 were what was proposed. As far as I
remember, the only one that did not reach consensus was form 4, for reasons
discussed here many times (should I have missed something, I hope someone
else who was in Oulu will correct me); in form 4, the ordering of b1,b2 and
b3 remains unspecified, but they cannot interleave (so it's not a complete
rejection).
I understand from this thread that there are some who disagree with form 5,
but that form did not seem to be surprising to anyone in Oulu, again as far
as I remember (my memory goes as far as Core work and Plenary sessions go;
I was not in Evolution when it was discussed there), and it has been
accepted as is. I'm not an expert on ISO procedure, but I'd wager (again,
correct me if I'm wrong here, as it's quite possible) that since it's been
accepted, people who think it's bad should probably push for a NB comment
at this stage.
As in committee meetings, we discuss what is brought up in the proposals,
that's pretty much the answer I can give to your questions, Greg. I hope
it's satisfactory.
2016-07-13 11:59 GMT-04:00 Greg Marr <gregmmarr@gmail.com>:
> On Tuesday, July 12, 2016 at 11:59:52 PM UTC-4, Patrice Roy wrote:
>>
>> Discussions are not public (to leave people maximal freedom of
>> expression), and they are held in subgroups as well as in plenary if needed
>> (sometimes, it's just something simple or something that everyone agrees
>> on).
>>
>
> I understand, and understand why. I was just reminding people that many
> people here don't have access.
>
>
>> In this specific case, the paper on expression ordering suggested fixing
>> seven orderings (if my memory's correct) and only one was (highly)
>> problematic in the eyes of many, including myself. The proposal was split,
>> the other six (again, from memory) were accepted, and this one was not. The
>> arguments for and against are well-known to those who read this list.
>>
>
> I think you might have missed the point of my question. I know that
> function argument evaluation order is controversial and was discussed. I'm
> not asking about this, as no order was chosen at this point, and as has
> been mentioned in this thread, passing C++17 as-is won't prevent this from
> being changed in the future.
>
> I asked whether anyone knows whether RTL vs LTR for assignment was ever
> controversial and discussed, or just accepted as it was specified in the
> initial proposal. This is because as has been pointed out, once C++17 is
> passed with this order, then it's fixed forever.
>
> I'm not sure at this point whether one way is "better" than the other,
> just asking whether it was discussed, and if so, if there were particular
> reasons why RTL was chosen over LTR. It has always made sense to me for
> the reasons given here, but the reasons given by Hyman Rosen for why LTR is
> better are definitely compelling.
>
> In the end, it's a consensus decision, and consensus was not reached for
>> this part of the ordering proposal. As Jeffreay and others stated, should
>> people care enough to try to convince the committee to revisit its position
>> on this specific issue, there are mechanisms that allow this (NB Comments,
>> for example, or a proposal targeted towards C++20).
>>
>
> The RTL vs LTR for assignment would have to be a NB Comment at this
> point. In order for a change to be accepted, I would imagine that it would
> need to address any reasons that RTL vs LTR was chosen.
>
>
>> 2016-07-12 23:19 GMT-04:00 Greg Marr <greg...@gmail.com>:
>>
>>> On Tuesday, July 12, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:
>>>>
>>>> There were debates in Oulu, and there were people for and against what
>>>> you care so much about.
>>>>
>>>
>>> We don't have access to the discussions, so we only know what is
>>> reported here.
>>> Was there discussion about whether assignment should be RTL vs LTR, or
>>> only about whether or not to provide an order for function arguments?
>>> If there were reasons brought up to have it be RTL instead of LTR, then
>>> any paper suggesting to change that would need to address those reasons.
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%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/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c%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/CAKiZDp1RosmU89eEUQ4SGO%3DyZa1P9OMEyh8ggwoQR-M%2B_Uyfaw%40mail.gmail.com.
--001a11431d346ac4580537878261
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>The orderings that were discussed were those pro=
posed in wg21.link/p0145<br><br></div>The eight forms found on page 3 and 4=
were what was proposed. As far as I remember, the only one that did not re=
ach consensus was form 4, for reasons discussed here many times (should I h=
ave missed something, I hope someone else who was in Oulu will correct me);=
in form 4, the ordering of b1,b2 and b3 remains unspecified, but they cann=
ot interleave (so it's not a complete rejection).<br><br>I understand f=
rom this thread that there are some who disagree with form 5, but that form=
did not seem to be surprising to anyone in Oulu, again as far as I remembe=
r (my memory goes as far as Core work and Plenary sessions go; I was not in=
Evolution when it was discussed there), and it has been accepted as is. I&=
#39;m not an expert on ISO procedure, but I'd wager (again, correct me =
if I'm wrong here, as it's quite possible) that since it's been=
accepted, people who think it's bad should probably push for a NB comm=
ent at this stage.<br><br></div>As in committee meetings, we discuss what i=
s brought up in the proposals, that's pretty much the answer I can give=
to your questions, Greg. I hope it's satisfactory.<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-07-13 11:59 GMT-04:00 =
Greg Marr <span dir=3D"ltr"><<a href=3D"mailto:gregmmarr@gmail.com" targ=
et=3D"_blank">gregmmarr@gmail.com</a>></span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday, July 12, 2016 at 11:=
59:52 PM UTC-4, Patrice Roy 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">Discussions are not public (to leave people maximal freed=
om of expression), and they are held in subgroups as well as in plenary if =
needed (sometimes, it's just something simple or something that everyon=
e agrees on).<br></div></blockquote><div><br></div></span><div>I understand=
, and understand why.=C2=A0 I was just reminding people that many people he=
re don't have access.</div><span class=3D""><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">In this specific case, the p=
aper on expression ordering suggested fixing seven orderings (if my memory&=
#39;s correct) and only one was (highly) problematic in the eyes of many, i=
ncluding myself. The proposal was split, the other six (again, from memory)=
were accepted, and this one was not. The arguments for and against are wel=
l-known to those who read this list.<br></div></blockquote><div><br></div><=
/span><div>I think you might have missed the point of my question.=C2=A0 I =
know that function argument evaluation order is controversial and was discu=
ssed.=C2=A0 I'm not asking about this, as no order was chosen at this p=
oint, and as has been mentioned in this thread, passing C++17 as-is won'=
;t prevent this from being changed in the future.</div><div><br></div><div>=
I asked whether anyone knows whether RTL vs LTR for assignment was ever con=
troversial and discussed, or just accepted as it was specified in the initi=
al proposal.=C2=A0 This is because as has been pointed out, once C++17 is p=
assed with this order, then it's fixed forever.</div><div><br></div><di=
v>I'm not sure at this point whether one way is "better" than=
the other, just asking whether it was discussed, and if so, if there were =
particular reasons why RTL was chosen over LTR.=C2=A0 It has always made se=
nse to me for the reasons given here, but the reasons given by Hyman Rosen =
for why LTR is better are definitely compelling.</div><span class=3D""><div=
><br></div><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">In the =
end, it's a consensus decision, and consensus was not reached for this =
part of the ordering proposal. As Jeffreay and others stated, should people=
care enough to try to convince the committee to revisit its position on th=
is specific issue, there are mechanisms that allow this (NB Comments, for e=
xample, or a proposal targeted towards C++20).<br></div></blockquote><div><=
br></div></span><div>The RTL vs LTR for assignment would have to be a NB Co=
mment at this point.=C2=A0 In order for a change to be accepted, I would im=
agine that it would need to address any reasons that RTL vs LTR was chosen.=
</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"></div><div><div class=3D"gmail_quote"><span class=3D"">2016-07-12 =
23:19 GMT-04:00 Greg Marr <span dir=3D"ltr"><<a rel=3D"nofollow">greg...=
@gmail.com</a>></span>:<br></span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D""><div dir=3D"ltr"><span>On Tuesday, July 12, 2016 at 11:05:52 PM U=
TC-4, Patrice Roy 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>There were debates in Oulu, and there were people for and agains=
t what you care so much about. </div></div></blockquote><div><br></div></sp=
an><div>We don't have access to the discussions, so we only know what i=
s reported here.<br></div><div>Was there discussion about whether assignmen=
t should be RTL vs LTR, or only about whether or not to provide an order fo=
r function arguments?</div><div>If there were reasons brought up to have it=
be RTL instead of LTR, then any paper suggesting to change that would need=
to address those reasons.</div><div><br></div></div></span><span><span cla=
ss=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/f4445b47-0552-473d-a68c-2c97b7965ff3%40isocpp.org</a>.<br>
</span></blockquote></div><br></div>
</blockquote></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" 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@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/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7572efc6-b6dd-=
4cd2-bdb0-039e9ae7157c%40isocpp.org</a>.<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" 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/CAKiZDp1RosmU89eEUQ4SGO%3DyZa1P9OMEyh=
8ggwoQR-M%2B_Uyfaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1RosmU=
89eEUQ4SGO%3DyZa1P9OMEyh8ggwoQR-M%2B_Uyfaw%40mail.gmail.com</a>.<br />
--001a11431d346ac4580537878261--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 13 Jul 2016 13:14:39 -0400
Raw View
--001a1135729e6fe869053787865c
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 11:51 AM, Patrice Roy <patricer@gmail.com> wrote:
>
> That being said, instructor and teachers have a responsibility here, and
> the current rules can be taught (they have been for a while), just as new
> ones could. I think we should go for more objective arguments should this
> discussion continue. And I really would prefer to discuss over an actual
> proposal (it helps organize and focus discussions).
>
The f(new T, new T) problem didn't emerge into popular notice until 2009,
when Sutter presented it as GotW #56. (I recall being incredulous during
the Usenet discussion that C++ actually operated this way.) We've seen
several other cases on this list where even C++ experts are mistaken about
order of evaluation. I doubt that a meaningful number of C++ programmers
would recognize the problem with this code even now.
There's a difference between what is taught and what is remembered. When
the rules are complex and indeterminate, people will forget what they are.
(Overloading rules, anyone?) Further, the physical form of code exerts a
strong influence on what its readers believe it does. Seeing f declared as
taking a pair of smart pointers and being called as above tells the reader
with definiteness that memory is being handled correctly, whether or not
the language is really defined that way.
When you must teach someone that in a() << b(), a() is called before b(),
in a() <<= b(), b() is called before a(), and in a() + b(), a() and b() can
be called in either order, you are imposing a cognitive load of meaningless
difference, and that will make the student quickly forget the rules. When
you teach someone that in an expression, subexpressions are evaluated
left-to-right, you impart a simple and universal rule that no one will
forget.
--
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/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iMrJ8FwQax%2BLwusNtw%40mail.gmail.com.
--001a1135729e6fe869053787865c
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 W=
ed, Jul 13, 2016 at 11:51 AM, Patrice Roy <span dir=3D"ltr"><<a href=3D"=
mailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>></sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That being s=
aid, instructor and teachers have a responsibility here, and the current ru=
les can be taught (they have been for a while), just as new ones could. I t=
hink we should go for more objective arguments should this discussion conti=
nue. And I really would prefer to discuss over an actual proposal (it helps=
organize and focus discussions).</div></div></blockquote><div><br>The <fon=
t face=3D"monospace, monospace">f(new T, new T)</font> problem didn't e=
merge into popular notice until 2009, when Sutter presented it as GotW #56.=
=C2=A0(I recall being incredulous during the Usenet discussion that C++ ac=
tually operated this way.) =C2=A0We've seen several other cases on this=
list where even C++ experts are mistaken about order of evaluation.=C2=A0 =
I doubt that a meaningful number of C++ programmers would recognize the pro=
blem with this code even now.</div><div><br></div><div>There's a differ=
ence between what is taught and what is remembered.=C2=A0 When the rules ar=
e complex and indeterminate, people will forget what they are. =C2=A0(Overl=
oading rules, anyone?) =C2=A0Further, the physical form of code exerts a st=
rong influence on what its readers believe it does.=C2=A0 Seeing <font face=
=3D"monospace, monospace">f</font> declared as taking a pair of smart point=
ers and being called as above tells the reader with definiteness that memor=
y is being handled correctly, whether or not the language is really defined=
that way.<br><br>When you must teach someone that in <font face=3D"monospa=
ce, monospace">a() << b()</font>, <font face=3D"monospace, monospace"=
>a()</font> is called before <font face=3D"monospace, monospace">b()</font>=
, in <font face=3D"monospace, monospace">a() <<=3D b()</font>, <font =
face=3D"monospace, monospace">b()</font> is called before <font face=3D"mon=
ospace, monospace">a()</font>, and in <font face=3D"monospace, monospace">a=
() + b()</font>, <font face=3D"monospace, monospace">a()</font> and <font f=
ace=3D"monospace, monospace">b()</font> can be called in either order, you =
are imposing a cognitive load of meaningless difference, and that will make=
the student quickly forget the rules.=C2=A0 When you teach someone that in=
an expression, subexpressions are evaluated left-to-right, you impart a si=
mple and universal rule that no one will forget.</div></div></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/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iM=
rJ8FwQax%2BLwusNtw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZCGY9V=
bBDxPrH_cCb%2Bokcc5nq5iMrJ8FwQax%2BLwusNtw%40mail.gmail.com</a>.<br />
--001a1135729e6fe869053787865c--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 13 Jul 2016 10:26:38 -0700
Raw View
--001a1144130c5635bb053787b12f
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 8:19 PM, Greg Marr <gregmmarr@gmail.com> wrote:
> On Tuesday, July 12, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:
>>
>> There were debates in Oulu, and there were people for and against what
>> you care so much about.
>>
>
> We don't have access to the discussions, so we only know what is reported
> here.
> Was there discussion about whether assignment should be RTL vs LTR, or
> only about whether or not to provide an order for function arguments?
> If there were reasons brought up to have it be RTL instead of LTR, then
> any paper suggesting to change that would need to address those reasons.
>
The sequencing of assignment was mentioned in Oulu, Kona, and Urbana, with
<< vs <<= being an example. I think BSI and some other folks will be
sympathetic to a paper trying to change that, although I don't know which
side they'll actually come down on. I don't see any arguments that
assignment should be RTL in the notes except maybe something in Kona about
developers tending to refactor the RHS. Microsoft may have some evidence
one way or the other that didn't come out in discussion. Maybe they put it
in one of the series of papers? Start at P0145 in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/, and go back
through the papers it revises.
Please write a dedicated paper about changing the assignment sequencing,
rather than mixing it with adding more ordering to other operations. Also
write a paper about adding more ordering, but strategically, you should
probably wait a meeting for that one, so you don't confuse us about the
actually-time-sensitive paper.
Thanks,
Jeffrey
--
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/CANh-dX%3D6%2Bw7C-f00jVceQ2se2fvuY1tQbeO5wfQR8hS6AGwaGA%40mail.gmail.com.
--001a1144130c5635bb053787b12f
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=
ue, Jul 12, 2016 at 8:19 PM, Greg Marr <span dir=3D"ltr"><<a href=3D"mai=
lto:gregmmarr@gmail.com" target=3D"_blank" class=3D"gmail-cremed cremed">gr=
egmmarr@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On Tuesday, July =
12, 2016 at 11:05:52 PM UTC-4, Patrice Roy wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div>There were debates in Oulu, a=
nd there were people for and against what you care so much about. </div></d=
iv></blockquote><div><br></div></span><div>We don't have access to the =
discussions, so we only know what is reported here.<br></div><div>Was there=
discussion about whether assignment should be RTL vs LTR, or only about wh=
ether or not to provide an order for function arguments?</div><div>If there=
were reasons brought up to have it be RTL instead of LTR, then any paper s=
uggesting to change that would need to address those reasons.</div></div></=
blockquote><div><br></div><div>The sequencing of assignment was mentioned i=
n Oulu, Kona, and Urbana, with << vs <<=3D being an example. I =
think BSI and some other folks will be sympathetic to a paper trying to cha=
nge that, although I don't know which side they'll actually come do=
wn on. I don't see any arguments that assignment should be RTL in the n=
otes except maybe something in Kona about developers tending to refactor th=
e RHS. Microsoft may have some evidence one way or the other that didn'=
t come out in discussion. Maybe they put it in one of the series of papers?=
Start at P0145 in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2016/">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/</a>, =
and go back through the papers it revises.</div><div><br></div><div>Please =
write a dedicated paper about changing the assignment sequencing, rather th=
an mixing it with adding more ordering to other operations. Also write a pa=
per about adding more ordering, but strategically, you should probably wait=
a meeting for that one, so you don't confuse us about the actually-tim=
e-sensitive paper.</div><div><br></div><div>Thanks,</div><div>Jeffrey</div>=
</div></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/CANh-dX%3D6%2Bw7C-f00jVceQ2se2fvuY1tQ=
beO5wfQR8hS6AGwaGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3D6%2=
Bw7C-f00jVceQ2se2fvuY1tQbeO5wfQR8hS6AGwaGA%40mail.gmail.com</a>.<br />
--001a1144130c5635bb053787b12f--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Wed, 13 Jul 2016 13:38:09 -0400
Raw View
--001a114ba1ce7117c2053787d946
Content-Type: text/plain; charset=UTF-8
From the paper, a precedes b in the following cases:
1. a.b
2. a->b
3. a->*b
4. a(b1, b2, b3) // the one that did not reach consensus: the paper
proposed imposing b1, then b2, then b3; what got consensus is that
evaluation order of b1,b2,b3 is unspecified but the evaluations do not
interleave
5. b @=a // +=, -=, *=, etc.
6. a[b]
7. a << b
8. a >> b
That's what the authors proposed, and that's what was under discussion. I
gather you would have preferred to swap a and b in 5., which to me would be
surprising (I don't see a << b and a <<= b as leading to the same behavior
pattern and I find the difference in expression ordering to match intuition
in this case, but we can disagree on this, it's fair). The fact that a() +
b() should be ordered for you is something I understand, although I remain
happy that we avoided this; note that it was not even proposed, thus it was
not discussed, so maybe you can make a push for this and try to convince a
sufficient number of individuals for C++20.
As stated before, the best way to make yourself heard at this point for 4.
and 5. is probably a NB comment (for modifications in th very near future)
or a proposal (for modifications later, although that might be more
difficult), with convincing examples and use cases.
2016-07-13 13:14 GMT-04:00 Hyman Rosen <hyman.rosen@gmail.com>:
> On Wed, Jul 13, 2016 at 11:51 AM, Patrice Roy <patricer@gmail.com> wrote:
>>
>> That being said, instructor and teachers have a responsibility here, and
>> the current rules can be taught (they have been for a while), just as new
>> ones could. I think we should go for more objective arguments should this
>> discussion continue. And I really would prefer to discuss over an actual
>> proposal (it helps organize and focus discussions).
>>
>
> The f(new T, new T) problem didn't emerge into popular notice until 2009,
> when Sutter presented it as GotW #56. (I recall being incredulous during
> the Usenet discussion that C++ actually operated this way.) We've seen
> several other cases on this list where even C++ experts are mistaken about
> order of evaluation. I doubt that a meaningful number of C++ programmers
> would recognize the problem with this code even now.
>
> There's a difference between what is taught and what is remembered. When
> the rules are complex and indeterminate, people will forget what they are.
> (Overloading rules, anyone?) Further, the physical form of code exerts a
> strong influence on what its readers believe it does. Seeing f declared
> as taking a pair of smart pointers and being called as above tells the
> reader with definiteness that memory is being handled correctly, whether or
> not the language is really defined that way.
>
> When you must teach someone that in a() << b(), a() is called before b(),
> in a() <<= b(), b() is called before a(), and in a() + b(), a() and b()
> can be called in either order, you are imposing a cognitive load of
> meaningless difference, and that will make the student quickly forget the
> rules. When you teach someone that in an expression, subexpressions are
> evaluated left-to-right, you impart a simple and universal rule that no one
> will forget.
>
> --
> 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/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iMrJ8FwQax%2BLwusNtw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iMrJ8FwQax%2BLwusNtw%40mail.gmail.com?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/CAKiZDp0y%3DbjBCUUdom-%2BFwjLYpwuZ9KuP8G%3Dd8%3DeWh08Qp-shg%40mail.gmail.com.
--001a114ba1ce7117c2053787d946
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>From the paper, a precedes b in the following cases:<=
br><br><ol><li>a.b</li><li>a->b</li><li>a->*b</li><li>a(b1, b2, b3) /=
/ the one that did not reach consensus: the paper proposed imposing b1, the=
n b2, then b3; what got consensus is that evaluation order of b1,b2,b3 is u=
nspecified but the evaluations do not interleave</li><li>b @=3Da // +=3D, -=
=3D, *=3D, etc.</li><li>a[b]</li><li>a << b</li><li>a >> b</li>=
</ol>That's what the authors proposed, and that's what was under di=
scussion. I gather you would have preferred to swap a and b in 5., which to=
me would be surprising (I don't see a << b and a <<=3D b a=
s leading to the same behavior pattern and I find the difference in express=
ion ordering to match intuition in this case, but we can disagree on this, =
it's fair). The fact that a() + b() should be ordered for you is someth=
ing I understand, although I remain happy that we avoided this; note that i=
t was not even proposed, thus it was not discussed, so maybe you can make a=
push for this and try to convince a sufficient number of individuals for C=
++20.<br><br>As stated before, the best way to make yourself heard at this =
point for 4. and 5. is probably a NB comment (for modifications in th very =
near future) or a proposal (for modifications later, although that might be=
more difficult), with convincing examples and use cases.<br><br><br><br></=
div><br><div><div><div><br><br></div></div></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">2016-07-13 13:14 GMT-04:00 Hyman Rose=
n <span dir=3D"ltr"><<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"=
_blank">hyman.rosen@gmail.com</a>></span>:<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"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><span class=3D"">On Wed, Jul 13, 2016 at 11:51 AM, Patrice Roy <span dir=
=3D"ltr"><<a href=3D"mailto:patricer@gmail.com" target=3D"_blank">patric=
er@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>That being said, instructor and teachers have a responsibilit=
y here, and the current rules can be taught (they have been for a while), j=
ust as new ones could. I think we should go for more objective arguments sh=
ould this discussion continue. And I really would prefer to discuss over an=
actual proposal (it helps organize and focus discussions).</div></div></bl=
ockquote></span><div><br>The <font face=3D"monospace, monospace">f(new T, n=
ew T)</font> problem didn't emerge into popular notice until 2009, when=
Sutter presented it as GotW #56. =C2=A0(I recall being incredulous during =
the Usenet discussion that C++ actually operated this way.) =C2=A0We've=
seen several other cases on this list where even C++ experts are mistaken =
about order of evaluation.=C2=A0 I doubt that a meaningful number of C++ pr=
ogrammers would recognize the problem with this code even now.</div><div><b=
r></div><div>There's a difference between what is taught and what is re=
membered.=C2=A0 When the rules are complex and indeterminate, people will f=
orget what they are. =C2=A0(Overloading rules, anyone?) =C2=A0Further, the =
physical form of code exerts a strong influence on what its readers believe=
it does.=C2=A0 Seeing <font face=3D"monospace, monospace">f</font> declare=
d as taking a pair of smart pointers and being called as above tells the re=
ader with definiteness that memory is being handled correctly, whether or n=
ot the language is really defined that way.<br><br>When you must teach some=
one that in <font face=3D"monospace, monospace">a() << b()</font>, <f=
ont face=3D"monospace, monospace">a()</font> is called before <font face=3D=
"monospace, monospace">b()</font>, in <font face=3D"monospace, monospace">a=
() <<=3D b()</font>, <font face=3D"monospace, monospace">b()</font> i=
s called before <font face=3D"monospace, monospace">a()</font>, and in <fon=
t face=3D"monospace, monospace">a() + b()</font>, <font face=3D"monospace, =
monospace">a()</font> and <font face=3D"monospace, monospace">b()</font> ca=
n be called in either order, you are imposing a cognitive load of meaningle=
ss difference, and that will make the student quickly forget the rules.=C2=
=A0 When you teach someone that in an expression, subexpressions are evalua=
ted left-to-right, you impart a simple and universal rule that no one will =
forget.</div></div></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" 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@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/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iM=
rJ8FwQax%2BLwusNtw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iMrJ8FwQax%2BLwusNtw%40mail.gma=
il.com</a>.<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" 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/CAKiZDp0y%3DbjBCUUdom-%2BFwjLYpwuZ9Ku=
P8G%3Dd8%3DeWh08Qp-shg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0y=
%3DbjBCUUdom-%2BFwjLYpwuZ9KuP8G%3Dd8%3DeWh08Qp-shg%40mail.gmail.com</a>.<br=
/>
--001a114ba1ce7117c2053787d946--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 13 Jul 2016 20:42:43 +0300
Raw View
On 13 July 2016 at 20:26, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> The sequencing of assignment was mentioned in Oulu, Kona, and Urbana, with
> << vs <<= being an example. I think BSI and some other folks will be
> sympathetic to a paper trying to change that, although I don't know which
> side they'll actually come down on. I don't see any arguments that
> assignment should be RTL in the notes except maybe something in Kona about
> developers tending to refactor the RHS. Microsoft may have some evidence one
There was a discussion about that on the reflector.
Quoth 1:
"More specifically, consider
map<int, size_t> m;
m[0] = m.size();
"
Quoth 2:
"We've seen quite a few cases of this:
std::unique_ptr<T> p;
std::map<T*, U> m;
m[p.release()] = f(p.get());
"
--
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/CAFk2RUbEeDHAtrYCPUUS%2BJ%2BM%2B5Mt9UrqzmvNYK%2BcDPbfKTZasQ%40mail.gmail.com.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 13 Jul 2016 13:58:27 -0400
Raw View
--001a114fda9c1b5824053788234d
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 11:36 AM, Ren Industries <renindustries@gmail.com>
wrote:
> Why would the simplicity of teaching anything matter more than anything
> else? IEEE 754 is incredibly hard to teach, with many odd nuances to it,
> yet it is used because those nuances lead to better results. Modeling after
> the mathematical concepts underlying the operations may lead to more
> difficult to teach, but also has clear benefits, as DV explained.
>
The nuances of C++ order of evaluation lead to worse results and dubious
benefits.
And of course, C++'s implementation of IEEE 754 is broken too, so maybe
your analogy is more apt than you realize,
(Broken how? For example, C++ does not require that the following program
succeed:
#include <assert.h>
int main() { volatile float i = 1.f; assert(i / 3.f == 1.f / 3.f); }
On my x86 Linux box, it fails when built with -mno-sse but works when SSE
instructions are used.)
--
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/CAHSYqdbhW%2BR_npeuYtEzAfAM69bY7%2BTofxv_SePDV9svNf74bA%40mail.gmail.com.
--001a114fda9c1b5824053788234d
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 W=
ed, Jul 13, 2016 at 11:36 AM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Why would the=
simplicity of teaching anything matter more than anything else? IEEE 754 i=
s incredibly hard to teach, with many odd nuances to it, yet it is used bec=
ause those nuances lead to better results. Modeling after the mathematical =
concepts underlying the operations may lead to more difficult to teach, but=
also has clear benefits, as DV explained.</div></blockquote><div><br>The n=
uances of C++ order of evaluation lead to worse results and dubious benefit=
s.<br><br>And of course, C++'s implementation of IEEE 754 is broken too=
, so maybe your analogy is more apt than you realize,<br>(Broken how?=C2=A0=
For example, C++ does not require that the following program succeed:<br><=
font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=A0#include <assert.h=
></font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=
=A0int main() { volatile float i =3D 1.f; assert(i / 3.f =3D=3D 1.f / 3.f);=
}</font><br><font face=3D"arial, helvetica, sans-serif">On my x86 Linux bo=
x, it fails when built with -mno-sse but works when SSE instructions are us=
ed.)</font></div></div></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/CAHSYqdbhW%2BR_npeuYtEzAfAM69bY7%2BTo=
fxv_SePDV9svNf74bA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbhW%2B=
R_npeuYtEzAfAM69bY7%2BTofxv_SePDV9svNf74bA%40mail.gmail.com</a>.<br />
--001a114fda9c1b5824053788234d--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 13 Jul 2016 21:03:24 +0100
Raw View
--001a11404e8eed9c2e053789e000
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 12, 2016 at 11:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, July 12, 2016 at 12:29:04 PM UTC-4, Edward Catmur wrote:
>>
>> On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>>
>>> So what? Are we supposed to restrict C++ to "experienced users" as you
>>> define it?
>>>
>>
>> It would be better to restrict C++ to experienced users than to make it
>> useless to them.
>>
>
> Hyperbole is not helpful in proving your point. The largest variance
> measured for this feature was 4%. A 4% performance drop is not going to
> make C++ "useless".
>
Huge efforts are put in to get performance increases of far less than 4%.
C++ might still be usable at 4% slower, but if it loses enough performance
to fall behind its competitors that would be a tragedy. Impressions matter
as well as raw numbers; who in a performance-sensitive situation would want
to use a language that leaves 4% on the table in favor of being easier to
teach and making it easier to write code that no-one should be writing
anyway?
--
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/CAJnLdOZ978akc7Sxqu4kEQt0uLp_UeLv3m2gRo-AUBv9Bdd5dw%40mail.gmail.com.
--001a11404e8eed9c2e053789e000
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=
ue, Jul 12, 2016 at 11:00 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, July 12, 2016=
at 12:29:04 PM UTC-4, Edward Catmur wrote:<span><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 6:12 AM, N=
icol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br></div></blockquo=
te></div></div></div></blockquote></span><span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>So what? Are we supposed to restrict C++ to "experienced users"=
as you define it?<br></div></div></blockquote><div><br></div><div>It would=
be better to restrict C++ to experienced users than to make it useless to =
them.</div></div></div></div></blockquote></span><div><br>Hyperbole is not =
helpful in proving your point. The largest variance measured for this featu=
re was 4%. A 4% performance drop is not going to make C++ "useless&quo=
t;.</div></div></blockquote><div><br></div><div>Huge efforts are put in to =
get performance increases of far less than 4%. C++ might still be usable at=
4% slower, but if it loses enough performance to fall behind its competito=
rs that would be a tragedy. Impressions matter as well as raw numbers; who=
=C2=A0in a performance-sensitive situation would want to use a language tha=
t leaves 4% on the table in favor of being easier to teach and making it ea=
sier to write code that no-one should be writing anyway?</div></div><br></d=
iv></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/CAJnLdOZ978akc7Sxqu4kEQt0uLp_UeLv3m2g=
Ro-AUBv9Bdd5dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ978akc7Sx=
qu4kEQt0uLp_UeLv3m2gRo-AUBv9Bdd5dw%40mail.gmail.com</a>.<br />
--001a11404e8eed9c2e053789e000--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 13 Jul 2016 21:12:19 +0100
Raw View
--001a114038d2ba349e05378a0052
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 6:14 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> When you must teach someone that in a() << b(), a() is called before b(),
> in a() <<= b(), b() is called before a(), and in a() + b(), a() and b()
> can be called in either order, you are imposing a cognitive load of
> meaningless difference, and that will make the student quickly forget the
> rules. When you teach someone that in an expression, subexpressions are
> evaluated left-to-right, you impart a simple and universal rule that no one
> will forget.
>
What was it H. L. Mencken said? "There is always a well-known solution to
every human problem - neat, plausible, and wrong."
--
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/CAJnLdOZuuyShqgiATVb_OatN%2BqxPHjJPa6y4tdW%2BtABhoku%3DCw%40mail.gmail.com.
--001a114038d2ba349e05378a0052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 13, 2016 at 6:14 PM, Hyman Rosen <span dir=3D"ltr"><<a href=
=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</=
a>></span> wrote:<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"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><div>When you must teach=
someone that in <font face=3D"monospace, monospace">a() << b()</font=
>, <font face=3D"monospace, monospace">a()</font> is called before <font fa=
ce=3D"monospace, monospace">b()</font>, in <font face=3D"monospace, monospa=
ce">a() <<=3D b()</font>, <font face=3D"monospace, monospace">b()</fo=
nt> is called before <font face=3D"monospace, monospace">a()</font>, and in=
<font face=3D"monospace, monospace">a() + b()</font>, <font face=3D"monosp=
ace, monospace">a()</font> and <font face=3D"monospace, monospace">b()</fon=
t> can be called in either order, you are imposing a cognitive load of mean=
ingless difference, and that will make the student quickly forget the rules=
..=C2=A0 When you teach someone that in an expression, subexpressions are ev=
aluated left-to-right, you impart a simple and universal rule that no one w=
ill forget.</div></div></div></div></blockquote><div><br></div><div>What wa=
s it H. L. Mencken said? "There is always a well-known solution to eve=
ry human problem - neat, plausible, and wrong."</div></div></div><div =
class=3D"gmail_extra"><br></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/CAJnLdOZuuyShqgiATVb_OatN%2BqxPHjJPa6=
y4tdW%2BtABhoku%3DCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZuuy=
ShqgiATVb_OatN%2BqxPHjJPa6y4tdW%2BtABhoku%3DCw%40mail.gmail.com</a>.<br />
--001a114038d2ba349e05378a0052--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 13 Jul 2016 22:31:21 +0100
Raw View
--94eb2c124a325f089905378b1bec
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 9:03 PM, Edward Catmur <ecatmur@googlemail.com>
wrote:
> On Tue, Jul 12, 2016 at 11:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Tuesday, July 12, 2016 at 12:29:04 PM UTC-4, Edward Catmur wrote:
>>>
>>> On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>>
>>>> So what? Are we supposed to restrict C++ to "experienced users" as you
>>>> define it?
>>>>
>>>
>>> It would be better to restrict C++ to experienced users than to make it
>>> useless to them.
>>>
>>
>> Hyperbole is not helpful in proving your point. The largest variance
>> measured for this feature was 4%. A 4% performance drop is not going to
>> make C++ "useless".
>>
>
> Huge efforts are put in to get performance increases of far less than 4%.
> C++ might still be usable at 4% slower, but if it loses enough performance
> to fall behind its competitors that would be a tragedy. Impressions matter
> as well as raw numbers; who in a performance-sensitive situation would want
> to use a language that leaves 4% on the table in favor of being easier to
> teach and making it easier to write code that no-one should be writing
> anyway?
>
I've just seen Jason Merrill's report on Oulu[1]. They found 2% penalty for
LTR over RTL on one of the SPEC2006 tests. Again, I consider that more than
sufficient reason to keep order of function arguments unspecified.
1.
http://developerblog.redhat.com/2016/07/13/red-hat-iso-c-standards-meeting-june-2016-core-language/
--
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/CAJnLdObKN0gqV%2BjVxvYLiVKnrVnVQ39h7%2B6O5YAH1KMJAC-j-A%40mail.gmail.com.
--94eb2c124a325f089905378b1bec
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 W=
ed, Jul 13, 2016 at 9:03 PM, Edward Catmur <span dir=3D"ltr"><<a href=3D=
"mailto:ecatmur@googlemail.com" target=3D"_blank">ecatmur@googlemail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue, Jul 12, 2016 a=
t 11:00 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@g=
mail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br></=
span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday, July 12=
, 2016 at 12:29:04 PM UTC-4, Edward Catmur wrote:<span><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at 6:12 =
AM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br></div></blo=
ckquote></div></div></div></blockquote></span></span><span class=3D""><span=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>So what? Are we supposed to restrict C++ to =
"experienced users" as you define it?<br></div></div></blockquote=
><div><br></div><div>It would be better to restrict C++ to experienced user=
s than to make it useless to them.</div></div></div></div></blockquote></sp=
an><div><br>Hyperbole is not helpful in proving your point. The largest var=
iance measured for this feature was 4%. A 4% performance drop is not going =
to make C++ "useless".</div></span></div></blockquote><div><br></=
div><div>Huge efforts are put in to get performance increases of far less t=
han 4%. C++ might still be usable at 4% slower, but if it loses enough perf=
ormance to fall behind its competitors that would be a tragedy. Impressions=
matter as well as raw numbers; who=C2=A0in a performance-sensitive situati=
on would want to use a language that leaves 4% on the table in favor of bei=
ng easier to teach and making it easier to write code that no-one should be=
writing anyway?</div></div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">I've just seen =
Jason Merrill's report on Oulu[1]. They found 2% penalty for LTR over R=
TL on one of the SPEC2006 tests. Again, I consider that more than sufficien=
t reason to keep order of function arguments unspecified.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1.=C2=A0<a href=3D"ht=
tp://developerblog.redhat.com/2016/07/13/red-hat-iso-c-standards-meeting-ju=
ne-2016-core-language/">http://developerblog.redhat.com/2016/07/13/red-hat-=
iso-c-standards-meeting-june-2016-core-language/</a></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/CAJnLdObKN0gqV%2BjVxvYLiVKnrVnVQ39h7%=
2B6O5YAH1KMJAC-j-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObKN0gq=
V%2BjVxvYLiVKnrVnVQ39h7%2B6O5YAH1KMJAC-j-A%40mail.gmail.com</a>.<br />
--94eb2c124a325f089905378b1bec--
.
Author: ezmagician@gmail.com
Date: Wed, 13 Jul 2016 14:39:56 -0700 (PDT)
Raw View
------=_Part_10_682879485.1468445996677
Content-Type: multipart/alternative;
boundary="----=_Part_11_78153006.1468445996678"
------=_Part_11_78153006.1468445996678
Content-Type: text/plain; charset=UTF-8
>
> They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
That's interesting. But then why not make the arguments evalued right to
left then?
Is it because everything else is left to right and having this particular
case be right-to-left may cause confusion?
On Wednesday, July 13, 2016 at 5:31:24 PM UTC-4, Edward Catmur wrote:
>
> On Wed, Jul 13, 2016 at 9:03 PM, Edward Catmur <eca...@googlemail.com
> <javascript:>> wrote:
>
>> On Tue, Jul 12, 2016 at 11:00 PM, Nicol Bolas <jmck...@gmail.com
>> <javascript:>> wrote:
>>
>>> On Tuesday, July 12, 2016 at 12:29:04 PM UTC-4, Edward Catmur wrote:
>>>>
>>>> On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>>
>>>>>
>>>>> So what? Are we supposed to restrict C++ to "experienced users" as you
>>>>> define it?
>>>>>
>>>>
>>>> It would be better to restrict C++ to experienced users than to make it
>>>> useless to them.
>>>>
>>>
>>> Hyperbole is not helpful in proving your point. The largest variance
>>> measured for this feature was 4%. A 4% performance drop is not going to
>>> make C++ "useless".
>>>
>>
>> Huge efforts are put in to get performance increases of far less than 4%.
>> C++ might still be usable at 4% slower, but if it loses enough performance
>> to fall behind its competitors that would be a tragedy. Impressions matter
>> as well as raw numbers; who in a performance-sensitive situation would want
>> to use a language that leaves 4% on the table in favor of being easier to
>> teach and making it easier to write code that no-one should be writing
>> anyway?
>>
>
> I've just seen Jason Merrill's report on Oulu[1]. They found 2% penalty
> for LTR over RTL on one of the SPEC2006 tests. Again, I consider that more
> than sufficient reason to keep order of function arguments unspecified.
>
> 1.
> http://developerblog.redhat.com/2016/07/13/red-hat-iso-c-standards-meeting-june-2016-core-language/
>
--
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/85658a7a-d8dc-4440-a87c-a6d746287417%40isocpp.org.
------=_Part_11_78153006.1468445996678
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-c=
olor: rgb(204, 204, 204); padding-left: 1ex;">They found 2% penalty for LTR=
over RTL on one of the SPEC2006 tests.</blockquote><div><br></div>That'=
;s interesting. But then why not make the arguments evalued right to left t=
hen?<div>Is it because everything else is left to right and having this par=
ticular case be right-to-left may cause confusion?<br><br>On Wednesday, Jul=
y 13, 2016 at 5:31:24 PM UTC-4, Edward Catmur wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On W=
ed, Jul 13, 2016 at 9:03 PM, Edward Catmur <span dir=3D"ltr"><<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1Yt9pVIRCwAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">eca...@googlem=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><span>On Tue, Jul 12, 2016 at 11:00 PM, Nicol Bolas=
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"1Yt9pVIRCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">jmck...@gmail.com</a>></span> wrote:<br></span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div dir=3D"ltr"><span>On Tuesday, July 12, 2016 at 12:29:04 PM U=
TC-4, Edward Catmur wrote:<span><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
class=3D"gmail_quote">On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <span d=
ir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><br></div></blockquote></div></div></d=
iv></blockquote></span></span><span><span><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>So =
what? Are we supposed to restrict C++ to "experienced users" as y=
ou define it?<br></div></div></blockquote><div><br></div><div>It would be b=
etter to restrict C++ to experienced users than to make it useless to them.=
</div></div></div></div></blockquote></span><div><br>Hyperbole is not helpf=
ul in proving your point. The largest variance measured for this feature wa=
s 4%. A 4% performance drop is not going to make C++ "useless".</=
div></span></div></blockquote><div><br></div><div>Huge efforts are put in t=
o get performance increases of far less than 4%. C++ might still be usable =
at 4% slower, but if it loses enough performance to fall behind its competi=
tors that would be a tragedy. Impressions matter as well as raw numbers; wh=
o=C2=A0in a performance-sensitive situation would want to use a language th=
at leaves 4% on the table in favor of being easier to teach and making it e=
asier to write code that no-one should be writing anyway?</div></div></div>=
</div>
</blockquote></div><br></div><div>I've just seen Jason Merrill's re=
port on Oulu[1]. They found 2% penalty for LTR over RTL on one of the SPEC2=
006 tests. Again, I consider that more than sufficient reason to keep order=
of function arguments unspecified.</div><div><br></div><div>1.=C2=A0<a hre=
f=3D"http://developerblog.redhat.com/2016/07/13/red-hat-iso-c-standards-mee=
ting-june-2016-core-language/" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fdevelope=
rblog.redhat.com%2F2016%2F07%2F13%2Fred-hat-iso-c-standards-meeting-june-20=
16-core-language%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGBnLf6piD8UB_mt=
4e3nNoWm4puTA';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fdeveloperblog.redhat.com%2F2016%2F07%2F13%2Fr=
ed-hat-iso-c-standards-meeting-june-2016-core-language%2F\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNGBnLf6piD8UB_mt4e3nNoWm4puTA';return true;">http=
://developerblog.<wbr>redhat.com/2016/07/13/red-hat-<wbr>iso-c-standards-me=
eting-june-<wbr>2016-core-language/</a></div></div>
</blockquote></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/85658a7a-d8dc-4440-a87c-a6d746287417%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/85658a7a-d8dc-4440-a87c-a6d746287417=
%40isocpp.org</a>.<br />
------=_Part_11_78153006.1468445996678--
------=_Part_10_682879485.1468445996677--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 13 Jul 2016 14:48:42 -0700 (PDT)
Raw View
------=_Part_25_1901501925.1468446522654
Content-Type: multipart/alternative;
boundary="----=_Part_26_1292801432.1468446522654"
------=_Part_26_1292801432.1468446522654
Content-Type: text/plain; charset=UTF-8
On Wednesday, July 13, 2016 at 5:39:57 PM UTC-4, ezmag...@gmail.com wrote:
>
> They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
>
>
> That's interesting. But then why not make the arguments evalued right to
> left then?
> Is it because everything else is left to right and having this particular
> case be right-to-left may cause confusion?
>
This depends on the psABI. Some work better with LTR, some RTL.
>
--
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/1aab8e27-d016-4da0-8eb4-6f2531df790d%40isocpp.org.
------=_Part_26_1292801432.1468446522654
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, July 13, 2016 at 5:39:57 PM UTC-4, ezmag...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex">They found 2% penalty for LTR over RTL on one of the SP=
EC2006 tests.</blockquote><div><br></div>That's interesting. But then w=
hy not make the arguments evalued right to left then?<div>Is it because eve=
rything else is left to right and having this particular case be right-to-l=
eft may cause confusion?<br></div></div></blockquote><div><br></div><div><b=
r></div><div>This depends on the psABI. Some work better with LTR, some RTL=
..</div><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><=
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>
</blockquote></div></div></blockquote></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/1aab8e27-d016-4da0-8eb4-6f2531df790d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1aab8e27-d016-4da0-8eb4-6f2531df790d=
%40isocpp.org</a>.<br />
------=_Part_26_1292801432.1468446522654--
------=_Part_25_1901501925.1468446522654--
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 13 Jul 2016 22:50:21 +0100
Raw View
--089e0122ea5e5d59dc05378b5fd5
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 10:39 PM, <ezmagician@gmail.com> wrote:
> They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
>
>
> That's interesting. But then why not make the arguments evalued right to
> left then?
> Is it because everything else is left to right and having this particular
> case be right-to-left may cause confusion?
>
but "everything else" is *not* evaluated LTR. this thread is basically all
about some people's dislike of the newly specd RTL evaluation of assignment
chains.
--
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/CACGiwhEcJFuQNvK1WjJeL54sfk%2BbMzKZTOEZ%3D8ghERS%2B-0KA4Q%40mail.gmail.com.
--089e0122ea5e5d59dc05378b5fd5
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 W=
ed, Jul 13, 2016 at 10:39 PM, <span dir=3D"ltr"><<a href=3D"mailto:ezma=
gician@gmail.com" target=3D"_blank">ezmagician@gmail.com</a>></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"><span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex">They found 2% penalty for LTR over RTL on one of the SPEC2006=
tests.</blockquote><div><br></div></span>That's interesting. But then =
why not make the arguments evalued right to left then?<div>Is it because ev=
erything else is left to right and having this particular case be right-to-=
left may cause confusion?<br></div></div></blockquote><div><br></div><div>b=
ut "everything else" is <i>not</i> evaluated LTR. this thread is =
basically all about some people's dislike of the newly specd RTL evalua=
tion of assignment chains.<br>=C2=A0<br></div></div></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/CACGiwhEcJFuQNvK1WjJeL54sfk%2BbMzKZTO=
EZ%3D8ghERS%2B-0KA4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEcJF=
uQNvK1WjJeL54sfk%2BbMzKZTOEZ%3D8ghERS%2B-0KA4Q%40mail.gmail.com</a>.<br />
--089e0122ea5e5d59dc05378b5fd5--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 13 Jul 2016 14:53:36 -0700
Raw View
Em quarta-feira, 13 de julho de 2016, =C3=A0s 11:14:41 PDT, Hyman Rosen esc=
reveu:
> But why? Associativity (and precedence) tell you how to fully parenthesi=
ze
> an expression.
Because it's the "happens before" order. When you write:
a() =3D b() =3D c() =3D d();
The c() =3D d() assignment happens first. So regardless of the order in whi=
ch c()=20
and d() are called, I'd expect that the pair gets called before b().
This is especially important if one of them throws. If the call to c() or d=
()=20
or the assignment throws, then the rest of the expression is abandoned. Sho=
uld=20
a() and b() have been called? I'd argue that, due to the associativity rule=
s,=20
they shouldn't have.
Think also of how many temporaries need to be kept in memory (let's think=
=20
trivial types, for a moment). If they're evaluated right to left, then ther=
e's=20
always one single temporary:
T &&tmp =3D d(),
tmp =3D (c() =3D tmp),
tmp =3D (b() =3D tmp),
a() =3D tmp;
Whereas a left-to-right order would imply keeping more temporaries:
T &&tmp_a =3D a(),
T &&tmp_b =3D b(),
T &&tmp_c =3D c(),
tmp_c =3D d(),
tmp_b =3D tmp_c,
tmp_a =3D tmp_b;
This directly leads to code optimisation: how many temporaries need to be k=
ept=20
in the stack during the expression?
Finally, as a consequence of b() being called after (c(), d()) pair, it=20
follows that d() should be called before c().
--=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/2535714.jxXiWuONkt%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 13 Jul 2016 14:58:10 -0700
Raw View
Em quarta-feira, 13 de julho de 2016, =C3=A0s 14:39:56 PDT, ezmagician@gmai=
l.com=20
escreveu:
> > They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
>=20
> That's interesting. But then why not make the arguments evalued right to=
=20
> left then?
> Is it because everything else is left to right and having this particular=
=20
> case be right-to-left may cause confusion?
Benchmarks show variance of up to 4%. That means some cases would better of=
f=20
with LTR, some would be better off with RTL.
The conclusion is that specifying one would make some cases (half?) and som=
e=20
cases better. So instead of choosing "the lesser of two evils" (whichever t=
hat=20
may be), the committee opted not to choose and allow sufficiently smart=20
compilers to order however they see fit, so they could get the best of both=
=20
worlds.
--=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/4199473.359BDtvs3Q%40tjmaciei-mobl1.
.
Author: ezmagician@gmail.com
Date: Wed, 13 Jul 2016 15:05:35 -0700 (PDT)
Raw View
------=_Part_2_1507470123.1468447535406
Content-Type: multipart/alternative;
boundary="----=_Part_3_1991458963.1468447535407"
------=_Part_3_1991458963.1468447535407
Content-Type: text/plain; charset=UTF-8
>
> but "everything else" is not evaluated LTR.
Forgive me, that remark was said thoughtlessly.
I for one would like for there to be a specified order to things, if only
to lessen the number of "unspecified" or "implementation defined" areas of
C++.
It may be helpful for the compiler writers, but it gives the programmer
another "I cannot do this" to worry about.
However, if it is a situation where the lack of specification provides
significant optimization opportunities, I can understand the decision to
keep it unspecified.
It will be good to have measurements such as Jason Merrill's report
<https://developerblog.redhat.com/2016/07/13/red-hat-iso-c-standards-meeting-june-2016-core-language/> made
in more detail before either decision is made.
On Wednesday, July 13, 2016 at 5:50:25 PM UTC-4, D. B. wrote:
>
> On Wed, Jul 13, 2016 at 10:39 PM, <ezmag...@gmail.com <javascript:>>
> wrote:
>
>> They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
>>
>>
>> That's interesting. But then why not make the arguments evalued right to
>> left then?
>> Is it because everything else is left to right and having this particular
>> case be right-to-left may cause confusion?
>>
>
> but "everything else" is *not* evaluated LTR. this thread is basically
> all about some people's dislike of the newly specd RTL evaluation of
> assignment chains.
>
>
--
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/27ff5d7b-043a-4be6-ba54-77515c4f1c1c%40isocpp.org.
------=_Part_3_1991458963.1468447535407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"border-left-wid=
th: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); p=
adding-left: 1ex;"></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid=
; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">but "ever=
ything else" is not evaluated LTR.</blockquote><div><br></div><div>For=
give me, that remark was said thoughtlessly.<br></div><div><br></div><div>I=
for one would like for there to be a specified order to things, if only to=
lessen the number of "unspecified" or "implementation defin=
ed" areas of C++.</div><div>It may be helpful for the compiler writers=
, but it gives the programmer another "I cannot do this" to worry=
about.</div><div><br></div><div>However, if it is a situation where the la=
ck of specification provides significant optimization opportunities, I can =
understand the decision to keep it unspecified.</div><div>It will be good t=
o have measurements such as <a href=3D"https://developerblog.redhat.com/201=
6/07/13/red-hat-iso-c-standards-meeting-june-2016-core-language/">Jason Mer=
rill's report</a>=C2=A0made in more detail before either decision is ma=
de.</div><br>On Wednesday, July 13, 2016 at 5:50:25 PM UTC-4, D. B. wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote">On Wed, Jul 13, 2016 at 10:39 PM, <span dir=3D"ltr"><=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"eVR9SFwS=
CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">ezmag=
....@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex">They found 2% penalty for LTR over RTL o=
n one of the SPEC2006 tests.</blockquote><div><br></div></span>That's i=
nteresting. But then why not make the arguments evalued right to left then?=
<div>Is it because everything else is left to right and having this particu=
lar case be right-to-left may cause confusion?<br></div></div></blockquote>=
<div><br></div><div>but "everything else" is <i>not</i> evaluated=
LTR. this thread is basically all about some people's dislike of the n=
ewly specd RTL evaluation of assignment chains.<br>=C2=A0<br></div></div></=
div></div>
</blockquote></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/27ff5d7b-043a-4be6-ba54-77515c4f1c1c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27ff5d7b-043a-4be6-ba54-77515c4f1c1c=
%40isocpp.org</a>.<br />
------=_Part_3_1991458963.1468447535407--
------=_Part_2_1507470123.1468447535406--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 13 Jul 2016 18:26:05 -0400
Raw View
--001a114c843a33420a05378be03e
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 5:53 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Because it's the "happens before" order. When you write:
>
> a() = b() = c() = d();
>
> The c() = d() assignment happens first. So regardless of the order in
> which c()
> and d() are called, I'd expect that the pair gets called before b().
When you write
((a() = b()) = c()) = d()
the a() = b() assignment happens first. But the standard (now) still
requires the valuation order d(), c(), b(), a().
It doesn't seem to me that you've made your case.
As for temporaries, 64-bit x86 has some 16 64-bit registers and 8 128-bit
SSE registers, so there's plenty of room to hold them, and they don't need
to go onto the stack. But that's not even important; the amount of code
that consists of such multiple assignments is minuscule. The important
thing is to make the language clear and let the compilers do the worrying
about generating good translations.
There's this video Don't Help the Compiler
<https://www.youtube.com/watch?v=AKtHxKJRwp4> by Stephan T. Lavavej. It's
directed at programmers. How much more sad when the language designers are
making the same mistake.
--
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/CAHSYqdZOp4-2NBftjrQ730LHcotiaoqgOR1-1WJYi%2B9wRvAA%3Dw%40mail.gmail.com.
--001a114c843a33420a05378be03e
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 W=
ed, Jul 13, 2016 at 5:53 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex">Because it's the "happens before&=
quot; order. When you write:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a() =3D b() =3D c() =3D d();<br>
<br>
The c() =3D d() assignment happens first. So regardless of the order in whi=
ch c()<br>
and d() are called, I'd expect that the pair gets called before b().</b=
lockquote><div><br></div><div>When you write</div><div><br></div><div><font=
face=3D"monospace, monospace">=C2=A0 =C2=A0 ((a() =3D b()) =3D c()) =3D d(=
)</font></div><div><font face=3D"monospace, monospace"><br></font></div><di=
v><font face=3D"arial, helvetica, sans-serif">the </font><font face=3D"mono=
space, monospace">a() =3D b()</font><font face=3D"arial, helvetica, sans-se=
rif"> assignment happens first.=C2=A0 But the standard (now) still requires=
the valuation order </font><font face=3D"monospace, monospace">d()</font><=
font face=3D"arial, helvetica, sans-serif">, </font><font face=3D"monospace=
, monospace">c()</font><font face=3D"arial, helvetica, sans-serif">, </font=
><font face=3D"monospace, monospace">b()</font><font face=3D"arial, helveti=
ca, sans-serif">, </font><font face=3D"monospace, monospace">a()</font><fon=
t face=3D"arial, helvetica, sans-serif">.<br>It doesn't seem to me that=
you've made your case.<br><br>As for temporaries, 64-bit x86 has some =
16 64-bit registers and 8 128-bit SSE registers, so there's plenty of r=
oom to hold them, and they don't need to go onto the stack.=C2=A0 But t=
hat's not even important; the amount of code that consists of such mult=
iple assignments is minuscule.=C2=A0 The important thing is to make the lan=
guage clear and let the compilers do the worrying about generating good tra=
nslations.<br><br>There's this video=C2=A0<a href=3D"https://www.youtub=
e.com/watch?v=3DAKtHxKJRwp4">Don't Help the Compiler</a>=C2=A0by Stepha=
n T. Lavavej.=C2=A0 It's directed at programmers.=C2=A0 How much more s=
ad when the language designers are making the same mistake.</font></div></d=
iv></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/CAHSYqdZOp4-2NBftjrQ730LHcotiaoqgOR1-=
1WJYi%2B9wRvAA%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZOp4-2=
NBftjrQ730LHcotiaoqgOR1-1WJYi%2B9wRvAA%3Dw%40mail.gmail.com</a>.<br />
--001a114c843a33420a05378be03e--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Wed, 13 Jul 2016 18:39:45 -0400
Raw View
--001a114ba1cefb283705378c0f2f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The speed issue is significant for C++ and its user base, as we do attract
those for whom every little bit of speed and size counts. It's an argument
that held a lot of weight in the discussions; it's measurable.
With respect to =C2=ABI for one would like for there to be a specified orde=
r to
things=C2=BB, let's keep in mind that it really affects code only in situat=
ions
where the expressions have side-effects. Whether the consequences of
standardizing the practice of relying on such code would lead to a simpler
or a more complex programming and maintenance experience seems more
subjective, as this thread would attest.
2016-07-13 18:05 GMT-04:00 <ezmagician@gmail.com>:
> but "everything else" is not evaluated LTR.
>
>
> Forgive me, that remark was said thoughtlessly.
>
> I for one would like for there to be a specified order to things, if only
> to lessen the number of "unspecified" or "implementation defined" areas o=
f
> C++.
> It may be helpful for the compiler writers, but it gives the programmer
> another "I cannot do this" to worry about.
>
> However, if it is a situation where the lack of specification provides
> significant optimization opportunities, I can understand the decision to
> keep it unspecified.
> It will be good to have measurements such as Jason Merrill's report
> <https://developerblog.redhat.com/2016/07/13/red-hat-iso-c-standards-meet=
ing-june-2016-core-language/> made
> in more detail before either decision is made.
>
> On Wednesday, July 13, 2016 at 5:50:25 PM UTC-4, D. B. wrote:
>>
>> On Wed, Jul 13, 2016 at 10:39 PM, <ezmag...@gmail.com> wrote:
>>
>>> They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
>>>
>>>
>>> That's interesting. But then why not make the arguments evalued right t=
o
>>> left then?
>>> Is it because everything else is left to right and having this
>>> particular case be right-to-left may cause confusion?
>>>
>>
>> but "everything else" is *not* evaluated LTR. this thread is basically
>> all about some people's dislike of the newly specd RTL evaluation of
>> assignment chains.
>>
>>
> --
> 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/27ff5d7b-043=
a-4be6-ba54-77515c4f1c1c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27ff5d7b-04=
3a-4be6-ba54-77515c4f1c1c%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAKiZDp3oNYAw_jz37XM1NuV9L-yBJGdQK%2B7Z%2Bv2PN%3=
D7DaLdROQ%40mail.gmail.com.
--001a114ba1cefb283705378c0f2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The speed issue is significant for C++ and its user base, =
as we do attract those for whom every little bit of speed and size counts. =
It's an argument that held a lot of weight in the discussions; it's=
measurable.<br><br>With respect to =C2=ABI for one would like for there to=
be a specified order to things=C2=BB, let's keep in mind that it reall=
y affects code only in situations where the expressions have side-effects. =
Whether the consequences of standardizing the practice of relying on such c=
ode would lead to a simpler or a more complex programming and maintenance e=
xperience seems more subjective, as this thread would attest.<br><br></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-07-13 18:05 =
GMT-04:00 <span dir=3D"ltr"><<a href=3D"mailto:ezmagician@gmail.com" ta=
rget=3D"_blank">ezmagician@gmail.com</a>></span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote class=3D"gmail_=
quote" style=3D"border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">but &=
quot;everything else" is not evaluated LTR.</blockquote><div><br></div=
></span><div>Forgive me, that remark was said thoughtlessly.<br></div><div>=
<br></div><div>I for one would like for there to be a specified order to th=
ings, if only to lessen the number of "unspecified" or "impl=
ementation defined" areas of C++.</div><div>It may be helpful for the =
compiler writers, but it gives the programmer another "I cannot do thi=
s" to worry about.</div><div><br></div><div>However, if it is a situat=
ion where the lack of specification provides significant optimization oppor=
tunities, I can understand the decision to keep it unspecified.</div><div>I=
t will be good to have measurements such as <a href=3D"https://developerblo=
g.redhat.com/2016/07/13/red-hat-iso-c-standards-meeting-june-2016-core-lang=
uage/" target=3D"_blank">Jason Merrill's report</a>=C2=A0made in more d=
etail before either decision is made.</div><br>On Wednesday, July 13, 2016 =
at 5:50:25 PM UTC-4, D. B. wrote:<span class=3D""><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul=
13, 2016 at 10:39 PM, <span dir=3D"ltr"><<a rel=3D"nofollow">ezmag...@=
gmail.com</a>></span> wrote:<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"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex">They found 2% penalty for LTR over RTL on o=
ne of the SPEC2006 tests.</blockquote><div><br></div></span>That's inte=
resting. But then why not make the arguments evalued right to left then?<di=
v>Is it because everything else is left to right and having this particular=
case be right-to-left may cause confusion?<br></div></div></blockquote><di=
v><br></div><div>but "everything else" is <i>not</i> evaluated LT=
R. this thread is basically all about some people's dislike of the newl=
y specd RTL evaluation of assignment chains.<br>=C2=A0<br></div></div></div=
></div>
</blockquote></span></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" 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@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/27ff5d7b-043a-4be6-ba54-77515c4f1c1c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27ff5d7b-043a-=
4be6-ba54-77515c4f1c1c%40isocpp.org</a>.<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" 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/CAKiZDp3oNYAw_jz37XM1NuV9L-yBJGdQK%2B=
7Z%2Bv2PN%3D7DaLdROQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3oNY=
Aw_jz37XM1NuV9L-yBJGdQK%2B7Z%2Bv2PN%3D7DaLdROQ%40mail.gmail.com</a>.<br />
--001a114ba1cefb283705378c0f2f--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 13 Jul 2016 17:45:37 -0500
Raw View
--001a113e9346463c0305378c2701
Content-Type: text/plain; charset=UTF-8
On 13 July 2016 at 17:05, <ezmagician@gmail.com> wrote:
> I for one would like for there to be a specified order to things, if only
> to lessen the number of "unspecified" or "implementation defined" areas of
> C++.
> It may be helpful for the compiler writers, but it gives the programmer
> another "I cannot do this" to worry about.
>
You see this as a Bad Thing. I see this as a Good Thing. "There Be
Dragons; Don't Go There" beats encouraging evaluation order dependent code.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BPa5r_t1EegUF3K%2B57bjrHVYDTqjA8sv-yn2cOAw-VaOA%40mail.gmail.com.
--001a113e9346463c0305378c2701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 13 July 2016 at 17:05, <span dir=3D"ltr"><<a href=3D"mailto:ezmagici=
an@gmail.com" target=3D"_blank">ezmagician@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>I for one would like for there to be=
a specified order to things, if only to lessen the number of "unspeci=
fied" or "implementation defined" areas of C++.</div><div>It=
may be helpful for the compiler writers, but it gives the programmer anoth=
er "I cannot do this" to worry about.</div><div></div></blockquot=
e></div><br>You see this as a Bad Thing.=C2=A0 I see this as a Good Thing. =
=C2=A0"There Be Dragons; Don't Go There" beats encouraging ev=
aluation order dependent code.<br>-- <br><div class=3D"gmail_signature" dat=
a-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+=
1-847-691-1404</div></div></div></div></div>
</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/CAGg_6%2BPa5r_t1EegUF3K%2B57bjrHVYDTq=
jA8sv-yn2cOAw-VaOA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPa5r=
_t1EegUF3K%2B57bjrHVYDTqjA8sv-yn2cOAw-VaOA%40mail.gmail.com</a>.<br />
--001a113e9346463c0305378c2701--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 13 Jul 2016 16:19:37 -0700
Raw View
Em quarta-feira, 13 de julho de 2016, =C3=A0s 18:26:05 PDT, Hyman Rosen esc=
reveu:
> On Wed, Jul 13, 2016 at 5:53 PM, Thiago Macieira <thiago@macieira.org>
>=20
> wrote:
> > Because it's the "happens before" order. When you write:
> > a() =3D b() =3D c() =3D d();
> >=20
> > The c() =3D d() assignment happens first. So regardless of the order in
> > which c()
> > and d() are called, I'd expect that the pair gets called before b().
>=20
> When you write
>=20
> ((a() =3D b()) =3D c()) =3D d()
>=20
> the a() =3D b() assignment happens first. But the standard (now) still
> requires the valuation order d(), c(), b(), a().
> It doesn't seem to me that you've made your case.
You didn't actually change anything. The consequence of the associativity i=
s=20
that the right side needs to be evaluated before the left. The fact that th=
e=20
left also has an assignment inside parentheses is irrelevant.
> As for temporaries, 64-bit x86 has some 16 64-bit registers and 8 128-bit
> SSE registers, so there's plenty of room to hold them, and they don't nee=
d
> to go onto the stack.
That is far from the case. First of all, of the 16 general-purpose register=
s,=20
only half of them are callee-saved. You can't store data in a scratch (call=
er-
saved) register and call a function: it will be gone when the function=20
returns. And even the caller-saved registers aren't free: if you want to us=
e=20
them, you need to save what was in it, which means pushing to the stack. An=
y=20
way you look at it, saving temporaries requires stack space.
Then add to the fact that types may be larger than 64 bits and thus require=
=20
more registers.
There are 16 128-bit SSE2 registers on x86-64, expanded to 32 x 512-bit wit=
h=20
AVX512, but only the low 128 bits of 6 of those are caller-saved and, besid=
es,=20
moving data to and from the SSE registers isn't free.
The only way you could talk about using registers as free storage is on=20
machines with rotating register windows (like SPARC and IA-64), provided th=
at=20
the CPU does have a large register set to back it (like modern UltraSPARC=
=20
cores do, but not the Itanium cores, though IA-64's dynamically-sized regis=
ter=20
window is more efficient than SPARC's fixed-size one). But then note that t=
he=20
large register window means paying a penalty on context-switching.
> But that's not even important; the amount of code
> that consists of such multiple assignments is minuscule. The important
> thing is to make the language clear and let the compilers do the worrying
> about generating good translations.
And here's what you don't get:
1) you dismissed a fact
The benchmarks have shown that there is a performance variance. If the chan=
ge=20
were negligible, it wouldn't have shown up, but it did. That concludes that=
=20
the amount of code is either not minuscule or is significant even if minusc=
ule.
2) you stated what is an opinion as a fact
You said that it's more important to make the language clear than to let th=
e=20
compilers optimise. That is your opinion and it may be shared with a lot of=
=20
people, but it is by no means a fact.
Moreover, the committee disagrees with your opinion.
--=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/3238385.nHdOI93KFb%40tjmaciei-mobl1.
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 18:37:15 -0700 (PDT)
Raw View
------=_Part_35_19666551.1468460235222
Content-Type: multipart/alternative;
boundary="----=_Part_36_296405750.1468460235223"
------=_Part_36_296405750.1468460235223
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=8812:00:55=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> We have been around and around this discussion many times before.
>
True. But there can be some further conclusions.
=20
> I know that there are people who do not accept that C++ should have stric=
t=20
> left-to-right evaluation.
>
At least my opinion is not only for C++. Particularly, C++ is complicated=
=20
enough. So I doubt any modification of rules can be easily settle down=20
without confusion. The latter is not against to any concrete proposal, but=
=20
it counts.
=20
> I believe that those people are utterly wrong, but that there is no way t=
o=20
> convince them of that, not unlike other political situations. To me, the=
=20
> notion that (a() << (b() << c())) and (a() =3D (b() =3D c())) should call=
a(),=20
> b(), and c() in different specified orders, while (a() + (b() + c()))=20
> should call them in unspecified order is so irrational that it beggars=20
> belief.
>
> That is your belief. I admit there is something too subjective and we=20
can't get consensus about it. But there is still something yet to clarify.=
=20
Perhaps I should emphasize again: the changes make some portable code in=20
previous version of C++ lose some precisely specified semantics properties,=
=20
and you can recover it by rewriting the code without decrease portability.=
=20
(Even it does not, the impact may be still serious ... e.g. a lot of work=
=20
to do to ensure the code has the same exact meaning to maintainers.) This=
=20
issue is not related to your belief, or even the rules themselves.
=20
> On Tue, Jul 12, 2016 at 4:02 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8B=E5=8D=8812:34:57=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:
>>>>
>>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=
=8C UTC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catmur=E5=86=99=E9=81=93=
=EF=BC=9A
>>>>>
>>>>>
>>>>> On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>>>>> >
>>>>> > The right decision is strict left-to-right order of evaluation for=
=20
>>>>> all expressions, with side-effects fully completed as they are evalua=
ted.
>>>>>
>>>>> That sounds like a performance nightmare.=20
>>>>>
>>>>
>>>> This can be resolved by introducing some specific primitives to specif=
y=20
>>>> the evaluation order not obeying this rule. However, they will be leng=
thy=20
>>>> and users will be reluctant to use them. Users will have excuse grante=
d by=20
>>>> the default rule.
>>>>
>>>> The true harm of such decision is, it encourages stupidity and lazines=
s=20
>>>> as the default case. Freedom of expressiveness is defeated by freedom =
of=20
>>>> lack of consideration.
>>>>
>>>
>>> Accepting reality should superseded all else. Reality has shown us that=
,=20
>>> 99% of the time, programmers assume things happen in a left-to-right or=
der.=20
>>> Which means that your vaunted "freedom of expressiveness" is only being=
=20
>>> used 1% of the time.
>>>
>>> What should be there is what is already there. As formal encouragement,=
=20
>> the rules should be long lived in foreseeable future, so it should bette=
r=20
>> avoid compromise merely to the status quo. (Actually I don't think there=
is=20
>> need of the compromise. Note that we already have ways to make 99% cases=
=20
>> work perfectly. The illustrated examples in the original proposal, howev=
er,=20
>> are disputable.) And whether it is reality or not, if the assumption doe=
s=20
>> not feed the need (of reality, of course) well, it should be thrown away=
..=20
>> As I experienced, the real need now is to do "the right thing", not "wor=
se=20
>> is better", because we already have the latter enough, if not too much.=
=20
>> Your idea seems to go to the wrong direction.
>>
>> One more reality is, people get bitten when they think too little. Every=
=20
>> will-educated programmer around me does not assume left-to-right=20
>> evaluation, because the rules of the languages (not only C++) told them =
it=20
>> should not be relied on, or the coding convention forbids them to use su=
ch=20
>> risky styles. Unless you eliminate all rules about evaluation order othe=
r=20
>> than left-to-right in the world (again, not only in C++), programmers wh=
o=20
>> have to deal with multiple languages will have a lesson from it, sooner =
or=20
>> later. Again in reality, very few programmers learn and use only C++.=20
>> (Notably, C does not have such guarantee, so they must care about it.)=
=20
>> After changing of the rules in C++, they have to care more, if not be=20
>> ignorant to these changes totally - which is not a good attitude, anyway=
..
>> =20
>>
>>> C++ is a practical language, not some ivory-tower experiment. We must=
=20
>>> bow to reality when it is presented to us. And reality tells us, *time=
=20
>>> and again*, that we lose far more from undefined evaluation order than=
=20
>>> we gain from it. We lose time in debugging. We lose time in development=
.. We=20
>>> lose mental time in having to think about it.
>>>
>>> The only thing we gain from it is making it harder to become a=20
>>> proficient C++ programmer. And that's not a benefit of the language.
>>>
>>> No. I don't have such experience of wasting time on such things. Just=
=20
>> keep away from those suspicious styles of code, and nothing would be los=
t.=20
>> You will eventually gain more (spare time, for example) because you don'=
t=20
>> have to learn such strange code patterns if it is identified as smelly o=
ne.=20
>> Only a few proficient reviewers should know how to precisely find them a=
nd=20
>> prevent them harm the "practical" people.
>> =20
>>
>>> This is offensive to people who want to write the "more correct" (more=
=20
>>>> precise, easier to read, easier to maintain) - not merely "runnable" c=
ode:=20
>>>> it makes they harder to achieve their goals while giving them nothing.
>>>>
>>>
>>> I don't know; I find this to be quite "correct" code:
>>>
>>> auto inserts =3D make_array(v.insert(v.end(), std::forward<Ts>(args))..=
..);
>>>
>>> This code is very clear: for each item in the pack, insert it at the=20
>>> end, capturing those iterators in an array. I see no reason to express =
this=20
>>> code in a more verbose way. Well, besides the fact that it doesn't work=
,=20
>>> but that's only due to a silly language rule.
>>>
>>> What is the "more correct" alternative? Show me how to write that same=
=20
>>> code in a way that is as clear and *concise* as this, which doesn't=20
>>> provoke undefined behavior.
>>>
>>> I admit the language is silly here. The point is there is no way to=20
>> directly express the specified order you need here. But if it is not so=
=20
>> silly to meet your requirements, it would be equally silly when I don't=
=20
>> want to depend on the order explicitly. It would be even more silly,=20
>> because when you have no simple way to express the specified order, you =
can=20
>> workaround by verbosity; however, after the rules of specified order are=
=20
>> settled, I will not workaround without breaking portability. This is the=
=20
>> net lost.
>>
>> I say "more correct" is about logical correctness of the code. Whenever=
=20
>> you make the code precisely work as your need through the specific rules=
=20
>> you have known, it is more correct than code relying on some unconscious=
ly=20
>> randomly selected and accidentally effective rules, though it may be too=
=20
>> wordy.
>>
>> The root of evil in your case is, the comma token does not play one role=
=20
>> well. This insane design can be attributed to C, only because it need to=
=20
>> specify order in several uncommon contexts (e.g. in the condition clause=
of=20
>> a loop statement). It can't consistently use semicolon because the desi=
gn=20
>> of syntax. Your case is one of the victim of the silly design.
>>
>> It is unfortunate that the comma operator is more messy in C++ as a=20
>> result of overloaded operator comma. But actually, the whole silly thing=
is=20
>> still that simple - the ability of specifying the order by the (builtin)=
=20
>> operator comma, or more precisely, *making a comma as an operator as=20
>> well as a non-operator in similar contexts without any reasons besides t=
o=20
>> workaround the silly syntax design*. Why not semicolon? The rules would=
=20
>> be simpler a lot.
>>
>> The answer may be *compatibility*. But why you throw away compatibility=
=20
>> just *now*, in a hurry and a far more disputable manner?
>>
>> Despite the existed messy rules, a better solution is to add new core=20
>> rules to clearly express your need without such verbosity, e.g. allowing=
=20
>> semicolons as separators of function arguments.
>>
>> =20
>>
>>> And if `make_array` offends you, feel free to change it into any=20
>>> function that would take a sequence of iterators.
>>>
>>> > The reason for defining order is to avoid code that "accidentally=20
>>>>> works" - that is, code that has order dependencies such that its beha=
vior=20
>>>>> is undefined or unspecified, but happens to be built with a compiler =
whose=20
>>>>> behavior matches the programmer's intent. Such code can mysteriously =
break=20
>>>>> when built on a different platform, long after it was written and has=
=20
>>>>> appeared to work correctly. We have personally encountered this situa=
tion=20
>>>>> in our company.
>>>>>
>>>>> There will always be implementation variance especially between=20
>>>>> platforms. A blanket statement that it is always bad ignores the mult=
itude=20
>>>>> of reasons to permit and encourage implementation variance. And of co=
urse=20
>>>>> the implementation variance already exists, so you won't be able to c=
hange=20
>>>>> the behavior of existing platforms.=20
>>>>>
>>>>> > The reason for choosing strict left-to-right order is that it's=20
>>>>> trivial to explain, matches the order in which code is read, and matc=
hes=20
>>>>> other languages such as Java.
>>>>>
>>>>> Any experienced user reads code blocks as a unit, just as any=20
>>>>> proficient reader of natural languages reads sentences and paragraphs=
in a=20
>>>>> single glance.=20
>>>>>
>>>>
>>>> Yes. This is exactly my experience, and not only to C++. If a user can=
=20
>>>> only work under a single strict order with some sequenced materials, I=
=20
>>>> doubt his/her brain is damaged. Moreover, assuming left-to-right to be=
the=20
>>>> natural order may be offensive to people who are using natural languag=
es=20
>>>> with right-to-left natural layout.
>>>>
>>>
>>> Wait a minute. Having a left-to-right order is offensive to people who=
=20
>>> use right-to-left languages... but having all our keywords being=20
>>> *English* is perfectly fine? What about the fact that the parser goes=
=20
>>> left-to-right; are they offended by that too? Maybe my brain is too dam=
aged=20
>>> from not being able to read paragraphs at a single glance, but I really=
=20
>>> can't follow your logic here.
>>>
>> No, it does not. ... I mean, it is *not *English. In reality, some=20
>> people ignorant to programming have already protested the "discriminatio=
n"=20
>> of English-central culture in programming languages. As a rebuttal, we t=
old=20
>> them the words in common programming languages are never "English", just=
=20
>> occasionally spelled by Latin alphabets similarly as English words due t=
o=20
>> some historical reasons.
>> I was illustrating the difference between processing text of natural=20
>> languages vs. in programming languages should not be ignored. Because I=
=20
>> don't think they can effectively use the same path of logic in one's bra=
in,=20
>> there is no "natural" bonus of RTL evaluation. Further, I am sure differ=
ent=20
>> natural languages can share little processing logic in my brain unless t=
hey=20
>> are similar enough (which is already difficult between arbitrary natural=
=20
>> languages), though they may share similar parsing logic in typical cases=
=20
>> (extraordinary cases are rare, e.g. Dongba symbols). Since I don't daily=
=20
>> use RTL languages so I used "may" to illustrate the possibility if the=
=20
>> points above is not feasible.
>> As of a parser... it can go from left to right, and vice versa. It can=
=20
>> even be neither LTR or RTL, but I guess it will be very inefficient.
>>
>>>
>>> Also, programming isn't a sport; you don't get extra points for degree=
=20
>>> of difficulty.
>>>
>>> And is making C++ more similar to Java supposed to be a *good* thing?=
=20
>>>>>
>>>>
>>>> And I can imagine making C++ less similar to C here has more impact in=
=20
>>>> reality.
>>>>
>>>
>>> C is not a subset of C++, and it hasn't been since... C++98. While ther=
e=20
>>> are people who write in the subset between C and C++, this is usually c=
ode=20
>>> intended to be compiled as either. And such people are generally writin=
g C=20
>>> which can be compiled as C++, not writing C++ that can be compiled as C=
.. So=20
>>> they will write it under C's rules first and foremost. Porting the othe=
r=20
>>> way is much rarer.
>>>
>>> Yes, C++ should not be messed up with C. But again in reality, there a=
=20
>> plenty of "C/C++" code to maintain. People write code that compiled both=
by=20
>> C and C++ compiler (e.g. header files), or transfer code in C to C++ wit=
h=20
>> quite a few modifications (e.g. GCC source tree). The "context switch"=
=20
>> between working on C and C++ code base is often a pain, so those people=
=20
>> will likely continue to only use the common set of C and C++ features. S=
o=20
>> the changes in the rule has almost no effect to them, if they are not=20
>> confused.
>>
>> The worse thing is, the changes also make it more complicated to transfe=
r=20
>> code between different version of C++ dialects, since they are not=20
>> bidirectionally compatible. Note the effective region is too broad so a=
=20
>> full coverage of review is always needed to port valid code in new diale=
cts=20
>> back to the code base in old dialects (very likely in reality). Tools ma=
y=20
>> help, but not enough.
>>
>> Should the extra effort be deserved? Or is it insane to switch to the ne=
w=20
>> C++ dialects?
>> =20
>>
>>> Also, let's not forget that, when it comes to complex expressions, C ha=
s=20
>>> *nothing* on C++. We have so many more tools to write complicated=20
>>> expressions than C does. That's why my example involved parameter packs=
and=20
>>> fold expressions; to me, they're the poster-child for making sequences =
of=20
>>> complex expressions that the user will *expect* to evaluate in order.
>>>
>>> This expectation are based on vague and non modular design of specific=
=20
>> syntax (mostly borrowed from C), rather than intuition.=20
>>
>> Briefly, there is no problem.to specify the order. But if the=20
>> unavoidable cost is to limit how to specify the order in other cases, it=
is=20
>> problematic and unacceptable.
>> =20
>>
>>> C++ needs it far more than C.
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f4=
79-4416-ad7a-560f97af60bf%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f=
479-4416-ad7a-560f97af60bf%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/84e8468a-9b31-421b-8b9f-dda81d15cbf7%40isocpp.or=
g.
------=_Part_36_296405750.1468460235223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:00:55=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">We have been around and around this discussion many times bef=
ore.</div></blockquote><div>True. But there can be some further conclusions=
..<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">I know that there are people who do not accept that C++ should have str=
ict left-to-right evaluation.</div></blockquote><div>At least my opinion is=
not only for C++. Particularly, C++ is complicated enough. So I doubt any =
modification of rules can be easily settle down without confusion. The latt=
er is not against to any concrete proposal, but it counts.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I believe that=
those people are utterly wrong, but that there is no way to convince them =
of that, not unlike other political situations.=C2=A0 To me, the notion tha=
t (a() << (b() << c())) and (a() =3D (b() =3D c())) should call=
a(), b(), and c() in different specified orders, while (a() + (b() + c()))=
should call them in unspecified order is so irrational that it beggars bel=
ief.</div><div><br></div></blockquote><div>That is your belief. I admit the=
re is something too subjective and we can't get consensus about it. But=
there is still something yet to clarify. Perhaps I should emphasize again:=
the changes make some portable code in previous version of C++ lose some p=
recisely specified semantics properties, and you can recover it by rewritin=
g the code without decrease portability. (Even it does not, the impact may =
be still serious ... e.g. a lot of work to do to ensure the code has the sa=
me exact meaning to maintainers.) This issue is not related to your belief,=
or even the rules themselves.<br>=C2=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div><div class=3D"gmail_quote">On Tue, Jul 12, 2016 at=
4:02 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"ODVWQLWwCgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">frank...@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 =
2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=
=8B=E5=8D=8812:34:57=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<span><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, July 11, =
2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8812=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=888:27:41=EF=BC=8CEdward Catm=
ur=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr"><br>
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <<a rel=3D"nofollow">h=
yman...@gmail.com</a>> wrote:<br>
><br>
> The right decision is strict left-to-right order of evaluation for all=
expressions, with side-effects fully completed as they are evaluated.</p>
<p dir=3D"ltr">That sounds like a performance nightmare. </p></blockquote><=
div><br>This can be resolved by introducing some specific primitives to spe=
cify the evaluation order not obeying this rule. However, they will be leng=
thy and users will be reluctant to use them. Users will have excuse granted=
by the default rule.<br><br>The true harm of such decision is, it encourag=
es stupidity and laziness as the default case. Freedom of expressiveness is=
defeated by freedom of lack of consideration.</div></div></blockquote><div=
><br>Accepting reality should superseded all else. Reality has shown us tha=
t, 99% of the time, programmers assume things happen in a left-to-right ord=
er. Which means that your vaunted "freedom of expressiveness" is =
only being used 1% of the time.<br><br></div></div></blockquote></span><div=
>What should be there is what is already there. As formal encouragement, th=
e rules should be long lived in foreseeable future, so it should better avo=
id compromise merely to the status quo. (Actually I don't think there i=
s need of the compromise. Note that we already have ways to make 99% cases =
work perfectly. The illustrated examples in the original proposal, however,=
are disputable.) And whether it is reality or not, if the assumption does =
not feed the need (of reality, of course) well, it should be thrown away. A=
s I experienced, the real need now is to do "the right thing", no=
t "worse is better", because we already have the latter enough, i=
f not too much. Your idea seems to go to the wrong direction.<br><br>One mo=
re reality is, people get bitten when they think too little. Every will-edu=
cated programmer around me does not assume left-to-right evaluation, becaus=
e the rules of the languages (not only C++) told them it should not be reli=
ed on, or the coding convention forbids them to use such risky styles. Unle=
ss you eliminate all rules about evaluation order other than left-to-right =
in the world (again, not only in C++), programmers who have to deal with mu=
ltiple languages will have a lesson from it, sooner or later. Again in real=
ity, very few programmers learn and use only C++. (Notably, C does not have=
such guarantee, so they must care about it.) After changing of the rules i=
n C++, they have to care more, if not be ignorant to these changes totally =
- which is not a good attitude, anyway.<br>=C2=A0<br></div><span><blockquot=
e 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>C++ is a practical lang=
uage, not some ivory-tower experiment. We must bow to reality when it is pr=
esented to us. And reality tells us, <i>time and again</i>, that we lose fa=
r more from undefined evaluation order than we gain from it. We lose time i=
n debugging. We lose time in development. We lose mental time in having to =
think about it.<br><br>The only thing we gain from it is making it harder t=
o become a proficient C++ programmer. And that's not a benefit of the l=
anguage.<br><br></div></div></blockquote></span><div>No. I don't have s=
uch experience of wasting time on such things. Just keep away from those su=
spicious styles of code, and nothing would be lost. You will eventually gai=
n more (spare time, for example) because you don't have to learn such s=
trange code patterns if it is identified as smelly one. Only a few proficie=
nt reviewers should know how to precisely find them and prevent them harm t=
he "practical" people.<br>=C2=A0<br></div><span><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>This is offensive to people who want =
to write the "more correct" (more precise, easier to read, easier=
to maintain) - not merely "runnable" code: it makes they harder =
to achieve their goals while giving them nothing.<br></div></div></blockquo=
te><div><br>I don't know; I find this to be quite "correct" c=
ode:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode><div><span style=3D"color:#008">auto</span><span style=3D"color:#000"> =
inserts </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> make_array</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#000">v</span><span style=3D"color:#660">.</span><span style=3D"color:#0=
00">insert</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
00">v</span><span style=3D"color:#660">.</span><span style=3D"color:#008">e=
nd</span><span style=3D"color:#660">(),</span><span style=3D"color:#000"> s=
td</span><span style=3D"color:#660">::</span><span style=3D"color:#000">for=
ward</span><span style=3D"color:#660"><</span><span style=3D"color:#606"=
>Ts</span><span style=3D"color:#660">>(</span><span style=3D"color:#000"=
>args</span><span style=3D"color:#660">))...);</span></div></code></div><br=
>This code is very clear: for each item in the pack, insert it at the end, =
capturing those iterators in an array. I see no reason to express this code=
in a more verbose way. Well, besides the fact that it doesn't work, bu=
t that's only due to a silly language rule.<br><br>What is the "mo=
re correct" alternative? Show me how to write that same code in a way =
that is as clear and <i>concise</i> as this, which doesn't provoke unde=
fined behavior.<br><br></div></div></blockquote></span><div>I admit the lan=
guage is silly here. The point is there is no way to directly express the s=
pecified order you need here. But if it is not so silly to meet your requir=
ements, it would be equally silly when I don't want to depend on the or=
der explicitly. It would be even more silly, because when you have no simpl=
e way to express the specified order, you can workaround by verbosity; howe=
ver, after the rules of specified order are settled, I will not workaround =
without breaking portability. This is the net lost.<br><br>I say "more=
correct" is about logical correctness of the code. Whenever you make =
the code precisely work as your need through the specific rules you have kn=
own, it is more correct than code relying on some unconsciously randomly se=
lected and accidentally effective rules, though it may be too wordy.<br><br=
>The root of evil in your case is, the comma token does not play one role w=
ell. This insane design can be attributed to C, only because it need to spe=
cify order in several uncommon contexts (e.g. in the condition clause of a =
loop statement). It can't=C2=A0 consistently use semicolon because the =
design of syntax. Your case is one of the victim of the silly design.<br><b=
r> It is unfortunate that the comma operator is more messy in C++ as a resu=
lt of overloaded operator comma. But actually, the whole silly thing is sti=
ll that simple - the ability of specifying the order by the (builtin) opera=
tor comma, or more precisely, <i>making a comma as an operator as well as a=
non-operator in similar contexts without any reasons besides to workaround=
the silly syntax design</i>. Why not semicolon? The rules would be simpler=
a lot.<br><br>The answer may be <i>compatibility</i>. But why you throw aw=
ay compatibility just <i>now</i>, in a hurry and a far more disputable mann=
er?<br><br>Despite the existed messy rules, a better solution is to add new=
core rules to clearly express your=20
need without such verbosity, e.g. allowing semicolons as separators of=20
function arguments.<br><br>=C2=A0<br></div><span><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>And if `make_array` offends you, feel f=
ree to change it into any function that would take a sequence of iterators.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">> The reason for defining order is to avoid code that &qu=
ot;accidentally works" - that is, code that has order dependencies suc=
h that its behavior is undefined or unspecified, but happens to be built wi=
th a compiler whose behavior matches the programmer's intent. Such code=
can mysteriously break when built on a different platform, long after it w=
as written and has appeared to work correctly. We have personally encounter=
ed this situation in our company.</p>
<p dir=3D"ltr">There will always be implementation variance especially betw=
een platforms. A blanket statement that it is always bad ignores the multit=
ude of reasons to permit and encourage implementation variance. And of cour=
se the implementation variance already exists, so you won't be able to =
change the behavior of existing platforms. </p>
<p dir=3D"ltr">> The reason for choosing strict left-to-right order is t=
hat it's trivial to explain, matches the order in which code is read, a=
nd matches other languages such as Java.</p>
<p dir=3D"ltr">Any experienced user reads code blocks as a unit, just as an=
y proficient reader of natural languages reads sentences and paragraphs in =
a single glance. </p></blockquote><div><br>Yes. This is exactly my experien=
ce, and not only to C++. If a user can only work under a single strict orde=
r with some sequenced materials, I doubt his/her brain is damaged. Moreover=
, assuming left-to-right to be the natural order may be offensive to people=
who are using natural languages with right-to-left natural layout.<br></di=
v></div></blockquote><div><br>Wait a minute. Having a left-to-right order i=
s offensive to people who use right-to-left languages... but having all our=
keywords being <i>English</i> is perfectly fine? What about the fact that =
the parser goes left-to-right; are they offended by that too? Maybe my brai=
n is too damaged from not being able to read paragraphs at a single glance,=
but I really can't follow your logic here.<br></div></div></blockquote=
></span><div>No, it does not. ... I mean, it is <i>not </i>English. In real=
ity, some people ignorant to programming have already protested the "d=
iscrimination" of English-central culture in programming languages. As=
a rebuttal, we told them the words in common programming languages are nev=
er "English", just occasionally spelled by Latin alphabets simila=
rly as English words due to some historical reasons.<br>I was illustrating =
the difference between processing text of natural languages vs. in programm=
ing languages should not be ignored. Because I don't think they can eff=
ectively use the same path of logic in one's brain, there is no "n=
atural" bonus of RTL evaluation. Further, I am sure different natural =
languages can share little processing logic in my brain unless they are sim=
ilar enough (which is already difficult between arbitrary natural languages=
), though they may share similar parsing logic in typical cases (extraordin=
ary cases are rare, e.g. Dongba symbols). Since I don't daily use RTL l=
anguages so I used "may" to illustrate the possibility if the poi=
nts above is not feasible.<br>As of a parser... it can go from left to righ=
t, and vice versa. It can even be neither LTR or RTL, but I guess it will b=
e very inefficient.<br></div><span><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><br>Also, programming isn't a sport; you don'=
;t get extra points for degree of difficulty.<br><br></div><blockquote clas=
s=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><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<p dir=3D"ltr">And is making C++ more similar to Java supposed to be a *goo=
d* thing? </p></blockquote><div><br>And I can imagine making C++ less simil=
ar to C here has more impact in reality.<br></div></div></blockquote><div><=
br>C is not a subset of C++, and it hasn't been since... C++98. While t=
here are people who write in the subset between C and C++, this is usually =
code intended to be compiled as either. And such people are generally writi=
ng C which can be compiled as C++, not writing C++ that can be compiled as =
C. So they will write it under C's rules first and foremost. Porting th=
e other way is much rarer.<br><br></div></div></blockquote></span><div>Yes,=
C++ should not be messed up with C. But again in reality, there a plenty o=
f "C/C++" code to maintain. People write code that compiled both =
by C and C++ compiler (e.g. header files), or transfer code in C to C++ wit=
h quite a few modifications (e.g. GCC source tree). The "context switc=
h" between working on C and C++ code base is often a pain, so those pe=
ople will likely continue to only use the common set of C and C++ features.=
So the changes in the rule has almost no effect to them, if they are not c=
onfused.<br><br>The worse thing is, the changes also make it more complicat=
ed to transfer code between different version of C++ dialects, since they a=
re not bidirectionally compatible. Note the effective region is too broad s=
o a full coverage of review is always needed to port valid code in new dial=
ects back to the code base in old dialects (very likely in reality). Tools =
may help, but not enough.<br><br>Should the extra effort be deserved? Or is=
it insane to switch to the new C++ dialects?<br>=C2=A0<br></div><span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Also, let's n=
ot forget that, when it comes to complex expressions, C has <i>nothing</i> =
on C++. We have so many more tools to write complicated expressions than C =
does. That's why my example involved parameter packs and fold expressio=
ns; to me, they're the poster-child for making sequences of complex exp=
ressions that the user will <i>expect</i> to evaluate in order.<br><br></di=
v></div></blockquote></span><div>This expectation are based on vague and no=
n modular design of specific syntax (mostly borrowed from C), rather than i=
ntuition. <br><br>Briefly, there is no <a href=3D"http://problem.to" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fproblem.to\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNG8vnOLS3qUYoajJovpPitpi9N6-Q';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fproblem.to\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNG8vnOLS3qUYoajJovpPitpi9N6-Q';return true;"=
>problem.to</a> specify the order. But if the unavoidable cost is to limit =
how to specify the order in other cases, it is problematic and unacceptable=
..<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>C++ needs it far more than C.<br></div></div></blockquote></s=
pan></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ODVWQLWwCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"ODVWQLWwCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/59cb4a9f-f479-4416-ad7a-560f97af60bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f479-4416-ad7a-560f97af60bf%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/59cb4a9f-f479-4416-ad7a-560f97af60bf%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/59cb4a9f-f479-4416-<wbr>ad7a-=
560f97af60bf%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></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/84e8468a-9b31-421b-8b9f-dda81d15cbf7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/84e8468a-9b31-421b-8b9f-dda81d15cbf7=
%40isocpp.org</a>.<br />
------=_Part_36_296405750.1468460235223--
------=_Part_35_19666551.1468460235222--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 18:48:30 -0700 (PDT)
Raw View
------=_Part_70_864467083.1468460910134
Content-Type: multipart/alternative;
boundary="----=_Part_71_743802657.1468460910134"
------=_Part_71_743802657.1468460910134
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> The true harm of such decision is, it encourages stupidity and laziness=
=20
>> as the default case.
>>
>
> Please try to stick to technical arguments on this mailing list, instead=
=20
> of personally attacking ("stupidity") the people who prefer a different=
=20
> outcome than you do.
>
> Jeffrey
>
I believed it was common sense that "insisting on ignorance of language=20
rules as a need in general" is stupidity, to anyone. So it was not attack=
=20
to anyone, esp. "personally".
Technically, the rules consist the interface of the designed language. How=
=20
will you allow people who know little about them to decide how they should=
=20
be?
--=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/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%40isocpp.or=
g.
------=_Part_71_743802657.1468460910134
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yassk=
in=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Jul 11, 2016 at 7:4=
6 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"qjceN8ewCgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The true harm of such=
decision is, it encourages stupidity and laziness as the default case.</di=
v></div></blockquote><div><br></div><div>Please try to stick to technical a=
rguments on this mailing list, instead of personally attacking ("stupi=
dity") the people who prefer a different outcome than you do.</div></d=
iv><br></div><div>Jeffrey</div></div></blockquote><div><br>I believed it wa=
s common sense that "insisting on ignorance of language rules as a nee=
d in general" is stupidity, to anyone. So it was not attack to anyone,=
esp. "personally".<br><br>Technically, the rules consist the int=
erface of the designed language. How will you allow people who know little =
about them to decide how they should be?<br><br><br> </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/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516=
%40isocpp.org</a>.<br />
------=_Part_71_743802657.1468460910134--
------=_Part_70_864467083.1468460910134--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 19:00:59 -0700 (PDT)
Raw View
------=_Part_66_1117262735.1468461659265
Content-Type: multipart/alternative;
boundary="----=_Part_67_1131058054.1468461659265"
------=_Part_67_1131058054.1468461659265
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=8812:12:08=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> The "stupidity and laziness" argument demands that the programming=20
> language should contain constructs that must not be used, and that will a=
ct=20
> as traps for the unwary. The notion that this is a desirable feature aga=
in=20
> seems to me so irrational that it beggars belief.
>
> No. I don't express that. Any constructs should be used at ones' own=20
risks. If you don't want to use something, that's OK. If you don't want to=
=20
see the code use such features, then tag the code using them as of "bad=20
code style" with sufficient reasons which are *not so subjective* (when you=
=20
want to convince others). But "I'm not using it" is certainly not a good=
=20
excuse to *forbid *it used *by others through the language specification*,=
=20
unless you want to keep those users away. Since C++ is not designed as=20
noob-oriented by you, and there are some people do rely on something you=20
want to remove, I think your point is problematic. If you want to remove=20
something indisputably, you have to prove that it does nothing useful to *a=
lmost=20
anyone* or there are sufficient ways as *replacement*, and/or it is harmful=
*in=20
almost any case*. This is not the case here.
=20
> On Tue, Jul 12, 2016 at 12:01 PM, 'Jeffrey Yasskin' via ISO C++ Standard =
-=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gmail.com=20
>> <javascript:>> wrote:
>>>
>>> The true harm of such decision is, it encourages stupidity and laziness=
=20
>>> as the default case.
>>>
>>
>> Please try to stick to technical arguments on this mailing list, instead=
=20
>> of personally attacking ("stupidity") the people who prefer a different=
=20
>> outcome than you do.
>>
>> Jeffrey
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2=
Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%=
2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
>
--=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/aa9d5e3d-c4f5-46c8-b43e-596121163b03%40isocpp.or=
g.
------=_Part_67_1131058054.1468461659265
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:12:08=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">The "stupidity and laziness" argument demands that =
the programming language should contain constructs that must not be used, a=
nd that will act as traps for the unwary.=C2=A0 The notion that this is a d=
esirable feature again seems to me so irrational that it beggars belief.</d=
iv><div><br></div></blockquote><div>No. I don't express that. Any const=
ructs should be used at ones' own risks. If you don't want to use s=
omething, that's OK. If you don't want to see the code use such fea=
tures, then tag the code using them as of "bad code style" with s=
ufficient reasons which are <i>not so subjective</i> (when you want to conv=
ince others).=C2=A0 But "I'm not using it" is certainly not a=
good excuse to <i>forbid </i>it used <i>by others through the language spe=
cification</i>, unless you want to keep those users away. Since C++ is not =
designed as noob-oriented by you, and there are some people do rely on some=
thing you want to remove, I think your point is problematic. If you want to=
remove something indisputably, you have to prove that it does nothing usef=
ul to <i>almost anyone</i> or there are sufficient ways as <i>replacement</=
i>, and/or it is harmful <i>in almost any case</i>. This is not the case he=
re.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><d=
iv class=3D"gmail_quote">On Tue, Jul 12, 2016 at 12:01 PM, 'Jeffrey Yas=
skin' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"MyFB41GxCgA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">std-pr..=
..@isocpp.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><span>On Mon, Jul 11, 2016 at 7:=
46 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"MyFB41GxCgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The true harm of such=
decision is, it encourages stupidity and laziness as the default case.</di=
v></div></blockquote><div><br></div></span><div>Please try to stick to tech=
nical arguments on this mailing list, instead of personally attacking (&quo=
t;stupidity") the people who prefer a different outcome than you do.</=
div></div><br></div><div>Jeffrey</div></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
MyFB41GxCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"MyFB41GxCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUG=
xHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz6F=
%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium\x3de=
mail\x26utm_source\x3dfooter';return true;" onclick=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz=
6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CANh-dXnM%2Bz6F%<wbr>3DMfruh6=
baZX7_5XXkrUGxHkh_%2B_<wbr>8_c1j60gm_A%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></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/aa9d5e3d-c4f5-46c8-b43e-596121163b03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aa9d5e3d-c4f5-46c8-b43e-596121163b03=
%40isocpp.org</a>.<br />
------=_Part_67_1131058054.1468461659265--
------=_Part_66_1117262735.1468461659265--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Wed, 13 Jul 2016 22:05:03 -0400
Raw View
--001a114dd95020e0bc05378eee0d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I for one would be very happy if claims on stupidity, syndroms and other
sorts of derogatory comments were kept away from the discussion. I
appreciate the intellect of people I discuss with, even (particularly?)
when we don't see eye to eye. I appreciate Jeffrey's efforts in that
direction.
2016-07-13 21:48 GMT-04:00 FrankHB1989 <frankhb1989@gmail.com>:
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 U=
TC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gmail.com> wrote:
>>>
>>> The true harm of such decision is, it encourages stupidity and laziness
>>> as the default case.
>>>
>>
>> Please try to stick to technical arguments on this mailing list, instead
>> of personally attacking ("stupidity") the people who prefer a different
>> outcome than you do.
>>
>> Jeffrey
>>
>
> I believed it was common sense that "insisting on ignorance of language
> rules as a need in general" is stupidity, to anyone. So it was not attack
> to anyone, esp. "personally".
>
> Technically, the rules consist the interface of the designed language. Ho=
w
> will you allow people who know little about them to decide how they shoul=
d
> be?
>
>
> --
> 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/b2e0db59-3e5=
d-4e7b-80a8-7ea9279d3516%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e=
5d-4e7b-80a8-7ea9279d3516%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAKiZDp1SkppTFL%3DQ4qfPf0%2BO36Wf5N1jAGfhzLvFfBb=
tfQc1Gw%40mail.gmail.com.
--001a114dd95020e0bc05378eee0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I for one would be very happy if claims on stupidity, synd=
roms and other sorts of derogatory comments were kept away from the discuss=
ion. I appreciate the intellect of people I discuss with, even (particularl=
y?) when we don't see eye to eye. I appreciate Jeffrey's efforts in=
that direction.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">2016-07-13 21:48 GMT-04:00 FrankHB1989 <span dir=3D"ltr"><<a hr=
ef=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com=
</a>></span>:<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"><br><br=
>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=93=EF=
=BC=9A<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 cl=
ass=3D"gmail_quote"><span class=3D"">On Mon, Jul 11, 2016 at 7:46 PM, Frank=
HB1989 <span dir=3D"ltr"><<a rel=3D"nofollow">frank...@gmail.com</a>>=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The true=
harm of such decision is, it encourages stupidity and laziness as the defa=
ult case.</div></div></blockquote><div><br></div></span><div>Please try to =
stick to technical arguments on this mailing list, instead of personally at=
tacking ("stupidity") the people who prefer a different outcome t=
han you do.</div></div><br></div><div>Jeffrey</div></div></blockquote><div>=
<br>I believed it was common sense that "insisting on ignorance of lan=
guage rules as a need in general" is stupidity, to anyone. So it was n=
ot attack to anyone, esp. "personally".<br><br>Technically, the r=
ules consist the interface of the designed language. How will you allow peo=
ple who know little about them to decide how they should be?<br><br><br> </=
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" 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@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/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e5d-=
4e7b-80a8-7ea9279d3516%40isocpp.org</a>.<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" 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/CAKiZDp1SkppTFL%3DQ4qfPf0%2BO36Wf5N1j=
AGfhzLvFfBbtfQc1Gw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1SkppT=
FL%3DQ4qfPf0%2BO36Wf5N1jAGfhzLvFfBbtfQc1Gw%40mail.gmail.com</a>.<br />
--001a114dd95020e0bc05378eee0d--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 19:30:23 -0700 (PDT)
Raw View
------=_Part_73_1216271156.1468463423739
Content-Type: multipart/alternative;
boundary="----=_Part_74_1279332464.1468463423739"
------=_Part_74_1279332464.1468463423739
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=881:47:45=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard -=
=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>
>> Please look at the technical arguments instead of calling people who=20
>> disagree with you "irrational".
>>
>
> It's not a matter of technical arguments, it's a matter of values (as you=
=20
> say). Science can tell you how to accomplish what you want, but it can't=
=20
> tell you what to want. For me, the values involved in having a programmi=
ng=20
> language that is simply specified and deterministic and consistent far=20
> outweigh the possible optimization benefit in letting the compiler pick=
=20
> evaluation order. SImilarly, I find negative value in having unspecified=
=20
> behavior in order to force programmers to be hyper-vigilant to avoid=20
> error. I find negative value in the notion that unspecified order adds=
=20
> expressiveness.
>
> It is true that matters of values are involved, but things are not as=20
simple as you thought, in reality.
=20
> C++ can do only one thing. It cannot have evaluation order both specifie=
d=20
> and unspecified. It cannot evaluate both the LHS and the RHS of an=20
> assignment first. So values must necessarily come into conflict, and=20
> battles over values are political, personal, and frequently nasty. =20
> Besides, what constitutes a technical argument? I say that Java has stri=
ct=20
> left-to-right evaluation, and I find that to be a technical argument -=20
> clearly the Java designers made this a conscious choice. But others=20
> dismiss this with "why would we want C++ to be like Java?" Or conversely=
,=20
> people claim to find that some code can run 4% faster when order is not=
=20
> specified, and I say that I don't care.
>
> Some of your points are plainly technically incorrect, despite of what=20
values you want to achieve. For example, the language (not only C++) is=20
certainly allowed with both specified and unspecified evaluation order on=
=20
expressions, just in different cases with different grammars. You are=20
actually not only insisting on evaluation order; you also don't want any=20
conforming extensions, just because you think that is right. This point is=
=20
what I mostly against to.
Further, you said you had found that designers of Java made the choice you=
=20
want, but you seem to deliberately ignore the related notes in Java=20
Language Specification (as I mentioned more than once), which tells you=20
that the designers of Java do not like the idea about relying on such=20
rules. This clearly contradicts your belief. Why you adopt the point=20
selectively?
=20
> Ultimately, my goal is to not be silent, so that when C++ goes the wrong=
=20
> (IMO) way, no one can say that this was done with the acquiescence of the=
=20
> entire C++ community.
>
> And for your amusement, or horror:
> struct A { }; A f(); A g();
> void operator<<(A, A);
> auto shfpointer =3D (void(*)(A, A))&operator<<;
> operator<<(f(), g()); // must evaluate f() then g()
> shfpointer(f(), g()); // can evaluate f() and g() in either order
>
I personally don't write or want to review such code. If that code is=20
really seriously written, it is a signal to either 1) it is a bug on coding=
=20
convention, or; 2) someone should be responsive to guarantee he/she know=20
how the code works (with some comments not presented here), and why to=20
write code in such style.
=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/3a4ad9c0-6334-4eeb-a2e4-eec9871a2a26%40isocpp.or=
g.
------=_Part_74_1279332464.1468463423739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=881:47:45=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Tue, Jul 12, 2016 at 1:12 PM,=
'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"AlKOpIm2CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">std-pr...@isocpp.org</a>></span> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div>Please look at the technical arguments instead of calling pe=
ople who disagree with you "irrational".</div></div></blockquote>=
<div><br></div><div>It's not a matter of technical arguments, it's =
a matter of values (as you say).=C2=A0 Science can tell you how to accompli=
sh what you want, but it can't tell you what to want.=C2=A0 For me, the=
values involved in having a programming language that is simply specified =
and deterministic and consistent far outweigh the possible optimization ben=
efit in letting the compiler pick evaluation order.=C2=A0 SImilarly, I find=
negative value in having unspecified behavior in order to force programmer=
s to be hyper-vigilant to avoid error.=C2=A0 I find negative value in the n=
otion that unspecified order adds expressiveness.<br><br></div></div></div>=
</div></blockquote><div>It is true that matters of values are involved, but=
things are not as simple as you thought, in reality.<br>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>C++ can do only one thing.=C2=A0 It cannot have evalu=
ation order both specified and unspecified.=C2=A0 It cannot evaluate both t=
he LHS and the RHS of an assignment first.=C2=A0 So values must necessarily=
come into conflict, and battles over values are political, personal, and f=
requently nasty.=C2=A0 Besides, what constitutes a technical argument?=C2=
=A0 I say that Java has strict left-to-right evaluation, and I find that to=
be a technical argument - clearly the Java designers made this a conscious=
choice.=C2=A0 But others dismiss this with "why would we want C++ to =
be like Java?" =C2=A0Or conversely, people claim to find that some cod=
e can run 4% faster when order is not specified, and I say that I don't=
care.<br><br></div></div></div></div></blockquote><div>Some of your points=
are plainly technically incorrect, despite of what values you want to achi=
eve. For example, the language (not only C++) is certainly allowed with bot=
h specified and unspecified evaluation order on expressions, just in differ=
ent cases with different grammars. You are actually not only insisting on e=
valuation order; you also don't want any conforming extensions, just be=
cause you think that is right. This point is what I mostly against to.<br><=
br>Further, you said you had found that designers of Java made the choice y=
ou want, but you seem to deliberately ignore the related notes in Java Lang=
uage Specification (as I mentioned more than once), which tells you that th=
e designers of Java do not like the idea about relying on such rules. This =
clearly contradicts your belief. Why you adopt the point selectively?<br><b=
r>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div>Ultimately, my goal is to not be =
silent, so that when C++ goes the wrong (IMO) way, no one can say that this=
was done with the acquiescence of the entire C++ community.<br><br>And for=
your amusement, or horror:<font face=3D"monospace, monospace"><br>=C2=A0 =
=C2=A0 struct A { };=C2=A0A f();=C2=A0A g();<br>=C2=A0 =C2=A0 void operator=
<<(A, A);<br>=C2=A0 =C2=A0 auto=C2=A0</font><span style=3D"font-famil=
y:monospace,monospace">shfpointer</span><font face=3D"monospace, monospace"=
>=C2=A0=3D (void(*)(A, A))&operator<<;<br>=C2=A0 =C2=A0 operator&=
lt;<(f(), g()); =C2=A0// must evaluate f() then g()<br>=C2=A0 =C2=A0=C2=
=A0</font><span style=3D"font-family:monospace,monospace">shfpointer</span>=
<font face=3D"monospace, monospace">(f(), g()); =C2=A0// can evaluate f() a=
nd g() in either order</font></div></div></div></div></blockquote><div>I pe=
rsonally don't write or want to review such code. If that code is reall=
y seriously written, it is a signal to either 1) it is a bug on coding conv=
ention, or; 2) someone should be responsive to guarantee he/she know how th=
e code works (with some comments not presented here), and why to write code=
in such style.<br>=C2=A0<br></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/3a4ad9c0-6334-4eeb-a2e4-eec9871a2a26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a4ad9c0-6334-4eeb-a2e4-eec9871a2a26=
%40isocpp.org</a>.<br />
------=_Part_74_1279332464.1468463423739--
------=_Part_73_1216271156.1468463423739--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 19:42:44 -0700 (PDT)
Raw View
------=_Part_81_691181497.1468464164944
Content-Type: multipart/alternative;
boundary="----=_Part_82_411425512.1468464164945"
------=_Part_82_411425512.1468464164945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=883:05:37=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Standard -=20
> Future Proposals:
>
> And there is nothing in your problem specification to say that the insert=
s=20
> should happen in any particular order.
>
> I shouldn't have to look up the specification to know what the code is=20
> supposed to do. This is about expectations. You with thousands of hours o=
f=20
> experience in C++ realized that the order is unspecified. Other people wi=
th=20
> thousands of hours of experience in C++ do not. What matters is what the=
=20
> intention of the author was and whether it matches what we read into it.=
=20
> Whichever the intention was it's obviously not expressed unambiguously. A=
s=20
> long as the code makes the author's intentions ambiguous it is not a win=
=20
> for code clarity.
>
Normally you should not have to look up the specification, because they=20
should be remembered before you see the code, if you are serious. I can't=
=20
imagine a people who don't know the domain knowledge enough (which makes=20
he/she can look up/write/recite the specification once needed in time) will=
=20
produce anything reliable. And I am shocked that one should have thousands=
=20
of hours of experience in C++ to do such things right. Why should I expect=
=20
that is the "right" case? I only uses a few hours to avoid such problems=20
(though reading the specification of C++ takes me more time - however,=20
changes of the standard even make it longer), just by avoiding such smelly=
=20
code that I can not easily figure out what it will do. Again, if (just)=20
*you* don't want to see some features in code out of your control, set the=
=20
coding convention, which is out of the scope of the language specification.
=20
>
> And there is nothing in your problem specification to say that the insert=
s=20
> should happen in any particular order.=20
> =20
>
>> What is the "more correct" alternative? Show me how to write that same=
=20
>> code in a way that is as clear and *concise* as this, which doesn't=20
>> provoke undefined behavior.
>>
>
> auto inserts =3D {v.insert(v.end(), args)...};
>
> That makes it an initializer_list, meaning the values are const, meaning=
=20
> you cannot move them out.
> Just saying.
>
> If you're writing already complicated expressions, why complicate them=20
> further by making them order-dependent?
>
> No system becomes more complicated or harder to understand by removing=20
> degrees of freedom.
>
>
--=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/66990214-d177-49d5-864f-e1c842e5cf01%40isocpp.or=
g.
------=_Part_82_411425512.1468464164945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=883:05:37=EF=BC=8CMiro Knejp=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Stan=
dard
- Future Proposals:<br>
<blockquote type=3D"cite">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.</blockquote>
I shouldn't have to look up the specification to know what the code
is supposed to do. This is about expectations. You with thousands of
hours of experience in C++ realized that the order is unspecified.
Other people with thousands of hours of experience in C++ do not.
What matters is what the intention of the author was and whether it
matches what we read into it. Whichever the intention was it's
obviously not expressed unambiguously. As long as the code makes the
author's intentions ambiguous it is not a win for code clarity.<br>=
</div></blockquote><div>Normally you should not have to look up the specifi=
cation, because they should be remembered before you see the code, if you a=
re serious. I can't imagine a people who don't know the domain know=
ledge enough (which makes he/she can look up/write/recite the specification=
once needed in time) will produce anything reliable. And I am shocked that=
one should have thousands of hours of experience in C++ to do such things =
right. Why should I expect that is the "right" case? I only uses =
a few hours to avoid such problems (though reading the specification of C++=
takes me more time - however, changes of the standard even make it longer)=
, just by avoiding such smelly code that I can not easily figure out what i=
t will do. Again, if (just) <i>you</i> don't want to see some features =
in code out of your control, set the coding convention, which is out of the=
scope of the language specification.<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">And there is nothing in your problem
specification to say that the inserts should happen in any
particular order.
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div dir=3D"ltr">
<div>What is the "more correct" alternative? Show=
me how
to write that same code in a way that is as clear and
<i>concise</i> as this, which doesn't provoke
undefined behavior.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>auto inserts =3D {v.insert(v.end(), args)...};</div>
</div>
</div>
</div>
</blockquote>
That makes it an initializer_list, meaning the values are const,
meaning you cannot move them out.<br>
Just saying.<br>
<br>
<blockquote type=3D"cite">If you're writing already complicated
expressions, why complicate them further by making them
order-dependent?</blockquote>
No system becomes more complicated or harder to understand by
removing degrees of freedom.<br>
<br>
</div>
</blockquote></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/66990214-d177-49d5-864f-e1c842e5cf01%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/66990214-d177-49d5-864f-e1c842e5cf01=
%40isocpp.org</a>.<br />
------=_Part_82_411425512.1468464164945--
------=_Part_81_691181497.1468464164944--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 20:02:32 -0700 (PDT)
Raw View
------=_Part_86_1389202925.1468465352686
Content-Type: multipart/alternative;
boundary="----=_Part_87_847097565.1468465352686"
------=_Part_87_847097565.1468465352686
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=883:20:01=EF=BC=8CMiro Knejp=E5=86=99=E9=81=93=EF=BC=9A
>
> Am 12.07.2016 um 19:03 schrieb Ren Industries:=20
> > The fact you continually assert this without evidence as if it is fact=
=20
> > is what truly "beggars belief".=20
> People also constantly assert without evidence that this is somehow=20
> "removing expresiveness" from the language. I have asked in the past and=
=20
> now again for code examples that clearly, without doubt, expresses that=
=20
> the author's intention was *deliberately* for code to be=20
> order-independent and not just a lucky side effect of how the language=20
> works. And by example I do not mean "I just wrote an expression and it=20
> happens to not depend on order of evaluation". No, I mean "I wrote this=
=20
> expression and I *intentionally* require it to be order independent=20
> because the future of the universe depends on it". =20
>
>=20
> > It is currently trivial to force a left to right ordering; simply make=
=20
> > each substatement its own statement, in the order you like. There is=20
> > no syntax to enforce "unordered" ordering. No one is forcing you to=20
> > nest statements; you can easily ensure your own ordering by using the=
=20
> > current syntax.=20
> >=20
> > The notion that removing expressiveness from a language is a benefit=20
> > is wrong, no matter how hard you believe otherwise...is equally valid=
=20
> > a statement, in that it asserts something with no actual evidence, and=
=20
> > may therefore be dismissed with no evidence as well.=20
> How many people use this expressiveness to express their intention in=20
> such a way that every reader of the code unambiguously understands their=
=20
> intention?=20
>
> Why is it relevant? Whether it is used, the differences on semantics are=
=20
there, before you deliberately *ignore *it, to treat different semantics=20
properties reflecting the same *meaning *of program you want. But the=20
language specification has no way to specify the latter. It totally depends=
..
Or do you really believe there can only be one evaluation order in the=20
world, or users of C++ should not touch any one of them other than=20
left-to-right order? I don't think it is in the scope of the language=20
specification.
=20
> Fact is human brains are very bad at doing (or imagining) multiple=20
> things happening at the same time which is why multithreading is such a=
=20
> hard problem. It is easier to go through something step by step than=20
> jumping around wildly or even doing things in parallel. Having a fixed=20
> order makes it easier to understand the solution because we can begin at=
=20
> one determined side of the expression and go through it one step at a=20
> time.=20
>
That's wrong. It may be true that imagining by naive emulation of discrete=
=20
processors in one's brain is difficult and error-prone. But you have not to=
=20
do. There is more effective abstraction to deal with such problems in=20
reality for each particular kind of problems, which is we really need to=20
solve.
It is wrong that only step-by-step imperative execution can be a feasible=
=20
(or to be the most suitable) abstraction to solve real problems. To make=20
you believe in this may be a significant failure of education (at least for=
=20
computer science subjects). I don't think yielding to such failure is a=20
appropriate choice here.
--=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/6e934d59-1e23-4a58-b24d-76f309f687b5%40isocpp.or=
g.
------=_Part_87_847097565.1468465352686
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=883:20:01=EF=BC=8CMiro Knejp=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Am 12.=
07.2016 um 19:03 schrieb Ren Industries:
<br>> The fact you continually assert this without evidence as if it is =
fact=20
<br>> is what truly "beggars belief".
<br>People also constantly assert without evidence that this is somehow=20
<br>"removing expresiveness" from the language. I have asked in t=
he past and=20
<br>now again for code examples that clearly, without doubt, expresses that=
=20
<br>the author's intention was *deliberately* for code to be=20
<br>order-independent and not just a lucky side effect of how the language=
=20
<br>works. And by example I do not mean "I just wrote an expression an=
d it=20
<br>happens to not depend on order of evaluation". No, I mean "I =
wrote this=20
<br>expression and I *intentionally* require it to be order independent=20
<br>because the future of the universe depends on it".=C2=A0
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>> It is currently trivial to force a left to right ordering; simply =
make=20
<br>> each substatement its own statement, in the order you like. There =
is=20
<br>> no syntax to enforce "unordered" ordering. No one is for=
cing you to=20
<br>> nest statements; you can easily ensure your own ordering by using =
the=20
<br>> current syntax.
<br>>
<br>> The notion that removing expressiveness from a language is a benef=
it=20
<br>> is wrong, no matter how hard you believe otherwise...is equally va=
lid=20
<br>> a statement, in that it asserts something with no actual evidence,=
and=20
<br>> may therefore be dismissed with no evidence as well.
<br>How many people use this expressiveness to express their intention in=
=20
<br>such a way that every reader of the code unambiguously understands thei=
r=20
<br>intention?
<br>
<br></blockquote><div>Why is it relevant? Whether it is used, the differenc=
es on semantics are there, before you deliberately <i>ignore </i>it, to tre=
at different semantics properties reflecting the same <i>meaning </i>of pro=
gram you want. But the language specification has no way to specify the lat=
ter. It totally depends.<br>Or do you really believe there can only be one =
evaluation order in the world, or users of C++ should not touch any one of =
them other than left-to-right order? I don't think it is in the scope o=
f the language specification.<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">Fact is human brains are very bad at doing (or imagining=
) multiple=20
<br>things happening at the same time which is why multithreading is such a=
=20
<br>hard problem. It is easier to go through something step by step than=20
<br>jumping around wildly or even doing things in parallel. Having a fixed=
=20
<br>order makes it easier to understand the solution because we can begin a=
t=20
<br>one determined side of the expression and go through it one step at a t=
ime.
<br></blockquote><div>That's wrong. It may be true that imagining by na=
ive emulation of discrete processors in one's brain is difficult and er=
ror-prone. But you have not to do. There is more effective abstraction to d=
eal with such problems in reality for each particular kind of problems, whi=
ch is we really need to solve.<br>It is wrong that only step-by-step impera=
tive execution can be a feasible (or to be the most suitable) abstraction t=
o solve real problems. To make you believe in this may be a significant fai=
lure of education (at least for computer science subjects). I don't thi=
nk yielding to such failure is a appropriate choice here.<br><br><br></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/6e934d59-1e23-4a58-b24d-76f309f687b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6e934d59-1e23-4a58-b24d-76f309f687b5=
%40isocpp.org</a>.<br />
------=_Part_87_847097565.1468465352686--
------=_Part_86_1389202925.1468465352686--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 20:14:34 -0700 (PDT)
Raw View
------=_Part_84_2111144511.1468466074259
Content-Type: multipart/alternative;
boundary="----=_Part_85_1378327719.1468466074260"
------=_Part_85_1378327719.1468466074260
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=884:31:31=EF=BC=8CRen Industries=E5=86=99=E9=81=93=EF=BC=
=9A
>
> This applies equally well to right-to-left order (which is currently=20
> Clang's ordering, I believe). It in no way proves that left-to-right is=
=20
> somehow the *only* correct way.
>
> I remember Clang used left-to-right by default. GCC (before some new -f=
=20
options introduced in current trunk) used right-to-left.
=20
> On Tue, Jul 12, 2016 at 4:28 PM, Hyman Rosen <hyman...@gmail.com=20
> <javascript:>> wrote:
>
>> On Tue, Jul 12, 2016 at 4:10 PM, Nevin Liber <ne...@eviloverlord.com=20
>> <javascript:>> wrote:
>>>
>>> Take the expression int a =3D b() + c() + d();
>>>
>>> Where b(), c() and d() return ints. When I see an expression like that=
,=20
>>> I *as the reader* expect it to be both commutative and associative. =20
>>> And in C++ today, it would be buggy code if the result were dependent o=
n=20
>>> the order of evaluation. I could, for instance, rewrite it as:
>>>
>>> int e =3D c() + d()
>>> int a =3D b() + e;
>>>
>>> If the evaluation order is defined, I *as a code maintainer* can no=20
>>> longer do this transformation without looking at b(), c(), d() to make =
sure=20
>>> they are completely independent, because it is impossible to tell just =
from=20
>>> the original expression if is dependent on the order of evaluation or n=
ot. =20
>>> In the evaluation order dependent world, this refactoring is fragile an=
d=20
>>> may break code.
>>>
>>
>> In C++ today this code is not associative. For example, even if all=20
>> functions return int values, if b() returns 1, c() returns -1, and d()=
=20
>> returns INT_MIN, reordering the computations (at the source level) to=20
>> add c() and d() before adding b() would result in undefined behavior. =
=20
>> If the functions return float values, reordering can lead to utterly=20
>> wrong results.
>>
>> Your incorrect intuition about how to rewrite this code could lead you t=
o=20
>> insert undefined behavior into the program. That's not surprising;=20
>> programmers have been led astray by incorrect beliefs about order of=20
>> evaluation for literally decades. That's why strict left-to-right order=
is=20
>> the only correct way to fix things. One simple rule that's trivial to=
=20
>> learn and impossible to forget.
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbttJ=
cPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbtt=
JcPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
>
--=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/a00f4a78-2cf5-431b-9394-98da07c03eb2%40isocpp.or=
g.
------=_Part_85_1378327719.1468466074260
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:31:31=EF=BC=8CRen Industries=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">This applies equally well to right-to-left order (which is cu=
rrently Clang's ordering, I believe). It in no way proves that left-to-=
right is somehow the <i>only</i>=C2=A0correct way.</div><div><br></div></bl=
ockquote><div>I remember Clang used left-to-right by default. GCC (before s=
ome new -f options introduced in current trunk) used right-to-left.<br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=
=3D"gmail_quote">On Tue, Jul 12, 2016 at 4:28 PM, Hyman Rosen <span dir=3D"=
ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"SFScYnm_CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">hyman...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span>On Tue, Jul 12, =
2016 at 4:10 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"SFScYnm_CgAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">ne...@eviloverlord.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div>Take the expression int a =3D b() + c() + d();<br>=
</div><div><br></div><div>Where b(), c() and d() return ints.=C2=A0 When I =
see an expression like that, I <i>as the reader</i> expect it to be both co=
mmutative and associative.=C2=A0 And in C++ today, it would be buggy code i=
f the result were dependent on the order of evaluation.=C2=A0 I could, for =
instance, rewrite it as:</div><div><br></div><div>int e =3D c() + d()</div>=
<div>int a =3D b() + e;</div><div><br></div><div>If the evaluation order is=
defined, I <i>as a code maintainer</i> can no longer do this transformatio=
n without looking at b(), c(), d() to make sure they are completely indepen=
dent, because it is impossible to tell just from the original expression if=
is dependent on the order of evaluation or not.=C2=A0 In the evaluation or=
der dependent world, this refactoring is fragile and may break code.</div><=
/div></div></div></blockquote></span><div><br>In C++ today this code is not=
associative.=C2=A0 For example, even if all functions return <font face=3D=
"monospace, monospace">int</font> values, if <font face=3D"monospace, monos=
pace">b()</font> returns <font face=3D"monospace, monospace">1</font>, <fon=
t face=3D"monospace, monospace">c()</font> returns <font face=3D"monospace,=
monospace">-1</font>, and <font face=3D"monospace, monospace">d()</font> r=
eturns <font face=3D"monospace, monospace">INT_MIN</font>, reordering the c=
omputations (at the source level) to add <font face=3D"monospace, monospace=
">c()</font> and <font face=3D"monospace, monospace">d()</font> before addi=
ng <font face=3D"monospace, monospace">b()</font> would result in undefined=
behavior.=C2=A0 If the functions return <font face=3D"monospace, monospace=
">float</font> values, reordering can lead to utterly wrong results.<br><br=
>Your incorrect intuition about how to rewrite this code could lead you to =
insert undefined behavior into the program.=C2=A0 That's not surprising=
; programmers have been led astray by incorrect beliefs about order of eval=
uation for literally decades.=C2=A0 That's why strict left-to-right ord=
er is the only correct way to fix things.=C2=A0 One simple rule that's =
trivial to learn and impossible to forget.</div></div></div></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
SFScYnm_CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"SFScYnm_CgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJ=
BNqtaD7zFRKBNQOahg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbttJcPLe%2=
BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter';return true;" onclick=3D"this.href=3D'htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbttJcPLe%2=
BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter';return true;">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/CAHSYqdbttJcPLe%<wbr>2BS5AaOhmA0WKj=
6Y8%<wbr>2BJBNqtaD7zFRKBNQOahg%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></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/a00f4a78-2cf5-431b-9394-98da07c03eb2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a00f4a78-2cf5-431b-9394-98da07c03eb2=
%40isocpp.org</a>.<br />
------=_Part_85_1378327719.1468466074260--
------=_Part_84_2111144511.1468466074259--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 20:28:55 -0700 (PDT)
Raw View
------=_Part_80_789868675.1468466935760
Content-Type: multipart/alternative;
boundary="----=_Part_81_625869558.1468466935760"
------=_Part_81_625869558.1468466935760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=884:35:40=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, Jul 12, 2016 at 4:31 PM, Ren Industries <renind...@gmail.com=20
> <javascript:>> wrote:
>
>> This applies equally well to right-to-left order (which is currently=20
>> Clang's ordering, I believe). It in no way proves that left-to-right is=
=20
>> somehow the *only* correct way.
>>
>
> Having more than one way is wrong. C++ is written and read from left to=
=20
> right. Evaluation should mirror that. (I believe that g++ does=20
> right-to-left for function arguments and clang does them left-to-right.)
>
No. It depends on how many cases you should deal with.
You effectively make things more complicated.
Old ways, for both code writers and readers:
- Leave it unseqenced, if intended.
- Make it seqenced, either explicit left-to-right, explicit=20
right-to-left or indeterminately sequenced, if intended.
- Otherwise, the semantics does not reflect the intention, so there are=
=20
bugs.
=20
Your ways, for writers:
- Leave it left-to-right, if intended.
- Leave it left-to-right, just be ignorant.
- Use some complicated tricks to eliminate the need of other sequenced=
=20
evaluation.
- Use some extensions (not guaranteed to be portable) to allow=20
unsequenced evaluation.
- Other buggy intention.
Your ways, for readers:
- Assume left-to-right is intended.
- Assume left-to-right just works, but not intended and potentially=20
buggy.
- See extensions and must figure out what it is and if the cost of=20
decreasing portability is acceptable.
- Otherwise, the semantics does not reflect the intention, so there are=
=20
bugs.
--=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/1ca2c822-8102-4db4-a929-7fc2222aa933%40isocpp.or=
g.
------=_Part_81_625869558.1468466935760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:35:40=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Tue, Jul 12, 2016 at 4:31 PM,=
Ren Industries <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"SDiehrO_CgAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">renind...@gmail.com</a>></span> wrote:<=
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">This applies equally wel=
l to right-to-left order (which is currently Clang's ordering, I believ=
e). It in no way proves that left-to-right is somehow the <i>only</i>=C2=A0=
correct way.</div></blockquote><div><br></div><div>Having more than one way=
is wrong.=C2=A0 C++ is written and read from left to right.=C2=A0 Evaluati=
on should mirror that. =C2=A0(I believe that g++ does right-to-left for fun=
ction arguments and clang does them left-to-right.)</div></div></div></div>=
</blockquote><div><br>No. It depends on how many cases you should deal with=
..<br><br>You effectively make things more complicated.<br><br>Old ways, for=
both code writers and readers:<br><ul><li>Leave it unseqenced, if intended=
..</li><li>Make it seqenced, either explicit left-to-right, explicit right-t=
o-left or indeterminately sequenced, if intended.</li><li>Otherwise, the se=
mantics does not reflect the intention, so there are bugs.<br></li></ul>You=
r ways, for writers:<br><ul><li>Leave it left-to-right, if intended.</li><l=
i>Leave it left-to-right, just be ignorant.</li><li>Use some complicated tr=
icks to eliminate the need of other sequenced evaluation.<br></li><li>Use s=
ome extensions (not guaranteed to be portable) to allow unsequenced evaluat=
ion.<br></li><li>Other buggy intention.</li></ul>Your ways, for readers:<br=
><ul><li>Assume left-to-right is intended.</li><li>Assume left-to-right jus=
t works, but not intended and potentially buggy.</li><li>See extensions and=
must figure out what it is and if the cost of decreasing portability is ac=
ceptable.<br></li><li>Otherwise, the semantics does not reflect the intenti=
on, so there are bugs.</li></ul><br><br><br></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/1ca2c822-8102-4db4-a929-7fc2222aa933%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ca2c822-8102-4db4-a929-7fc2222aa933=
%40isocpp.org</a>.<br />
------=_Part_81_625869558.1468466935760--
------=_Part_80_789868675.1468466935760--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 20:31:30 -0700 (PDT)
Raw View
------=_Part_12_2065327972.1468467090907
Content-Type: multipart/alternative;
boundary="----=_Part_13_205327180.1468467090908"
------=_Part_13_205327180.1468467090908
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=884:37:53=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, Jul 12, 2016 at 4:32 PM, 'Jeffrey Yasskin' via ISO C++ Standard -=
=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>
>> I do think it's on the table to make the sequencing stricter for C++20,=
=20
>> once folks have had time to investigate more of the implications. The=20
>> change for C++17 was just cautious.
>>
>
> The problem is that the ordering for assignment, once specified as=20
> right-to-left in C++17, can never be fixed. That's heinous.
>
For assignments this was actually specified long ago. See CWG 222 and CWG=
=20
637. There may be more subtle risks to change.
--=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/b716daa8-b12b-4fd7-9bd9-ab185238e697%40isocpp.or=
g.
------=_Part_13_205327180.1468467090908
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:37:53=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Tue, Jul 12, 2016 at 4:32 PM,=
'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"RATCe9K_CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">std-pr...@isocpp.org</a>></span> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>I do think it's on the table to make the s=
equencing stricter for C++20, once folks have had time to investigate more =
of the implications. The change for C++17 was just cautious.</div></div></b=
lockquote><div><br>The problem is that the ordering for assignment, once sp=
ecified as right-to-left in C++17, can never be fixed.=C2=A0 That's hei=
nous.</div></div></div></div></blockquote><div><br>For assignments this was=
actually specified long ago. See CWG 222 and CWG 637. There may be more su=
btle risks to change.<br><br></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/b716daa8-b12b-4fd7-9bd9-ab185238e697%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b716daa8-b12b-4fd7-9bd9-ab185238e697=
%40isocpp.org</a>.<br />
------=_Part_13_205327180.1468467090908--
------=_Part_12_2065327972.1468467090907--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 20:40:51 -0700 (PDT)
Raw View
------=_Part_22_1334151620.1468467651997
Content-Type: multipart/alternative;
boundary="----=_Part_23_862658309.1468467651997"
------=_Part_23_862658309.1468467651997
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=884:39:01=EF=BC=8CNevin ":-)" Liber=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 12 July 2016 at 15:28, Hyman Rosen <hyman...@gmail.com <javascript:>>=
=20
> wrote:
>
>> In C++ today this code is not associative. For example, even if all=20
>> functions return int values, if b() returns 1, c() returns -1, and d()=
=20
>> returns INT_MIN, reordering the computations (at the source level) to=20
>> add c() and d() before adding b() would result in undefined behavior. =
=20
>> If the functions return float values, reordering can lead to utterly=20
>> wrong results.
>>
>
> In other words, when you write code that doesn't obey the rules of=20
> commutativity and associativity, you make it harder for humans to=20
> understand. Great point!
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>=20
> +1-847-691-1404
>
This is not the root reason. If you write only so-called "pure" evaluation=
=20
of expressions, there are no such problems. Once you are relying on side=20
effects, you should care both of evaluation order and times. And=20
commutativity or associativity does not always make sense to arbitrary=20
expressions. You still need to care which expressions have those=20
properties, anyway.
=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/ee2118dc-ae3f-409e-83c9-aaa78d91e9ee%40isocpp.or=
g.
------=_Part_23_862658309.1468467651997
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:39:01=EF=BC=8CNevin ":-=
)" Liber=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">On 12 July 2016 at 15:28, Hyman Rosen <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"4MqiM-K_CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">hyman...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div>In C++ today this code is not associative.=C2=A0 For exa=
mple, even if all functions return <font face=3D"monospace, monospace">int<=
/font> values, if <font face=3D"monospace, monospace">b()</font> returns <f=
ont face=3D"monospace, monospace">1</font>, <font face=3D"monospace, monosp=
ace">c()</font> returns <font face=3D"monospace, monospace">-1</font>, and =
<font face=3D"monospace, monospace">d()</font> returns <font face=3D"monosp=
ace, monospace">INT_MIN</font>, reordering the computations (at the source =
level) to add <font face=3D"monospace, monospace">c()</font> and <font face=
=3D"monospace, monospace">d()</font> before adding <font face=3D"monospace,=
monospace">b()</font> would result in undefined behavior.=C2=A0 If the fun=
ctions return <font face=3D"monospace, monospace">float</font> values, reor=
dering can lead to utterly wrong results.<br></div></div></div></div></bloc=
kquote><div><br></div><div>In other words, when you write code that doesn&#=
39;t obey the rules of commutativity and associativity, you make it harder =
for humans to understand.=C2=A0 Great point!</div></div>-- <br><div><div di=
r=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"4MqiM-K_CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">ne...@eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div></=
div></div></div></div></div></div></blockquote><div><br>This is not the roo=
t reason. If you write only so-called "pure" evaluation of expres=
sions, there are no such problems. Once you are relying on side effects, yo=
u should care both of evaluation order and times. And commutativity or asso=
ciativity does not always make sense to arbitrary expressions. You still ne=
ed to care which expressions have those properties, anyway.<br><br>=C2=A0<b=
r></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/ee2118dc-ae3f-409e-83c9-aaa78d91e9ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee2118dc-ae3f-409e-83c9-aaa78d91e9ee=
%40isocpp.org</a>.<br />
------=_Part_23_862658309.1468467651997--
------=_Part_22_1334151620.1468467651997--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 20:53:01 -0700 (PDT)
Raw View
------=_Part_79_624614616.1468468381472
Content-Type: multipart/alternative;
boundary="----=_Part_80_1882818648.1468468381472"
------=_Part_80_1882818648.1468468381472
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=884:52:25=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>> wrote:
>>
>> In other words, when you write code that doesn't obey the rules of=20
>> commutativity and associativity, you make it harder for humans to=20
>> understand. Great point!
>>
>
> When you apply the incorrect mental model to a programming language, you=
=20
> will fail to understand the program. When you apply transformations to a=
=20
> program while failing to understand it, you will break it. When you brea=
k=20
> the program and it fails, the excuse that the program failed to fit your=
=20
> model is not going to make the program work again.
>
> Programming is already hard enough without deliberately throwing=20
> unspecified behavior into the mix.
>
Understanding a program is not understanding the exhaustive behavior on=20
each implementation. That methodology simply does work in reality because=
=20
there are almost always variety input and internal state you can't=20
determine and control, plus you may have buggy underlying implementations=
=20
.... so you will eventually fail to predicate the precise behavior on any=20
program. And that is also an incorrect mental model for any practical=20
programming language.
I doubt the difficulties you met are mostly because you have too much=20
assumption that you don't need actually, not leaving unspecified behavior=
=20
alone. It things need not to be specified are accidentally relied on=20
without cautious, you are likely to have new troubles sooner or later.
--=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/407d82f3-126e-422c-ab6d-a1fda21f28cb%40isocpp.or=
g.
------=_Part_80_1882818648.1468468381472
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:52:25=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Tue, Jul 12, 2016 at 4:38 PM,=
Nevin Liber <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"IaYLhp3ACgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">ne...@eviloverlord.com</a>></span> wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te"><div>In other words, when you write code that doesn't obey the rule=
s of commutativity and associativity, you make it harder for humans to unde=
rstand.=C2=A0 Great point!</div></div></div></div></blockquote><div><br>Whe=
n you apply the incorrect mental model to a programming language, you will =
fail to understand the program.=C2=A0 When you apply transformations to a p=
rogram while failing to understand it, you will break it.=C2=A0 When you br=
eak the program and it fails, the excuse that the program failed to fit you=
r model is not going to make the program work again.<br><br>Programming is =
already hard enough without deliberately throwing unspecified behavior into=
the mix.</div></div></div></div></blockquote><div><br>Understanding a prog=
ram is not understanding the exhaustive behavior on each implementation. Th=
at methodology simply does work in reality because there are almost always =
variety input and internal state you can't determine and control, plus =
you may have buggy underlying implementations ... so you will eventually fa=
il to predicate the precise behavior on any program. And that is also an in=
correct mental model for any practical programming language.<br><br>I doubt=
the difficulties you met are mostly because you have too much assumption t=
hat you don't need actually, not leaving unspecified behavior alone. It=
things need not to be specified are accidentally relied on without cautiou=
s, you are likely to have new troubles sooner or later.<br><br><br></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/407d82f3-126e-422c-ab6d-a1fda21f28cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/407d82f3-126e-422c-ab6d-a1fda21f28cb=
%40isocpp.org</a>.<br />
------=_Part_80_1882818648.1468468381472--
------=_Part_79_624614616.1468468381472--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 21:02:26 -0700 (PDT)
Raw View
------=_Part_93_816528214.1468468946149
Content-Type: multipart/alternative;
boundary="----=_Part_94_1689757523.1468468946150"
------=_Part_94_1689757523.1468468946150
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=885:09:47=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, Jul 12, 2016 at 4:45 PM, Patrice Roy <patr...@gmail.com=20
> <javascript:>> wrote:
>
>> I've made this comment in the past, and did not expect the discussion to=
=20
>> come back two weeks after we voted on the issue, but as a complement to=
=20
>> Nevin's comment, I'm glad, from a code review perpsective, that code=20
>> written as x =3D h(f(),g()); where there are side-effects to f() and g()=
can=20
>> be considered as something that's buggy and requires rewriting, not as=
=20
>> something potentially correct and that needs to be investigated.
>>
>
> In a language with a properly defined evaluation order, the following cod=
e=20
> works as obviously as it reads.
> template <typename T> T get(istream &in) { T t; in >> t; return t; }
> auto point =3D make_pair(get<int>(cin), get<int>(cin));
>
> It's the way the code works in C++ today if I write
> int xy[2] =3D { get<int>(cin), get<int>(cin) };
> so the language is inconsistent with itself with respect to when it=20
> defines order and when it doesn't.
>
> I've said it before - C and C++ programmers have developed Stockholm=20
> Syndrome with respect to evaluation order. The rules have been wrong for=
=20
> so long that programmers have come to believe that this is the way they=
=20
> must be, and then accuse reasonable-looking code of being broken, stupid,=
=20
> error-prone, and lazy when it's really the language that's that way.
>
This only your personal belief, with something technically unsound. As I've=
=20
said before, the facts are:
- Evaluation order is not subjective to only C and C++.
- Unspecified evaluation order is not patented by C-like languages.
- Evaluation order has nothing to with parsing/lexical order because=20
they are unrelated processes in general. Your brain combines those stage=
s=20
does not mean this is the only one "correct" or most proper implementati=
on=20
in any case.
- Left-to-right is not the "correct" order in nature. It only occurred=
=20
to be "correct" only when you forced the rules with some assumptions whi=
ch=20
are not always existed or acceptable.
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d2a6045a-131b-404b-9c53-cfa081bfe40f%40isocpp.or=
g.
------=_Part_94_1689757523.1468468946150
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=885:09:47=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Tue, Jul 12, 2016 at 4:45 PM,=
Patrice Roy <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"zcJCCpDBCgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">patr...@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I've made this =
comment in the past, and did not expect the=20
discussion to come back two weeks after we voted on the issue, but as a=20
complement to Nevin's comment, I'm glad, from a code review perpsec=
tive,
that code written as x =3D h(f(),g()); where there are side-effects to=20
f() and g() can be considered as something that's buggy and requires=20
rewriting, not as something potentially correct and that needs to be=20
investigated.</div></div></div></blockquote><div><br>In a language with a p=
roperly defined evaluation order, the following code works as obviously as =
it reads.<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template <=
;typename T> T get(istream &in) { T t; in >> t; return t; }</f=
ont><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto point =3D ma=
ke_pair(get<int>(cin), get<int>(cin));</font><br><br><font face=
=3D"arial, helvetica, sans-serif">It's the way the code works in C++ to=
day if I write</font><br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
int xy[2] =3D { get<int>(cin), get<int>(cin) };</font></div><di=
v><font face=3D"arial, helvetica, sans-serif">so the language is inconsiste=
nt with itself with respect to when it defines order and when it doesn'=
t.<br><br>I've said it before - C and C++ programmers have developed St=
ockholm Syndrome with respect to evaluation order.=C2=A0 The rules have bee=
n wrong for so long that programmers have come to believe that this is the =
way they must be, and then accuse reasonable-looking code of being broken, =
stupid, error-prone, and lazy when it's really the language that's =
that way.</font></div></div></div></div></blockquote><div>This only your pe=
rsonal belief, with something technically unsound. As I've said before,=
the facts are:<br><ul><li>Evaluation order is not subjective to only C and=
C++.</li><li>Unspecified evaluation order is not patented by C-like langua=
ges.</li><li>Evaluation order has nothing to with parsing/lexical order bec=
ause they are unrelated processes in general. Your brain combines those sta=
ges does not mean this is the only one "correct" or most proper i=
mplementation in any case.<br></li><li>Left-to-right is not the "corre=
ct" order in nature. It only occurred to be "correct" only w=
hen you forced the rules with some assumptions which are not always existed=
or acceptable.<br></li></ul>=C2=A0<br></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/d2a6045a-131b-404b-9c53-cfa081bfe40f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2a6045a-131b-404b-9c53-cfa081bfe40f=
%40isocpp.org</a>.<br />
------=_Part_94_1689757523.1468468946150--
------=_Part_93_816528214.1468468946149--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 21:07:30 -0700 (PDT)
Raw View
------=_Part_86_1671549903.1468469250184
Content-Type: multipart/alternative;
boundary="----=_Part_87_1078318124.1468469250191"
------=_Part_87_1078318124.1468469250191
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=885:41:30=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, July 12, 2016 at 4:52:25 PM UTC-4, Hyman Rosen wrote:
>>
>> On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <ne...@eviloverlord.com>=20
>> wrote:
>>>
>>> In other words, when you write code that doesn't obey the rules of=20
>>> commutativity and associativity, you make it harder for humans to=20
>>> understand. Great point!
>>>
>>
>> When you apply the incorrect mental model to a programming language, you=
=20
>> will fail to understand the program.
>>
>
> People should not conform to their programming languages; programming=20
> languages should conform to people.
>
If people don't know enough to their languages, they have nothing to=20
conform.
And making a language to "conform people" is nonsense. Languages serve to=
=20
people's *need*, not *belief*. I am not convinced when people built their=
=20
need solely based on some value judgement without any other proof in fact.
=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/1dc49912-3d6d-408a-8261-038fa36c1928%40isocpp.or=
g.
------=_Part_87_1078318124.1468469250191
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=885:41:30=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<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">On Tuesday, July 12, 2016 at 4:52:25 PM UTC-4, Hyman Rosen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <span dir=3D"=
ltr"><<a rel=3D"nofollow">ne...@eviloverlord.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div>In other words, when you write code that doesn't obey the rules=
of commutativity and associativity, you make it harder for humans to under=
stand.=C2=A0 Great point!</div></div></div></div></blockquote><div><br>When=
you apply the incorrect mental model to a programming language, you will f=
ail to understand the program.</div></div></div></div></blockquote><div><br=
>People should not conform to their programming languages; programming lang=
uages should conform to people.</div></div></blockquote><div><br>If people =
don't know enough to their languages, they have nothing to conform.<br>=
<br>And making a language to "conform people" is nonsense. Langua=
ges serve to people's <i>need</i>, not <i>belief</i>. I am not convince=
d when people built their need solely based on some value judgement without=
any other proof in fact.<br><br>=C2=A0<br></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/1dc49912-3d6d-408a-8261-038fa36c1928%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1dc49912-3d6d-408a-8261-038fa36c1928=
%40isocpp.org</a>.<br />
------=_Part_87_1078318124.1468469250191--
------=_Part_86_1671549903.1468469250184--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 21:22:48 -0700 (PDT)
Raw View
------=_Part_93_2089995201.1468470168639
Content-Type: multipart/alternative;
boundary="----=_Part_94_1769714299.1468470168639"
------=_Part_94_1769714299.1468470168639
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8B=E5=8D=8811:51:29=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=9A
>
> Not to get everything off-topic; I know everything can be taught, as was=
=20
> pointed out to me on another occasion, but caring about the =C2=ABteachab=
ility=C2=BB=20
> of the language is not without interest. That being said, what is more=20
> =C2=ABteachable=C2=BB is highly subjective in some cases (this one includ=
ed, as both=20
> Hyman and myself care for it, but don't agree as to what is easier to=20
> explain in some aspects).
>
> At least to treat evaluation order same to some other mysterious order *i=
s=20
*destroying the teachability because in general they are unrelated things.=
=20
I don't think encouraging such illusion is a good result of teaching.
If someone insist on that should be the case of C++, I'm sorry to see that=
=20
C++ stands against to the majority of intellectuals and it will forces=20
learners to waste more time on such topics if they unfortunately touched=20
C++ at first. This result again conflicts to teachability.
=20
> That being said, instructor and teachers have a responsibility here, and=
=20
> the current rules can be taught (they have been for a while), just as new=
=20
> ones could. I think we should go for more objective arguments should this=
=20
> discussion continue. And I really would prefer to discuss over an actual=
=20
> proposal (it helps organize and focus discussions).
>
> Cheers!
>
> 2016-07-13 11:36 GMT-04:00 Ren Industries <renind...@gmail.com=20
> <javascript:>>:
>
>> Why would the simplicity of teaching anything matter more than anything=
=20
>> else? IEEE 754 is incredibly hard to teach, with many odd nuances to it,=
=20
>> yet it is used because those nuances lead to better results. Modeling af=
ter=20
>> the mathematical concepts underlying the operations may lead to more=20
>> difficult to teach, but also has clear benefits, as DV explained.=20
>>
>>
>> On Wed, Jul 13, 2016 at 11:14 AM, Hyman Rosen <hyman...@gmail.com=20
>> <javascript:>> wrote:
>>
>>> On Wed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <thi...@macieira.org=
=20
>>> <javascript:>> wrote:
>>>>
>>>> Note that this RTL for assignments was done like that to match the
>>>> associativity of the operator in question:
>>>
>>>
>>> But why? Associativity (and precedence) tell you how to fully=20
>>> parenthesize an expression. Why should that inform the order in which=
=20
>>> subexpressions are evaluated? If I begin with the fully parenthesized=
=20
>>> expressions a() =3D (b() =3D c()) and ((a() =3D b()) =3D c()) the first=
=20
>>> parenthesized as for right associativity and the second for left, the n=
ew=20
>>> standard requires that the order of evaluation for both is c(), b(), a(=
),=20
>>> so how does associativity even matter? And why should a() << b()=20
>>> require a different order than a() <<=3D b() while a() + b() remains=20
>>> unspecified? How does that help people to read and write C++?
>>>
>>> DV's explanation that intuition suggests that the RHS be evaluated firs=
t=20
>>> for assignments seems more reasonable, but I don't find it sufficiently=
=20
>>> compelling to overcome the simplicity of teaching that evaluation is=20
>>> left-to-right, always. Even if it runs counter to intuition, it's a=20
>>> mistake that you can only make once because when you learn the rule, it=
's=20
>>> so sharp and easy that you can't forget it.
>>> =20
>>>
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy=
4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQ=
y4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2=
RfUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO=
2RfUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>
>
--=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/5b323310-b056-4d5c-9658-54ae95e384c1%40isocpp.or=
g.
------=_Part_94_1769714299.1468470168639
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=8811:51:29=EF=BC=8CPatrice Roy=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>Not to get everything off-topic; I know everything can b=
e taught, as was pointed out to me on another occasion, but caring about th=
e =C2=ABteachability=C2=BB of the language is not without interest. That be=
ing said, what is more =C2=ABteachable=C2=BB is highly subjective in some c=
ases (this one included, as both Hyman and myself care for it, but don'=
t agree as to what is easier to explain in some aspects).<br><br></div></di=
v></blockquote><div>At least to treat evaluation order same to some other m=
ysterious order <i>is </i>destroying the teachability because in general th=
ey are unrelated things. I don't think encouraging such illusion is a g=
ood result of teaching.<br><br>If someone insist on that should be the case=
of C++, I'm sorry to see that C++ stands against to the majority of in=
tellectuals and it will forces learners to waste more time on such topics i=
f they unfortunately touched C++ at first. This result again conflicts to t=
eachability.<br>=C2=A0<br></div><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>That being said, instructor and teachers=
have a responsibility here, and the current rules can be taught (they have=
been for a while), just as new ones could. I think we should go for more o=
bjective arguments should this discussion continue. And I really would pref=
er to discuss over an actual proposal (it helps organize and focus discussi=
ons).<br><br></div><div>Cheers!<br></div></div><div><br><div class=3D"gmail=
_quote">2016-07-13 11:36 GMT-04:00 Ren Industries <span dir=3D"ltr"><<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GgNZBMb-CgA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">renind..=
..@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Why would the simplicity of teaching anything matter more than anything=
else? IEEE 754 is incredibly hard to teach, with many odd nuances to it, y=
et it is used because those nuances lead to better results. Modeling after =
the mathematical concepts underlying the operations may lead to more diffic=
ult to teach, but also has clear benefits, as DV explained.=C2=A0<div><br><=
/div></div><div><div><div><br><div class=3D"gmail_quote">On Wed, Jul 13, 20=
16 at 11:14 AM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"GgNZBMb-CgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">hyman...@gmail.com</a>></sp=
an> wrote:<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"><div><div cla=
ss=3D"gmail_quote"><span>On Wed, Jul 13, 2016 at 1:09 AM, Thiago Macieira <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"GgNZBMb-CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;;return true;">thi...@macieira.org</a>></span> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Note that this RTL for assignments was done like that to matc=
h the<br>
associativity of the operator in question:</blockquote></span><div><br>But =
why?=C2=A0 Associativity (and precedence) tell you how to fully parenthesiz=
e an expression.=C2=A0 Why should that inform the order in which subexpress=
ions are evaluated?=C2=A0 If I begin with the fully parenthesized expressio=
ns=C2=A0<font face=3D"monospace, monospace">a() =3D (b() =3D c())</font> an=
d <font face=3D"monospace, monospace">((a() =3D b()) =3D c()) </font>the fi=
rst parenthesized as for right associativity and the second for left, the n=
ew standard requires that the order of evaluation for both is <font face=3D=
"monospace, monospace">c(), b(), a()</font>, so how does associativity even=
matter?=C2=A0 And why should <font face=3D"monospace, monospace">a() <&=
lt; b()</font> require a different order than <font face=3D"monospace, mono=
space">a() <<=3D b()</font>=C2=A0while <font face=3D"monospace, monos=
pace">a() + b()</font> remains unspecified?=C2=A0 How does that help people=
to read and write C++?<br><br>DV's explanation that intuition suggests=
that the RHS be evaluated first for assignments seems more reasonable, but=
I don't find it sufficiently compelling to overcome the simplicity of =
teaching that evaluation is left-to-right, always.=C2=A0 Even if it runs co=
unter to intuition, it's a mistake that you can only make once because =
when you learn the rule, it's so sharp and easy that you can't forg=
et it.<br>=C2=A0</div></div></div></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
GgNZBMb-CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"GgNZBMb-CgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx=
4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy4gvUmYCcb=
xHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium\x3demail\x26=
utm_source\x3dfooter';return true;" onclick=3D"this.href=3D'https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy4gvUmYCcbxH=
HjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com?utm_medium\x3demail\x26ut=
m_source\x3dfooter';return true;">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/<wbr>CAHSYqdZQy4gvUmYCcbxHHjNksEw9D<wbr>e=
B-5kCx4_Q9PiS0%3DdccOw%<wbr>40mail.gmail.com</a>.<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" 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"=
GgNZBMb-CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"GgNZBMb-CgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2RfUQGRJvEuhoFGtmp5vd-FHsjg=
OOfcL91r1V2YWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2RfUQGRJvEu=
hoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com?utm_medium\x3demail\x26utm_=
source\x3dfooter';return true;" onclick=3D"this.href=3D'https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2RfUQGRJvEuhoFG=
tmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com?utm_medium\x3demail\x26utm_sour=
ce\x3dfooter';return true;">https://groups.google.com/a/<wbr>isocpp.org=
/d/msgid/std-<wbr>proposals/CAMD6iD_<wbr>YO2RfUQGRJvEuhoFGtmp5vd-<wbr>FHsjg=
OOfcL91r1V2YWw%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></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/5b323310-b056-4d5c-9658-54ae95e384c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b323310-b056-4d5c-9658-54ae95e384c1=
%40isocpp.org</a>.<br />
------=_Part_94_1769714299.1468470168639--
------=_Part_93_2089995201.1468470168639--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 21:28:38 -0700 (PDT)
Raw View
------=_Part_91_639722841.1468470519010
Content-Type: multipart/alternative;
boundary="----=_Part_92_738391205.1468470519011"
------=_Part_92_738391205.1468470519011
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=885:53:44=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=BC=
=9A
>
> Em quarta-feira, 13 de julho de 2016, =C3=A0s 11:14:41 PDT, Hyman Rosen=
=20
> escreveu:=20
> > But why? Associativity (and precedence) tell you how to fully=20
> parenthesize=20
> > an expression.=20
>
> Because it's the "happens before" order. When you write:=20
>
> As we don't talk about multithreading, I think "seqenced before" is=20
enouth.=20
> a() =3D b() =3D c() =3D d();=20
>
> The c() =3D d() assignment happens first. So regardless of the order in=
=20
> which c()=20
> and d() are called, I'd expect that the pair gets called before b().=20
>
> This is especially important if one of them throws. If the call to c() or=
=20
> d()=20
> or the assignment throws, then the rest of the expression is abandoned.=
=20
> Should=20
> a() and b() have been called? I'd argue that, due to the associativity=20
> rules,=20
> they shouldn't have.=20
>
> Think also of how many temporaries need to be kept in memory (let's think=
=20
> trivial types, for a moment). If they're evaluated right to left, then=20
> there's=20
> always one single temporary:=20
>
> T &&tmp =3D d(),=20
> tmp =3D (c() =3D tmp),=20
> tmp =3D (b() =3D tmp),=20
> a() =3D tmp;=20
>
> Whereas a left-to-right order would imply keeping more temporaries:=20
>
> T &&tmp_a =3D a(),=20
> T &&tmp_b =3D b(),=20
> T &&tmp_c =3D c(),=20
> tmp_c =3D d(),=20
> tmp_b =3D tmp_c,=20
> tmp_a =3D tmp_b;=20
>
> This directly leads to code optimisation: how many temporaries need to be=
=20
> kept=20
> in the stack during the expression?=20
>
> Finally, as a consequence of b() being called after (c(), d()) pair, it=
=20
> follows that d() should be called before c().=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=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/a98228df-6ed8-45ba-a86b-5071dbb8c7c2%40isocpp.or=
g.
------=_Part_92_738391205.1468470519011
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=885:53:44=EF=BC=8CThiago Macieir=
a=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em=
quarta-feira, 13 de julho de 2016, =C3=A0s 11:14:41 PDT, Hyman Rosen escre=
veu:
<br>> But why? =C2=A0Associativity (and precedence) tell you how to full=
y parenthesize
<br>> an expression.
<br>
<br>Because it's the "happens before" order. When you write:
<br>
<br></blockquote><div>As we don't talk about multithreading, I think &q=
uot;seqenced before" is enouth. <br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0a() =3D b(=
) =3D c() =3D d();
<br>
<br>The c() =3D d() assignment happens first. So regardless of the order in=
which c()=20
<br>and d() are called, I'd expect that the pair gets called before b()=
..
<br>
<br>This is especially important if one of them throws. If the call to c() =
or d()=20
<br>or the assignment throws, then the rest of the expression is abandoned.=
Should=20
<br>a() and b() have been called? I'd argue that, due to the associativ=
ity rules,=20
<br>they shouldn't have.
<br>
<br>Think also of how many temporaries need to be kept in memory (let's=
think=20
<br>trivial types, for a moment). If they're evaluated right to left, t=
hen there's=20
<br>always one single temporary:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0T &&tmp =3D d()=
,
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tmp =3D (c() =3D tmp),
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tmp =3D (b() =3D tmp),
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0a() =3D tmp;
<br>
<br>Whereas a left-to-right order would imply keeping more temporaries:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0T &&tmp_a =3D a=
(),
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0T &&tmp_b =3D b=
(),
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0T &&tmp_c =3D c=
(),
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tmp_c =3D d(),
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tmp_b =3D tmp_c,
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tmp_a =3D tmp_b;
<br>
<br>This directly leads to code optimisation: how many temporaries need to =
be kept=20
<br>in the stack during the expression?
<br>
<br>Finally, as a consequence of b() being called after (c(), d()) pair, it=
=20
<br>follows that d() should be called before c().
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';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'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';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" 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/a98228df-6ed8-45ba-a86b-5071dbb8c7c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a98228df-6ed8-45ba-a86b-5071dbb8c7c2=
%40isocpp.org</a>.<br />
------=_Part_92_738391205.1468470519011--
------=_Part_91_639722841.1468470519010--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 13 Jul 2016 21:34:51 -0700 (PDT)
Raw View
------=_Part_97_1281675650.1468470891292
Content-Type: multipart/alternative;
boundary="----=_Part_98_942401699.1468470891292"
------=_Part_98_942401699.1468470891292
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=9A
>
> I for one would be very happy if claims on stupidity, syndroms and other=
=20
> sorts of derogatory comments were kept away from the discussion. I=20
> appreciate the intellect of people I discuss with, even (particularly?)=
=20
> when we don't see eye to eye. I appreciate Jeffrey's efforts in that=20
> direction.
>
> I also appreciate that effort.
But please don't take "avoiding derogatory comments" as some sorts of=20
political correctness. There do exist certain kinds of stupidity and they=
=20
are not just you-know-who. I have to argue that is not "personal", that's=
=20
all. Sorry if that wording makes someone unhappy.
=20
> 2016-07-13 21:48 GMT-04:00 FrankHB1989 <frank...@gmail.com <javascript:>>=
:
>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=93=
=EF=BC=9A
>>>
>>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gmail.com> wrote=
:
>>>>
>>>> The true harm of such decision is, it encourages stupidity and lazines=
s=20
>>>> as the default case.
>>>>
>>>
>>> Please try to stick to technical arguments on this mailing list, instea=
d=20
>>> of personally attacking ("stupidity") the people who prefer a different=
=20
>>> outcome than you do.
>>>
>>> Jeffrey
>>>
>>
>> I believed it was common sense that "insisting on ignorance of language=
=20
>> rules as a need in general" is stupidity, to anyone. So it was not attac=
k=20
>> to anyone, esp. "personally".
>>
>> Technically, the rules consist the interface of the designed language.=
=20
>> How will you allow people who know little about them to decide how they=
=20
>> should be?
>>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e=
5d-4e7b-80a8-7ea9279d3516%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3=
e5d-4e7b-80a8-7ea9279d3516%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/e6848a1e-f812-410e-93ef-086e111e6122%40isocpp.or=
g.
------=_Part_98_942401699.1468470891292
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">I for one would be very happy if claims on stupidity, syndrom=
s and other sorts of derogatory comments were kept away from the discussion=
.. I appreciate the intellect of people I discuss with, even (particularly?)=
when we don't see eye to eye. I appreciate Jeffrey's efforts in th=
at direction.<br></div><div><br></div></blockquote><div>I also appreciate t=
hat effort.<br><br>But please don't take "avoiding derogatory comm=
ents" as some sorts of political correctness. There do exist certain k=
inds of stupidity and they are not just you-know-who. I have to argue that =
is not "personal", that's all. Sorry if that wording makes so=
meone unhappy.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div><div class=3D"gmail_quote">2016-07-13 21:48 GMT-04:00 FrankHB198=
9 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"fWec20EgCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&=
#39;;return true;">frank...@gmail.com</a>></span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=
=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=
=8CJeffrey Yasskin=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span>On Mon, Ju=
l 11, 2016 at 7:46 PM, FrankHB1989 <span dir=3D"ltr"><<a rel=3D"nofollow=
">frank...@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>The true harm of such decision is, it encourages stupid=
ity and laziness as the default case.</div></div></blockquote><div><br></di=
v></span><div>Please try to stick to technical arguments on this mailing li=
st, instead of personally attacking ("stupidity") the people who =
prefer a different outcome than you do.</div></div><br></div><div>Jeffrey</=
div></div></blockquote><div><br>I believed it was common sense that "i=
nsisting on ignorance of language rules as a need in general" is stupi=
dity, to anyone. So it was not attack to anyone, esp. "personally"=
;.<br><br>Technically, the rules consist the interface of the designed lang=
uage. How will you allow people who know little about them to decide how th=
ey should be?<br><br><br> </div></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
fWec20EgCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"fWec20EgCwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b2e0db59-3e5d-4e7b-<wbr>80a8-=
7ea9279d3516%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></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/e6848a1e-f812-410e-93ef-086e111e6122%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e6848a1e-f812-410e-93ef-086e111e6122=
%40isocpp.org</a>.<br />
------=_Part_98_942401699.1468470891292--
------=_Part_97_1281675650.1468470891292--
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Thu, 14 Jul 2016 13:32:32 +0200
Raw View
Personally, I am disappointed that we did not get a fixed evaluation
order. To me, the argument that a non-fixed evaluation order allows a
theoretical speed-up in the order of up to 4% has had to much weight
and perhaps even is a red herring. If you have an f(g(),h()) and both
g and h have side-effects, there is already unspecified behaviour, and
if they do not, the compiler is already free to choose whatever
evaluation order it deems best.
Instead, we could have removed a barrier for new or non-expert C++
programmers who do not understand why an example such as Hymans point
p =3D { read<int>(std::cin),read<int>(std::cin)} works wonderfully in
their environment and passes all unit-tests in order to suddenly and
mysteriously fail when porting to a new compiler or after an upgrade
of the same compiler, perhaps years later. I myself might easily
overlook that that code is really not working, but only appears to do
so.
So let us please have some experts out there (I am not one) who can
argue the case for safety and security over speed and persuade all the
skilled experts such as FrankHB and Catmur about the value of a strict
order evaluation.
For those interested in speed, it is my belief that speed can be had
in another way. A good, pragmatic specification of pure would be one
way forward.
/Peter
PS: I have no problem living with assignment being right to left
rather than left to right.
On Thu, Jul 14, 2016 at 6:34 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B U=
TC+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> I for one would be very happy if claims on stupidity, syndroms and other
>> sorts of derogatory comments were kept away from the discussion. I
>> appreciate the intellect of people I discuss with, even (particularly?) =
when
>> we don't see eye to eye. I appreciate Jeffrey's efforts in that directio=
n.
>>
> I also appreciate that effort.
>
> But please don't take "avoiding derogatory comments" as some sorts of
> political correctness. There do exist certain kinds of stupidity and they
> are not just you-know-who. I have to argue that is not "personal", that's
> all. Sorry if that wording makes someone unhappy.
>
>>
>> 2016-07-13 21:48 GMT-04:00 FrankHB1989 <frank...@gmail.com>:
>>>
>>>
>>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=
UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=93=
=EF=BC=9A
>>>>
>>>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gmail.com> wrot=
e:
>>>>>
>>>>> The true harm of such decision is, it encourages stupidity and lazine=
ss
>>>>> as the default case.
>>>>
>>>>
>>>> Please try to stick to technical arguments on this mailing list, inste=
ad
>>>> of personally attacking ("stupidity") the people who prefer a differen=
t
>>>> outcome than you do.
>>>>
>>>> Jeffrey
>>>
>>>
>>> I believed it was common sense that "insisting on ignorance of language
>>> rules as a need in general" is stupidity, to anyone. So it was not atta=
ck to
>>> anyone, esp. "personally".
>>>
>>> Technically, the rules consist the interface of the designed language.
>>> How will you allow people who know little about them to decide how they
>>> should be?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Grou=
ps
>>> "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an
>>> email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3=
e5d-4e7b-80a8-7ea9279d3516%40isocpp.org.
>>
>>
> --
> 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/e6848a1e-f81=
2-410e-93ef-086e111e6122%40isocpp.org.
--=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/CANPtknx-capfQPC%3Dw4SFL%3DjadcrFZzBp3ReP23aYQKK=
BUw%2ByVg%40mail.gmail.com.
.
Author: jsphadetula@gmail.com
Date: Thu, 14 Jul 2016 11:53:41 +0000 (UTC)
Raw View
------=_Part_1730_324818665.1468497221160
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What if LTR is adopted but the compiler rewrites the arguments as statement=
s one after the other then feeds the results back to the function, will the=
performance penalty still persist
Get Outlook for Android
On Thu, Jul 14, 2016 at 12:32 PM +0100, "Peter Koch Larsen" <peter.koch.lar=
sen@gmail.com> wrote:
Personally, I am disappointed that we did not get a fixed evaluation
order. To me, the argument that a non-fixed evaluation order allows a
theoretical speed-up in the order of up to 4% has had to much weight
and perhaps even is a red herring. If you have an f(g(),h()) and both
g and h have side-effects, there is already unspecified behaviour, and
if they do not, the compiler is already free to choose whatever
evaluation order it deems best.
Instead, we could have removed a barrier for new or non-expert C++
programmers who do not understand why an example such as Hymans point
p =3D { read(std::cin),read(std::cin)} works wonderfully in
their environment and passes all unit-tests in order to suddenly and
mysteriously fail when porting to a new compiler or after an upgrade
of the same compiler, perhaps years later. I myself might easily
overlook that that code is really not working, but only appears to do
so.
So let us please have some experts out there (I am not one) who can
argue the case for safety and security over speed and persuade all the
skilled experts such as FrankHB and Catmur about the value of a strict
order evaluation.
For those interested in speed, it is my belief that speed can be had
in another way. A good, pragmatic specification of pure would be one
way forward.
/Peter
PS: I have no problem living with assignment being right to left
rather than left to right.
On Thu, Jul 14, 2016 at 6:34 AM, FrankHB1989 wrote:
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B U=
TC+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> I for one would be very happy if claims on stupidity, syndroms and other
>> sorts of derogatory comments were kept away from the discussion. I
>> appreciate the intellect of people I discuss with, even (particularly?) =
when
>> we don't see eye to eye. I appreciate Jeffrey's efforts in that directio=
n.
>>
> I also appreciate that effort.
>
> But please don't take "avoiding derogatory comments" as some sorts of
> political correctness. There do exist certain kinds of stupidity and they
> are not just you-know-who. I have to argue that is not "personal", that's
> all. Sorry if that wording makes someone unhappy.
>
>>
>> 2016-07-13 21:48 GMT-04:00 FrankHB1989 :
>>>
>>>
>>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=
UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=93=
=EF=BC=9A
>>>>
>>>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 wrote:
>>>>>
>>>>> The true harm of such decision is, it encourages stupidity and lazine=
ss
>>>>> as the default case.
>>>>
>>>>
>>>> Please try to stick to technical arguments on this mailing list, inste=
ad
>>>> of personally attacking ("stupidity") the people who prefer a differen=
t
>>>> outcome than you do.
>>>>
>>>> Jeffrey
>>>
>>>
>>> I believed it was common sense that "insisting on ignorance of language
>>> rules as a need in general" is stupidity, to anyone. So it was not atta=
ck to
>>> anyone, esp. "personally".
>>>
>>> Technically, the rules consist the interface of the designed language.
>>> How will you allow people who know little about them to decide how they
>>> should be?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Grou=
ps
>>> "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an
>>> email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3=
e5d-4e7b-80a8-7ea9279d3516%40isocpp.org.
>>
>>
> --
> 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/e6848a1e-f81=
2-410e-93ef-086e111e6122%40isocpp.org.
--=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/CANPtknx-capfQPC%3Dw4SFL%3DjadcrFZzBp3ReP23aYQKK=
BUw%2ByVg%40mail.gmail.com.
--=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/997FEFE7601FB061.f4e48d6d-533d-4e74-b8cd-53b6fd2=
a7b7f%40mail.outlook.com.
------=_Part_1730_324818665.1468497221160
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"auto">What if LTR is adopted but the com=
piler rewrites the arguments as statements one after the other then feeds t=
he results back to the function, will the performance penalty still persist=
</p>
<p dir=3D"auto">Get <a href=3D"https://aka.ms/ghei36">Outlook for Android</=
a><br>
</p>
<br><br><br>
<div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 12:32 PM +0100, "Peter K=
och Larsen" <span dir=3D"ltr"><<a href=3D"mailto:peter.koch.larsen@gmail=
..com" target=3D"_blank">peter.koch.larsen@gmail.com</a>></span> wrote:<b=
r>
<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"3D"ltr"">
<pre>Personally, I am disappointed that we did not get a fixed evaluation
order. To me, the argument that a non-fixed evaluation order allows a
theoretical speed-up in the order of up to 4% has had to much weight
and perhaps even is a red herring. If you have an f(g(),h()) and both
g and h have side-effects, there is already unspecified behaviour, and
if they do not, the compiler is already free to choose whatever
evaluation order it deems best.
Instead, we could have removed a barrier for new or non-expert C++
programmers who do not understand why an example such as Hymans point
p =3D { read<int>(std::cin),read<int>(std::cin)} works wonderfully in
their environment and passes all unit-tests in order to suddenly and
mysteriously fail when porting to a new compiler or after an upgrade
of the same compiler, perhaps years later. I myself might easily
overlook that that code is really not working, but only appears to do
so.
So let us please have some experts out there (I am not one) who can
argue the case for safety and security over speed and persuade all the
skilled experts such as FrankHB and Catmur about the value of a strict
order evaluation.
For those interested in speed, it is my belief that speed can be had
in another way. A good, pragmatic specification of pure would be one
way forward.
/Peter
PS: I have no problem living with assignment being right to left
rather than left to right.
On Thu, Jul 14, 2016 at 6:34 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=
=9B UTC+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=
=EF=BC=9A
>>
>> I for one would be very happy if claims on stupidity, syndroms and=
other
>> sorts of derogatory comments were kept away from the discussion. I
>> appreciate the intellect of people I discuss with, even (particula=
rly?) when
>> we don't see eye to eye. I appreciate Jeffrey's efforts in that di=
rection.
>>
> I also appreciate that effort.
>
> But please don't take "avoiding derogatory comments" as some sorts of
> political correctness. There do exist certain kinds of stupidity and t=
hey
> are not just you-know-who. I have to argue that is not "personal", tha=
t's
> all. Sorry if that wording makes someone unhappy.
>
>>
>> 2016-07-13 21:48 GMT-04:00 FrankHB1989 <frank...@gmail.com>:
>>>
>>>
>>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=
=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=
=E9=81=93=EF=BC=9A
>>>>
>>>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gma=
il.com> wrote:
>>>>>
>>>>> The true harm of such decision is, it encourages stupi=
dity and laziness
>>>>> as the default case.
>>>>
>>>>
>>>> Please try to stick to technical arguments on this mailing=
list, instead
>>>> of personally attacking ("stupidity") the people who prefe=
r a different
>>>> outcome than you do.
>>>>
>>>> Jeffrey
>>>
>>>
>>> I believed it was common sense that "insisting on ignorance of=
language
>>> rules as a need in general" is stupidity, to anyone. So it was=
not attack to
>>> anyone, esp. "personally".
>>>
>>> Technically, the rules consist the interface of the designed l=
anguage.
>>> How will you allow people who know little about them to decide=
how they
>>> should be?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Go=
ogle Groups
>>> "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from =
it, send an
>>> email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b=
2e0db59-3e5d-4e7b-80a8-7ea9279d3516%40isocpp.org.
>>
>>
> --
> You received this message because you are subscribed to the Google Gro=
ups
> "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/e6848a1e-=
f812-410e-93ef-086e111e6122%40isocpp.org.
--=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/CANPtknx-capfQPC%3Dw4SFL%3DjadcrFZzBp3ReP23aYQKK=
BUw%2ByVg%40mail.gmail.com.
</frank...@gmail.com></frank...@gmail.com></frankhb1989@gmail.com></int></i=
nt></pre>
</div>
</blockquote>
</div>
</body></html>
<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/997FEFE7601FB061.f4e48d6d-533d-4e74-b=
8cd-53b6fd2a7b7f%40mail.outlook.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/997FEFE7601FB=
061.f4e48d6d-533d-4e74-b8cd-53b6fd2a7b7f%40mail.outlook.com</a>.<br />
------=_Part_1730_324818665.1468497221160--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 11:29:52 -0400
Raw View
--001a1149c49c8cc4ed05379a2d11
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13, 2016 at 11:31 PM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 U=
TC+8=E4=B8=8A=E5=8D=884:37:53=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> The problem is that the ordering for assignment, once specified as
>> right-to-left in C++17, can never be fixed. That's heinous.
>>
>
> For assignments this was actually specified long ago. See CWG 222 and CWG
> 637. There may be more subtle risks to change.
>
CWG 222 and 637 are for C, not C++. More to the point, they do not specify
order of evaluation for assignment. What are you trying to say?
In any case, compatibility with C is irrelevant; the two languages are
already different with respect to order. For example:
C 11 N1570 6.7.9.23: "The evaluations of the initialization list
expressions are indeterminately sequenced with respect to one another and
thus the order in which any side effects occur is unspecified."
C++ 17 N4527 8.5.4/4: "Within the initializer-list of a braced-init-list
.... every value computation and side effect associated with a given
initializer-clause is sequenced before every value computation and side
effect associated with any initializer-clause that follows it in the
comma-separated list of the initializer-list."
--=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/CAHSYqdav%2B%2B5Srs1%3DCf_xGDV_sxtKsvH-H%3D_M-M0=
jYQcZs5fFCw%40mail.gmail.com.
--001a1149c49c8cc4ed05379a2d11
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 W=
ed, Jul 13, 2016 at 11:31 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=
=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:37=
:53=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>The problem is that the order=
ing for assignment, once specified as right-to-left in C++17, can never be =
fixed.=C2=A0 That's heinous.</div></div></div></div></blockquote><div><=
br>For assignments this was actually specified long ago. See CWG 222 and CW=
G 637. There may be more subtle risks to change.</div></div></blockquote><d=
iv><br>CWG 222 and 637 are for C, not C++.=C2=A0 More to the point, they do=
not specify order of evaluation for assignment.=C2=A0 What are you trying =
to say?<br><br>In any case, compatibility with C is irrelevant; the two lan=
guages are already different with respect to order.=C2=A0 For example:<br><=
br>C 11 N1570 <a href=3D"http://6.7.9.23">6.7.9.23</a>: "The evaluatio=
ns of the initialization list expressions are indeterminately sequenced wit=
h respect to one another and thus the order in which any side effects occur=
is unspecified."<br><br>C++ 17 N4527 8.5.4/4: "Within the initia=
lizer-list of a braced-init-list ... every value computation and side effec=
t associated with a given initializer-clause is sequenced before every valu=
e computation and side effect associated with any initializer-clause that f=
ollows it in the comma-separated list of the initializer-list."</div><=
/div></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/CAHSYqdav%2B%2B5Srs1%3DCf_xGDV_sxtKsv=
H-H%3D_M-M0jYQcZs5fFCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdav=
%2B%2B5Srs1%3DCf_xGDV_sxtKsvH-H%3D_M-M0jYQcZs5fFCw%40mail.gmail.com</a>.<br=
/>
--001a1149c49c8cc4ed05379a2d11--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 11:40:54 -0400
Raw View
--001a1141fcbef9645a05379a5408
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13, 2016 at 7:19 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> Em quarta-feira, 13 de julho de 2016, =C3=A0s 18:26:05 PDT, Hyman Rosen
> escreveu:
> > When you write
> > ((a() =3D b()) =3D c()) =3D d()
> > the a() =3D b() assignment happens first. But the standard (now) still
> > requires the valuation order d(), c(), b(), a().
> > It doesn't seem to me that you've made your case.
>
> You didn't actually change anything. The consequence of the associativity
> is
> that the right side needs to be evaluated before the left. The fact that
> the
> left also has an assignment inside parentheses is irrelevant.
>
No, associativity has no consequence with respect to order of evaluation
of subexpressions. Associativity (and precedence) tell you how to fully
parenthesize expressions, nothing more. Assignment is right-associative
simply because we want a =3D b =3D c to assign to both b and a, and not onl=
y to
a. So we parenthesize it as a =3D (b =3D c) instead of (a =3D b) =3D c bec=
ause the
latter would result in two assignments to a and none to b.
Moreover, the committee disagrees with your opinion.
The committee has been wrong many times before. It is wrong again.
--=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/CAHSYqdai%2BVLaEk6Naf-di61c3UYRCe96yCyMaeVU5_XYh=
8-KSA%40mail.gmail.com.
--001a1141fcbef9645a05379a5408
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 W=
ed, Jul 13, 2016 at 7:19 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex"><span class=3D"">Em quarta-feira, 13 d=
e julho de 2016, =C3=A0s 18:26:05 PDT, Hyman Rosen escreveu:<br>
> When you write<br>
>=C2=A0 =C2=A0 =C2=A0((a() =3D b()) =3D c()) =3D d()<br>
> the a() =3D b() assignment happens first.=C2=A0 But the standard (now)=
still<br>
> requires the valuation order d(), c(), b(), a().<br>
> It doesn't seem to me that you've made your case.<br>
<br>
</span>You didn't actually change anything. The consequence of the asso=
ciativity is<br>
that the right side needs to be evaluated before the left. The fact that th=
e<br>
left also has an assignment inside parentheses is irrelevant.<br></blockquo=
te><div><br></div><div>No, associativity has no consequence with respect to=
order of evaluation of=C2=A0subexpressions.=C2=A0 Associativity (and prece=
dence) tell you how to fully parenthesize expressions, nothing more.=C2=A0 =
Assignment is right-associative simply because we want <font face=3D"monosp=
ace, monospace">a =3D b =3D c</font> to assign to both <font face=3D"monosp=
ace, monospace">b</font> and <font face=3D"monospace, monospace">a</font>, =
and not only to <font face=3D"monospace, monospace">a</font>.=C2=A0 So we p=
arenthesize it as <font face=3D"monospace, monospace">a =3D (b =3D c)</font=
> instead of <font face=3D"monospace, monospace">(a =3D b) =3D c</font> bec=
ause the latter would result in two assignments to <font face=3D"monospace,=
monospace">a</font> and none to <font face=3D"monospace, monospace">b</fon=
t>.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex">
Moreover, the committee disagrees with your opinion.</blockquote><div><br>T=
he committee has been wrong many times before.=C2=A0 It is wrong again.</di=
v></div></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/CAHSYqdai%2BVLaEk6Naf-di61c3UYRCe96yC=
yMaeVU5_XYh8-KSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdai%2BVLa=
Ek6Naf-di61c3UYRCe96yCyMaeVU5_XYh8-KSA%40mail.gmail.com</a>.<br />
--001a1141fcbef9645a05379a5408--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 11:50:30 -0400
Raw View
--001a114a84984c1ae405379a7743
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 9:37 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> At least my opinion is not only for C++. Particularly, C++ is complicated
> enough. So I doubt any modification of rules can be easily settle down
> without confusion. The latter is not against to any concrete proposal, but
> it counts.
>
Strict left-to-right simplifies the rules. It cannot be more confusing to
specify an order than to leave the order unspecified.
the changes make some portable code in previous version of C++ lose some
> precisely specified semantics properties
>
I know you believe that it is important for C++ programmers to be able to
express in their programs that they want subexpressions to be deliberately
unordered. I believe this ability is not only unimportant, but that the
vast majority of C++ programmers have never even thought of embedding such
semantics into their code, and would not do so if informed of the
possibility. I believe that it is wrong to prevent the adoption of a
sensible rule that would prevent errors in code from spontaneously
appearing in order to preserve the ability to express something unimportant.
--
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/CAHSYqda65XwRCQn8Jikcj-8CZ-1gGtoy6auAM85X98gs0KL%2BBw%40mail.gmail.com.
--001a114a84984c1ae405379a7743
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 W=
ed, Jul 13, 2016 at 9:37 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>At leas=
t my opinion is not only for C++. Particularly, C++ is complicated enough. =
So I doubt any modification of rules can be easily settle down without conf=
usion. The latter is not against to any concrete proposal, but it counts.<b=
r></div></div></blockquote><div><br>Strict left-to-right simplifies the rul=
es.=C2=A0 It cannot be more confusing to specify an order than to leave the=
order unspecified.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>the changes make some portable code in previous version of C++ l=
ose some precisely specified semantics properties</div></div></blockquote><=
div><br>I know you believe that it is important for C++ programmers to be a=
ble to express in their programs that they want subexpressions to be delibe=
rately unordered.=C2=A0 I believe this ability is not only unimportant, but=
that the vast majority of C++ programmers have never even thought of embed=
ding such semantics into their code, and would not do so if informed of the=
possibility.=C2=A0 I believe that it is wrong to prevent the adoption of a=
sensible rule that would prevent errors in code from spontaneously appeari=
ng in order to preserve the ability to express something unimportant.</div>=
</div></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/CAHSYqda65XwRCQn8Jikcj-8CZ-1gGtoy6auA=
M85X98gs0KL%2BBw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda65XwRCQ=
n8Jikcj-8CZ-1gGtoy6auAM85X98gs0KL%2BBw%40mail.gmail.com</a>.<br />
--001a114a84984c1ae405379a7743--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 14 Jul 2016 08:53:12 -0700
Raw View
On quinta-feira, 14 de julho de 2016 11:40:54 PDT Hyman Rosen wrote:
> > You didn't actually change anything. The consequence of the associativity
> > is
> > that the right side needs to be evaluated before the left. The fact that
> > the
> > left also has an assignment inside parentheses is irrelevant.
>
> No, associativity has no consequence with respect to order of evaluation
> of subexpressions. Associativity (and precedence) tell you how to fully
> parenthesize expressions, nothing more. Assignment is right-associative
> simply because we want a = b = c to assign to both b and a, and not only to
> a. So we parenthesize it as a = (b = c) instead of (a = b) = c because the
> latter would result in two assignments to a and none to b.
Let me re-state my argument.
Due to the associativity rules, in the expression
a = b = c;
a will get the value of the b = c assignment. For that to happen, we require
that b = c must be run first. There's no argument here.
Therefore, the committee ruled that the RHS of the a = x expression (with x :=
b = c) should be evaluated first. So assignments should have evaluation from
the right to left.
--
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/3253537.nqfeqHXg7B%40tjmaciei-mobl1.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:01:07 -0400
Raw View
--001a114fda9c4cdd2805379a9d13
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13, 2016 at 10:00 PM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 U=
TC+8=E4=B8=8A=E5=8D=8812:12:08=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> The "stupidity and laziness" argument demands that the programming
>> language should contain constructs that must not be used, and that will =
act
>> as traps for the unwary. The notion that this is a desirable feature ag=
ain
>> seems to me so irrational that it beggars belief.
>>
>> No. I don't express that. Any constructs should be used at ones' own
> risks. If you don't want to use something, that's OK. If you don't want t=
o
> see the code use such features, then tag the code using them as of "bad
> code style" with sufficient reasons which are *not so subjective* (when
> you want to convince others). But "I'm not using it" is certainly not a
> good excuse to *forbid *it used *by others through the language
> specification*, unless you want to keep those users away. Since C++ is
> not designed as noob-oriented by you, and there are some people do rely o=
n
> something you want to remove, I think your point is problematic. If you
> want to remove something indisputably, you have to prove that it does
> nothing useful to *almost anyone* or there are sufficient ways as
> *replacement*, and/or it is harmful *in almost any case*. This is not the
> case here.
>
C++ is a programming language, used to direct the actions of a computer.
It is meaningless to say that a programming language contains constructs
that can be "used at one's own risk". That is Stockholm Syndrome and
misplaced nerd hubris. If such constructs exist in the language, it means
that the language has been poorly specified, so that it is easy for
programmers to use the constructs incorrectly. The solution is not to warn
the programmers but to fix the language.
Again, with respect to order of evaluation, we are speaking of specifying
behavior which is currently unspecified. It appears to be very important
to you that programmers be able to deliberately express in their C++ code
that they want subexpressions to be unordered, but I believe that it is
important to no one else, and certainly not a reason to avoid adopting a
rule that would be of actual benefit to programmers.
--=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/CAHSYqdY81ik232sD2gp1jQRCWGiiJ_1ZFmt5-Ork4XwZDy9=
otg%40mail.gmail.com.
--001a114fda9c4cdd2805379a9d13
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 W=
ed, Jul 13, 2016 at 10:00 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2=
016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=
=E5=8D=8812:12:08=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<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">The "stupidity and lazin=
ess" argument demands that the programming language should contain con=
structs that must not be used, and that will act as traps for the unwary.=
=C2=A0 The notion that this is a desirable feature again seems to me so irr=
ational that it beggars belief.</div><div><br></div></blockquote><div>No. I=
don't express that. Any constructs should be used at ones' own ris=
ks. If you don't want to use something, that's OK. If you don't=
want to see the code use such features, then tag the code using them as of=
"bad code style" with sufficient reasons which are <i>not so sub=
jective</i> (when you want to convince others).=C2=A0 But "I'm not=
using it" is certainly not a good excuse to <i>forbid </i>it used <i>=
by others through the language specification</i>, unless you want to keep t=
hose users away. Since C++ is not designed as noob-oriented by you, and the=
re are some people do rely on something you want to remove, I think your po=
int is problematic. If you want to remove something indisputably, you have =
to prove that it does nothing useful to <i>almost anyone</i> or there are s=
ufficient ways as <i>replacement</i>, and/or it is harmful <i>in almost any=
case</i>. This is not the case here.</div></div></blockquote><div><br>C++ =
is a programming language, used to direct the actions of a computer.=C2=A0 =
It is meaningless to say that a programming language contains constructs th=
at can be "used at one's own risk".=C2=A0 That is Stockholm S=
yndrome and misplaced nerd hubris.=C2=A0 If such constructs exist in the la=
nguage, it means that the language has been poorly specified, so that it is=
easy for programmers to use the constructs incorrectly.=C2=A0 The solution=
is not to warn the programmers but to fix the language.<br><br>Again, with=
respect to order of evaluation, we are speaking of specifying behavior whi=
ch is currently unspecified.=C2=A0 It appears to be very important to you t=
hat programmers be able to deliberately express in their C++ code that they=
want subexpressions to be unordered, but I believe that it is important to=
no one else, and certainly not a reason to avoid adopting a rule that woul=
d be of actual benefit to programmers.</div></div></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/CAHSYqdY81ik232sD2gp1jQRCWGiiJ_1ZFmt5=
-Ork4XwZDy9otg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY81ik232sD=
2gp1jQRCWGiiJ_1ZFmt5-Ork4XwZDy9otg%40mail.gmail.com</a>.<br />
--001a114fda9c4cdd2805379a9d13--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:07:40 -0400
Raw View
--001a114c843ab538be05379ab43d
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 10:30 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> Some of your points are plainly technically incorrect, despite of what
> values you want to achieve. For example, the language (not only C++) is
> certainly allowed with both specified and unspecified evaluation order on
> expressions, just in different cases with different grammars. You are
> actually not only insisting on evaluation order; you also don't want any
> conforming extensions, just because you think that is right. This point is
> what I mostly against to.
>
I don't understand what this means. What grammars? What extensions? I am
speaking of order of evaluation in C++ expressions.
> Further, you said you had found that designers of Java made the choice you
> want, but you seem to deliberately ignore the related notes in Java
> Language Specification (as I mentioned more than once), which tells you
> that the designers of Java do not like the idea about relying on such
> rules. This clearly contradicts your belief. Why you adopt the point
> selectively?
>
The Java designers came from decades of having internalized the prejudice
against relying on evaluation order because they used languages where it
was unspecified. They decided to specify the order (and made the correct
choices), but could not overcome the burden of their habits.
I personally don't write or want to review such code.
>
Sometimes it's the code that's bad and sometimes it's the language that's
bad. Sometimes claiming the former is a means to avoid fixing the latter.
--
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/CAHSYqdbxCbJEAvPRUKuK_Thir4WiYXjBRc1rQSatf-uG4sJS2A%40mail.gmail.com.
--001a114c843ab538be05379ab43d
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 W=
ed, Jul 13, 2016 at 10:30 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Some o=
f your points are plainly technically incorrect, despite of what values you=
want to achieve. For example, the language (not only C++) is certainly all=
owed with both specified and unspecified evaluation order on expressions, j=
ust in different cases with different grammars. You are actually not only i=
nsisting on evaluation order; you also don't want any conforming extens=
ions, just because you think that is right. This point is what I mostly aga=
inst to.<br></div></div></blockquote><div><br>I don't understand what t=
his means.=C2=A0 What grammars? What extensions?=C2=A0 I am speaking of ord=
er of evaluation in C++ expressions.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>Further, you said you had found that designer=
s of Java made the choice you want, but you seem to deliberately ignore the=
related notes in Java Language Specification (as I mentioned more than onc=
e), which tells you that the designers of Java do not like the idea about r=
elying on such rules. This clearly contradicts your belief. Why you adopt t=
he point selectively?<br></div></div></blockquote><div><br>The Java designe=
rs came from decades of having internalized the prejudice against relying o=
n evaluation order because they used languages where it was unspecified.=C2=
=A0 They decided to specify the order (and made the correct choices), but c=
ould not overcome the burden of their habits.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>I personally don't write or want t=
o review such code.</div></div></blockquote><div><br>Sometimes it's the=
code that's bad and sometimes it's the language that's bad.=C2=
=A0 Sometimes claiming the former is a means to avoid fixing the latter.</d=
iv></div></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/CAHSYqdbxCbJEAvPRUKuK_Thir4WiYXjBRc1r=
QSatf-uG4sJS2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbxCbJEAvPR=
UKuK_Thir4WiYXjBRc1rQSatf-uG4sJS2A%40mail.gmail.com</a>.<br />
--001a114c843ab538be05379ab43d--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:11:31 -0400
Raw View
--001a114c843a75014b05379ac27f
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 11:02 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> Or do you really believe there can only be one evaluation order in the
> world, or users of C++ should not touch any one of them other than
> left-to-right order?
>
Yes. A programming language is used to direct the operations of a
computer. The constructs of the language should be precisely defined so
that the programmer does not write ambiguous directions. The constructs of
the language should be defined so that it is not easy for programmers to
unwittingly write ambiguous directions.
--
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/CAHSYqdbk9e31GOfZbhanpti%3DwuP3CqrHZ6Q%3DHFJYyM-hj%3DRq-Q%40mail.gmail.com.
--001a114c843a75014b05379ac27f
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 W=
ed, Jul 13, 2016 at 11:02 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Or do =
you really believe there can only be one evaluation order in the world, or =
users of C++ should not touch any one of them other than left-to-right orde=
r?</div></div></blockquote><div><br>Yes.=C2=A0 A programming language is us=
ed to direct the operations of a computer.=C2=A0 The constructs of the lang=
uage should be precisely defined so that the programmer does not write ambi=
guous directions.=C2=A0 The constructs of the language should be defined so=
that it is not easy for programmers to unwittingly write ambiguous directi=
ons.</div></div></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/CAHSYqdbk9e31GOfZbhanpti%3DwuP3CqrHZ6=
Q%3DHFJYyM-hj%3DRq-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbk9e=
31GOfZbhanpti%3DwuP3CqrHZ6Q%3DHFJYyM-hj%3DRq-Q%40mail.gmail.com</a>.<br />
--001a114c843a75014b05379ac27f--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:15:12 -0400
Raw View
--001a114c843aaecfb905379acfb5
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 13, 2016 at 11:28 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
>
> - Leave it unseqenced, if intended.
>
>
The proportion of C++ code that has intentional lack of sequence is 0, to a
great number of decimal places. Using this as a reason to not adopt rules
that would prevent latent errors from being expressed years after they are
written is wrong.
--
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/CAHSYqdZheWVMDYVmATiNoHEi3yZA6G0cNN6bA_81Bs%2ByV%3DWLrg%40mail.gmail.com.
--001a114c843aaecfb905379acfb5
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 W=
ed, Jul 13, 2016 at 11:28 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><l=
i>Leave it unseqenced, if intended.</li></ul></div></div></blockquote><div>=
<br>The proportion of C++ code that has intentional lack of sequence is 0, =
to a great number of decimal places.=C2=A0 Using this as a reason to not ad=
opt rules that would prevent latent errors from being expressed years after=
they are written is wrong.</div></div></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/CAHSYqdZheWVMDYVmATiNoHEi3yZA6G0cNN6b=
A_81Bs%2ByV%3DWLrg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZheWVM=
DYVmATiNoHEi3yZA6G0cNN6bA_81Bs%2ByV%3DWLrg%40mail.gmail.com</a>.<br />
--001a114c843aaecfb905379acfb5--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:20:55 -0400
Raw View
--001a1135729e19adfb05379ae447
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 12:07 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> If people don't know enough to their languages, they have nothing to
> conform.
>
The f(new T, new T) discussion first appeared in 2009, some ten years after
C++ was standardized. So the people who "don't enough to their languages"
included the entire universe of C++ programmers. That's not the fault of
the programmers, that's the fault of the language.
--
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/CAHSYqday4EaG48h%3DVgxERHEFj5hoGEUmjS1BzDdA-qKF74%3D__w%40mail.gmail.com.
--001a1135729e19adfb05379ae447
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, Jul 14, 2016 at 12:07 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>If people don't =
know enough to their languages, they have nothing to conform.</div></div></=
blockquote><div><br>The <font face=3D"monospace, monospace">f(new T, new T)=
</font> discussion first appeared in 2009, some ten years after C++ was sta=
ndardized.=C2=A0 So the people who "don't enough to their language=
s" included the entire universe of C++ programmers.=C2=A0 That's n=
ot the fault of the programmers, that's the fault of the language.</div=
></div></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/CAHSYqday4EaG48h%3DVgxERHEFj5hoGEUmjS=
1BzDdA-qKF74%3D__w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqday4EaG=
48h%3DVgxERHEFj5hoGEUmjS1BzDdA-qKF74%3D__w%40mail.gmail.com</a>.<br />
--001a1135729e19adfb05379ae447--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:26:18 -0400
Raw View
--001a114a849859346305379af7be
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 12:22 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> At least to treat evaluation order same to some other mysterious order *is
> *destroying the teachability because in general they are unrelated
> things. I don't think encouraging such illusion is a good result of
> teaching.
>
> If someone insist on that should be the case of C++, I'm sorry to see that
> C++ stands against to the majority of intellectuals and it will forces
> learners to waste more time on such topics if they unfortunately touched
> C++ at first. This result again conflicts to teachability.
>
That's correct. C++ evaluation order should be strictly left-to-right, and
then programmers should simply be taught that this is the rule.
Additionally, they might have to be untaught the PEMDAS rule they learned
in school; in the expression a() + b() * c(), we do not order the calls as
b(), c(), a() even though the multiplication happens before the addition.
--
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/CAHSYqdYf6NCcUrUr5yuNRb-Fv1UJFgWr-Xkd4VezPPOkHoa9%2BQ%40mail.gmail.com.
--001a114a849859346305379af7be
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, Jul 14, 2016 at 12:22 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>At lea=
st to treat evaluation order same to some other mysterious order <i>is </i>=
destroying the teachability because in general they are unrelated things. I=
don't think encouraging such illusion is a good result of teaching.<br=
><br>If someone insist on that should be the case of C++, I'm sorry to =
see that C++ stands against to the majority of intellectuals and it will fo=
rces learners to waste more time on such topics if they unfortunately touch=
ed C++ at first. This result again conflicts to teachability.</div></div></=
blockquote><div><br>That's correct.=C2=A0 C++ evaluation order should b=
e strictly left-to-right, and then programmers should simply be taught that=
this is the rule.=C2=A0 Additionally, they might have to be untaught the P=
EMDAS rule they learned in school; in the expression <font face=3D"monospac=
e, monospace">a() + b() * c()</font>, we do not order the calls as <font fa=
ce=3D"monospace, monospace">b()</font>, <font face=3D"monospace, monospace"=
>c()</font>, <font face=3D"monospace, monospace">a()</font> even though the=
multiplication happens before the addition.</div></div></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/CAHSYqdYf6NCcUrUr5yuNRb-Fv1UJFgWr-Xkd=
4VezPPOkHoa9%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYf6NCcUr=
Ur5yuNRb-Fv1UJFgWr-Xkd4VezPPOkHoa9%2BQ%40mail.gmail.com</a>.<br />
--001a114a849859346305379af7be--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 12:36:56 -0400
Raw View
--001a1140846866edbf05379b1d41
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 11:53 AM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Let me re-state my argument.
>
> Due to the associativity rules, in the expression
> a = b = c;
>
> a will get the value of the b = c assignment. For that to happen, we
> require
> that b = c must be run first. There's no argument here.
>
> Therefore, the committee ruled that the RHS of the a = x expression (with
> x :=
> b = c) should be evaluated first. So assignments should have evaluation
> from
> the right to left.
Just because you say "therefore" does not mean that the second statement
actually follows from the first.
To wit:
Due to the parenthesization rules, in the expression
a << (b << c)
a will be shifted by the result of the b << c shift. For that to
happen, we require that b << c must be run first.
There's no argument there.
Therefore, the committee ruled that the RHS of the a << x expression
(with x := b << c) should be evaluated first.
So shifts should have evaluation from the right to the left.
See how that works?
--
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/CAHSYqda11wvCRdjtihSStD%3DiO9Qzkf38vEaaBBLXCv305ZKDww%40mail.gmail.com.
--001a1140846866edbf05379b1d41
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, Jul 14, 2016 at 11:53 AM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex">Let me re-state my argument.<br>
<br>
Due to the associativity rules, in the expression<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D b =3D c;<br>
<br>
a will get the value of the b =3D c assignment. For that to happen, we requ=
ire<br>
that b =3D c must be run first. There's no argument here.<br>
<br>
Therefore, the committee ruled that the RHS of the a =3D x expression (with=
x :=3D<br>
b =3D c) should be evaluated first. So assignments should have evaluation f=
rom<br>
the right to left.</blockquote><div><br>Just because you say "therefor=
e" does not mean that the second statement actually follows=C2=A0from =
the first.<br>To wit:<br><br>=C2=A0 =C2=A0 Due to the parenthesization rule=
s, in the expression<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 a << (b << c)</font><br><font face=3D"arial, helv=
etica, sans-serif">=C2=A0 =C2=A0 </font><font face=3D"monospace, monospace"=
>a</font><font face=3D"arial, helvetica, sans-serif"> will be shifted by th=
e result of the </font><font face=3D"monospace, monospace">b << c</fo=
nt><font face=3D"arial, helvetica, sans-serif"> shift.=C2=A0 For that to ha=
ppen, we require that </font><font face=3D"monospace, monospace">b <<=
c</font><font face=3D"arial, helvetica, sans-serif"> must be run first.</f=
ont></div><div><font face=3D"arial, helvetica, sans-serif">=C2=A0 =C2=A0 Th=
ere's no argument there.<br><br>=C2=A0 =C2=A0 Therefore,=C2=A0</font>th=
e committee ruled that the RHS of the <font face=3D"monospace, monospace">a=
<< x </font>expression (with <font face=3D"monospace, monospace">x :=
=3D b << c</font>) should be evaluated first.<br>=C2=A0 =C2=A0 So shi=
fts should have evaluation from the right to the left.<br><br>See how that =
works?</div></div></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/CAHSYqda11wvCRdjtihSStD%3DiO9Qzkf38vE=
aaBBLXCv305ZKDww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda11wvCRd=
jtihSStD%3DiO9Qzkf38vEaaBBLXCv305ZKDww%40mail.gmail.com</a>.<br />
--001a1140846866edbf05379b1d41--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 14 Jul 2016 12:52:27 -0400
Raw View
On 2016-07-14 11:50, Hyman Rosen wrote:
> On Wed, Jul 13, 2016 at 9:37 PM, FrankHB1989 wrote:
>> At least my opinion is not only for C++. Particularly, C++ is complicated
>> enough. So I doubt any modification of rules can be easily settle down
>> without confusion. The latter is not against to any concrete proposal, but
>> it counts.
>
> Strict left-to-right simplifies the rules. It cannot be more confusing to
> specify an order than to leave the order unspecified.
Okay... I'll dispute that.
If order is unspecified, and code is correct only for a certain order,
then I know that code is broken.
If order is specified, then I have to understand *how* the order is
specified in order to know if order-dependent code is correct or broken.
Therefore, the knowledge required to make a determination as to the
correctness of code is *increased* by specified order.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm8g2h%24ua9%241%40ger.gmane.org.
.
Author: Ren Industries <renindustries@gmail.com>
Date: Thu, 14 Jul 2016 14:01:43 -0400
Raw View
--001a11c017d4815b7805379c4b34
Content-Type: text/plain; charset=UTF-8
This is pointedly not true of C++; it is not used to direct the operations
of a computer, but instead, an abstract machine. One could easily process
C++ into paper and execute it through an automata. As well, these are
merely your opinions; many languages do not think the same way you do; C++
is all about speed and removing abstractions, not about making it easier.
Many things that would make your life as a programmer easier come at a
cost, and one defining characteristic of C++ is not paying for that which
you don't use.
If I don't need sequencing, I do not wish to pay for it! If I do, I will
rewrite it to be slightly more verbose and use semi colons to make my
intent clear! What about this is difficult to understand?
On Thu, Jul 14, 2016 at 12:11 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Wed, Jul 13, 2016 at 11:02 PM, FrankHB1989 <frankhb1989@gmail.com>
> wrote:
>>
>> Or do you really believe there can only be one evaluation order in the
>> world, or users of C++ should not touch any one of them other than
>> left-to-right order?
>>
>
> Yes. A programming language is used to direct the operations of a
> computer. The constructs of the language should be precisely defined so
> that the programmer does not write ambiguous directions. The constructs of
> the language should be defined so that it is not easy for programmers to
> unwittingly write ambiguous directions.
>
> --
> 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/CAHSYqdbk9e31GOfZbhanpti%3DwuP3CqrHZ6Q%3DHFJYyM-hj%3DRq-Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbk9e31GOfZbhanpti%3DwuP3CqrHZ6Q%3DHFJYyM-hj%3DRq-Q%40mail.gmail.com?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/CAMD6iD-H9Sb0sGvKBHDxMxGM57EjNx%2BXkzCQQ2J9XwCihZ1u%3DA%40mail.gmail.com.
--001a11c017d4815b7805379c4b34
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is pointedly not true of C++; it is not used to direc=
t the operations of a computer, but instead, an abstract machine. One could=
easily process C++ into paper and execute it through an automata. As well,=
these are merely your opinions; many languages do not think the same way y=
ou do; C++ is all about speed and removing abstractions, not about making i=
t easier. Many things that would make your life as a programmer easier come=
at a cost, and one defining characteristic of C++ is not paying for that w=
hich you don't use.<div><br></div><div>If I don't need sequencing, =
I do not wish to pay for it! If I do, I will rewrite it to be slightly more=
verbose and use semi colons to make my intent clear! What about this is di=
fficult to understand?</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Jul 14, 2016 at 12:11 PM, Hyman Rosen <span dir=3D=
"ltr"><<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.=
rosen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span c=
lass=3D"">On Wed, Jul 13, 2016 at 11:02 PM, FrankHB1989 <span dir=3D"ltr">&=
lt;<a href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@g=
mail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>Or do you really believe there can only be one evaluation order in =
the world, or users of C++ should not touch any one of them other than left=
-to-right order?</div></div></blockquote></span><div><br>Yes.=C2=A0 A progr=
amming language is used to direct the operations of a computer.=C2=A0 The c=
onstructs of the language should be precisely defined so that the programme=
r does not write ambiguous directions.=C2=A0 The constructs of the language=
should be defined so that it is not easy for programmers to unwittingly wr=
ite ambiguous directions.</div></div></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" 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@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/CAHSYqdbk9e31GOfZbhanpti%3DwuP3CqrHZ6=
Q%3DHFJYyM-hj%3DRq-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdbk9e31GOfZbhanpti%3DwuP3CqrHZ6Q%3DHFJYyM-hj%3DRq-Q%40mail=
..gmail.com</a>.<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" 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/CAMD6iD-H9Sb0sGvKBHDxMxGM57EjNx%2BXkz=
CQQ2J9XwCihZ1u%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-H9Sb0=
sGvKBHDxMxGM57EjNx%2BXkzCQQ2J9XwCihZ1u%3DA%40mail.gmail.com</a>.<br />
--001a11c017d4815b7805379c4b34--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 14:11:10 -0400
Raw View
--94eb2c06fb2e5c81ba05379c6e1e
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 12:52 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2016-07-14 11:50, Hyman Rosen wrote:
> > Strict left-to-right simplifies the rules. It cannot be more confusing
> to
> > specify an order than to leave the order unspecified.
>
> Okay... I'll dispute that.
>
> If order is unspecified, and code is correct only for a certain order,
> then I know that code is broken.
>
> If order is specified, then I have to understand *how* the order is
> specified in order to know if order-dependent code is correct or broken.
>
> Therefore, the knowledge required to make a determination as to the
> correctness of code is *increased* by specified order.
I would argue that increased knowledge implies decreased confusion. More
to the point, knowing that the order is unspecified is itself knowledge.
You say "If order is unspecified, and code is correct only for a certain
order, then I know that code is broken." But that means that you know the
order is unspecified. That is the same quantum of knowledge as knowing
that the order is particular. And the problem with unspecified order is
when programmers do not know that the order is unspecified, or fail to
notice that they are depending on a particular order because the code works
(until it doesn't).
--
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/CAHSYqdb3JZg2VnoiCYXzQsXvdzEkOmLVnetVN_CBY_yNPq5XUQ%40mail.gmail.com.
--94eb2c06fb2e5c81ba05379c6e1e
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, Jul 14, 2016 at 12:52 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border=
-left-color:rgb(204,204,204);padding-left:1ex">On 2016-07-14 11:50, Hyman R=
osen wrote:<span class=3D""><br>
> Strict left-to-right simplifies the rules.=C2=A0 It cannot be more con=
fusing to<br>
> specify an order than to leave the order unspecified.<br>
<br>
</span>Okay... I'll dispute that.<br>
<br>
If order is unspecified, and code is correct only for a certain order,<br>
then I know that code is broken.<br>
<br>
If order is specified, then I have to understand *how* the order is<br>
specified in order to know if order-dependent code is correct or broken.<br=
>
<br>
Therefore, the knowledge required to make a determination as to the<br>
correctness of code is *increased* by specified order.</blockquote><div><br=
>I would argue that increased knowledge implies decreased confusion.=C2=A0 =
More to the point, knowing that the order is unspecified is itself knowledg=
e.=C2=A0 You say "If order is unspecified, and code is correct only fo=
r a certain order,=C2=A0then I know that code is broken." =C2=A0But th=
at means that you know the order is unspecified.=C2=A0 That is the same qua=
ntum of knowledge as knowing that the order is particular.=C2=A0 And the pr=
oblem with unspecified order is when programmers do not know that the order=
is unspecified, or fail to notice that they are depending on a particular =
order because the code works (until it doesn't).</div></div></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/CAHSYqdb3JZg2VnoiCYXzQsXvdzEkOmLVnetV=
N_CBY_yNPq5XUQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb3JZg2Vnoi=
CYXzQsXvdzEkOmLVnetVN_CBY_yNPq5XUQ%40mail.gmail.com</a>.<br />
--94eb2c06fb2e5c81ba05379c6e1e--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 14:18:42 -0400
Raw View
--001a114c843a56e23a05379c89ee
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renindustries@gmail.com>
wrote:
> This is pointedly not true of C++; it is not used to direct the operations
> of a computer, but instead, an abstract machine.
>
Well, then, let's buy an abstract machine that's 4% faster and evaluate our
function arguments left-to-right.
> C++ is all about speed and removing abstractions, not about making it
> easier.
>
Abstract machines have speed? Programming in C++ is about removing
abstractions? What an odd claim!
> Many things that would make your life as a programmer easier come at a
> cost, and one defining characteristic of C++ is not paying for that which
> you don't use.
>
The problem is that people accidentally do use sequencing, and then do pay
for it in errors down the line.
> If I don't need sequencing, I do not wish to pay for it! If I do, I will
> rewrite it to be slightly more verbose and use semi colons to make my
> intent clear! What about this is difficult to understand?
>
The fact that C++ makes you pay for sequencing when you write
int x[2] = { a(), b() };
indicates that the language is not interested in eliminating sequencing as
a cost. What about this is difficult to understand?
--
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/CAHSYqdb4%3DDpXGsdkAW%2B-CXxc9ELvzMuvHnTnKoEE8%3DYH-7cPpA%40mail.gmail.com.
--001a114c843a56e23a05379c89ee
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, Jul 14, 2016 at 2:01 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">This is point=
edly not true of C++; it is not used to direct the operations of a computer=
, but instead, an abstract machine.</div></blockquote><div><br>Well, then, =
let's buy an abstract machine that's 4% faster and evaluate our fun=
ction arguments left-to-right.<br><br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">C++ is all about speed and removing abstractions, not about making=
it easier.</div></blockquote><div><br>Abstract machines have speed?=C2=A0 =
Programming in C++ is about removing abstractions?=C2=A0 What an odd claim!=
<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"> Many things that would m=
ake your life as a programmer easier come at a cost, and one defining chara=
cteristic of C++ is not paying for that which you don't use.</div></blo=
ckquote><div><br>The problem is that people accidentally do use sequencing,=
and then do pay for it in errors down the line.<br>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>If I don't need sequencing, I do not wish t=
o pay for it! If I do, I will rewrite it to be slightly more verbose and us=
e semi colons to make my intent clear! What about this is difficult to unde=
rstand?</div></div></blockquote><div><br>The fact that C++ makes you pay fo=
r sequencing when you write<br><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 int x[2] =3D { a(), b() };<br></font><font face=3D"arial, helvetica,=
sans-serif">indicates that the language is not interested in eliminating s=
equencing as a cost. =C2=A0</font>What about this is difficult to understan=
d?</div></div></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/CAHSYqdb4%3DDpXGsdkAW%2B-CXxc9ELvzMuv=
HnTnKoEE8%3DYH-7cPpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb4%3=
DDpXGsdkAW%2B-CXxc9ELvzMuvHnTnKoEE8%3DYH-7cPpA%40mail.gmail.com</a>.<br />
--001a114c843a56e23a05379c89ee--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Thu, 14 Jul 2016 14:23:42 -0400
Raw View
--001a11414c541f412e05379c9a01
Content-Type: text/plain; charset=UTF-8
We can certainly talk about the speed or efficiency of abstract machines,
yes.
That is not a problem with the language, that is a problem with people
failing to use the language correctly; if you wish to propose some syntax
to force a left to right sequence to ameliorate that issue, that is
perfectly fine. But removing the expressiveness of the language to help
those ill informed in its use beggars belief.
C++ doesn't make you pay for sequencing if both of those statements are
side-effect free (pure). It could easily reorder both a() and b() to be
faster, in that case. What about that opportunity being lost being a bad
thing is difficult to understand?
On Thu, Jul 14, 2016 at 2:18 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> This is pointedly not true of C++; it is not used to direct the
>> operations of a computer, but instead, an abstract machine.
>>
>
> Well, then, let's buy an abstract machine that's 4% faster and evaluate
> our function arguments left-to-right.
>
>
>
>> C++ is all about speed and removing abstractions, not about making it
>> easier.
>>
>
> Abstract machines have speed? Programming in C++ is about removing
> abstractions? What an odd claim!
>
>
>> Many things that would make your life as a programmer easier come at a
>> cost, and one defining characteristic of C++ is not paying for that which
>> you don't use.
>>
>
> The problem is that people accidentally do use sequencing, and then do pay
> for it in errors down the line.
>
>
>> If I don't need sequencing, I do not wish to pay for it! If I do, I will
>> rewrite it to be slightly more verbose and use semi colons to make my
>> intent clear! What about this is difficult to understand?
>>
>
> The fact that C++ makes you pay for sequencing when you write
> int x[2] = { a(), b() };
> indicates that the language is not interested in eliminating sequencing as
> a cost. What about this is difficult to understand?
>
> --
> 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/CAHSYqdb4%3DDpXGsdkAW%2B-CXxc9ELvzMuvHnTnKoEE8%3DYH-7cPpA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb4%3DDpXGsdkAW%2B-CXxc9ELvzMuvHnTnKoEE8%3DYH-7cPpA%40mail.gmail.com?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/CAMD6iD_KA%3DMAV%2BLqpnGHn9yBTinfj0FPnsEpkMq7wQQoALtT6Q%40mail.gmail.com.
--001a11414c541f412e05379c9a01
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>We can certainly talk about the speed or efficiency o=
f abstract machines, yes.=C2=A0</div><div><br></div><div>That is not a prob=
lem with the language, that is a problem with people failing to use the lan=
guage correctly; if you wish to propose some syntax to force a left to righ=
t sequence to ameliorate that issue, that is perfectly fine. But removing t=
he expressiveness of the language to help those ill informed in its use beg=
gars belief.</div><div><br></div><div>C++ doesn't make you pay for sequ=
encing if both of those statements are side-effect free (pure). It could ea=
sily reorder both a() and b() to be faster, in that case. What about that o=
pportunity being lost being a bad thing is difficult to understand?</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 1=
4, 2016 at 2:18 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hym=
an.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 14, 2016 =
at 2:01 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto:renindus=
tries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">This is pointedly not true of C+=
+; it is not used to direct the operations of a computer, but instead, an a=
bstract machine.</div></blockquote></span><div><br>Well, then, let's bu=
y an abstract machine that's 4% faster and evaluate our function argume=
nts left-to-right.<br><br>=C2=A0</div><span class=3D""><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr">C++ is all about speed and removing abstractions, not about m=
aking it easier.</div></blockquote></span><div><br>Abstract machines have s=
peed?=C2=A0 Programming in C++ is about removing abstractions?=C2=A0 What a=
n odd claim!<br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"> Many things that would make your life as a programmer easier come at a=
cost, and one defining characteristic of C++ is not paying for that which =
you don't use.</div></blockquote></span><div><br>The problem is that pe=
ople accidentally do use sequencing, and then do pay for it in errors down =
the line.<br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>If I don't need sequencing, I do not wish to pay for it! If I do,=
I will rewrite it to be slightly more verbose and use semi colons to make =
my intent clear! What about this is difficult to understand?</div></div></b=
lockquote></span><div><br>The fact that C++ makes you pay for sequencing wh=
en you write<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 int x[2] =
=3D { a(), b() };<br></font><font face=3D"arial, helvetica, sans-serif">ind=
icates that the language is not interested in eliminating sequencing as a c=
ost. =C2=A0</font>What about this is difficult to understand?</div></div></=
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" 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@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/CAHSYqdb4%3DDpXGsdkAW%2B-CXxc9ELvzMuv=
HnTnKoEE8%3DYH-7cPpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdb4%3DDpXGsdkAW%2B-CXxc9ELvzMuvHnTnKoEE8%3DYH-7cPpA%40mail=
..gmail.com</a>.<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" 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/CAMD6iD_KA%3DMAV%2BLqpnGHn9yBTinfj0FP=
nsEpkMq7wQQoALtT6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_KA%3D=
MAV%2BLqpnGHn9yBTinfj0FPnsEpkMq7wQQoALtT6Q%40mail.gmail.com</a>.<br />
--001a11414c541f412e05379c9a01--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 14:31:39 -0400
Raw View
--94eb2c06fb2ea5871805379cb778
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 2:23 PM, Ren Industries <renindustries@gmail.com>
wrote:
>
> That is not a problem with the language, that is a problem with people
> failing to use the language correctly;
>
No, it is a problem with language designers who pride themselves on
creating tools that sever fingers, and on people who feel superior because
they still have all of theirs. When using the language "correctly" is
error-prone, including engendering errors that remain latent for years
before manifesting, then the language is incorrect.
if you wish to propose some syntax to force a left to right sequence to
> ameliorate that issue, that is perfectly fine. But removing the
> expressiveness of the language to help those ill informed in its use
> beggars belief.
>
Except that no one (with probability 1) uses this supposed expressiveness
to deliberately request unspecified order. They either don't care, or
they're making a mistake.
C++ doesn't make you pay for sequencing if both of those statements are
> side-effect free (pure). It could easily reorder both a() and b() to be
> faster, in that case. What about that opportunity being lost being a bad
> thing is difficult to understand?
>
Huh? Of course we're only talking about subexpressions with side effects.
If there are no side effects, the as-if rules let the computations proceed
in any order, with or without language changes.
--
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/CAHSYqdb0J07u6drtxOeMZ-h%3DPUfp7gmv6k_-vmije-d0rsunYw%40mail.gmail.com.
--94eb2c06fb2ea5871805379cb778
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, Jul 14, 2016 at 2:23 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>That is not a problem with the language, that is a problem with people fa=
iling to use the language correctly;</div></div></blockquote><div><br>No, i=
t is a problem with language designers who pride themselves on creating too=
ls that sever fingers, and on people who feel superior because they still h=
ave all of theirs.=C2=A0 When using the language "correctly" is e=
rror-prone, including engendering errors that remain latent for years befor=
e manifesting, then the language is incorrect.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div> if you wish to propose some syntax t=
o force a left to right sequence to ameliorate that issue, that is perfectl=
y fine. But removing the expressiveness of the language to help those ill i=
nformed in its use beggars belief.</div></div></blockquote><div><br>Except =
that no one (with probability 1) uses this supposed expressiveness to delib=
erately request unspecified order.=C2=A0 They either don't care, or the=
y're making a mistake.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>C++ doesn't make you pay for sequencing if both of th=
ose statements are side-effect free (pure). It could easily reorder both a(=
) and b() to be faster, in that case. What about that opportunity being los=
t being a bad thing is difficult to understand?</div></div></blockquote><di=
v><br>Huh?=C2=A0 Of course we're only talking about subexpressions with=
side effects.=C2=A0 If there are no side effects, the as-if rules let the =
computations proceed in any order, with or without language changes.</div><=
/div></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/CAHSYqdb0J07u6drtxOeMZ-h%3DPUfp7gmv6k=
_-vmije-d0rsunYw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb0J07u6d=
rtxOeMZ-h%3DPUfp7gmv6k_-vmije-d0rsunYw%40mail.gmail.com</a>.<br />
--94eb2c06fb2ea5871805379cb778--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 14 Jul 2016 19:35:15 +0100
Raw View
--001a114757866a986405379cc3a8
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 7:18 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> This is pointedly not true of C++; it is not used to direct the
>> operations of a computer, but instead, an abstract machine.
>>
>
> Well, then, let's buy an abstract machine that's 4% faster and evaluate
> our function arguments left-to-right.
>
There are no machines that are 4% faster, certainly not at a reasonable
price.
> Many things that would make your life as a programmer easier come at a
>> cost, and one defining characteristic of C++ is not paying for that which
>> you don't use.
>>
>
> The problem is that people accidentally do use sequencing, and then do pay
> for it in errors down the line.
>
Yes, that is a problem. It is not enough of a problem to justify the damage
incurred by your preferred solution. One does not amputate an arm to deal
with a hangnail.
If I don't need sequencing, I do not wish to pay for it! If I do, I will
>> rewrite it to be slightly more verbose and use semi colons to make my
>> intent clear! What about this is difficult to understand?
>>
>
> The fact that C++ makes you pay for sequencing when you write
> int x[2] = { a(), b() };
> indicates that the language is not interested in eliminating sequencing as
> a cost. What about this is difficult to understand?
>
That's unfortunate, but it's easy to work around:
auto x = std::make_array(a(), b());
--
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/CAJnLdObx9NmKJe9LR63v%3DSZjBijViPkFDMdeAgoa2u%3Dw0vcBGQ%40mail.gmail.com.
--001a114757866a986405379cc3a8
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, Jul 14, 2016 at 7:18 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"m=
ailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>>=
;</span> wrote:<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"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 2:01 =
PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto:renindustries@gm=
ail.com" target=3D"_blank">renindustries@gmail.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr">This is pointedly not true of C++; it is=
not used to direct the operations of a computer, but instead, an abstract =
machine.</div></blockquote><div><br>Well, then, let's buy an abstract m=
achine that's 4% faster and evaluate our function arguments left-to-rig=
ht.<br></div></div></div></div></blockquote><div><br></div><div>There are n=
o machines that are 4% faster, certainly not at a reasonable price.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">Many things that would make your life as a programmer easier come at a c=
ost, and one defining characteristic of C++ is not paying for that which yo=
u don't use.</div></blockquote><div><br>The problem is that people acci=
dentally do use sequencing, and then do pay for it in errors down the line.=
<br></div></div></div></div></blockquote><div><br></div><div>Yes, that is a=
problem. It is not enough of a problem to justify the damage incurred by y=
our preferred solution. One does not amputate an arm to deal with a hangnai=
l.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>If I don't need sequencing, I do not wish to pay for it! =
If I do, I will rewrite it to be slightly more verbose and use semi colons =
to make my intent clear! What about this is difficult to understand?</div><=
/div></blockquote><div><br>The fact that C++ makes you pay for sequencing w=
hen you write<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 int x[2]=
=3D { a(), b() };<br></font><font face=3D"arial, helvetica, sans-serif">in=
dicates that the language is not interested in eliminating sequencing as a =
cost. =C2=A0</font>What about this is difficult to understand?</div></div><=
/div></div></blockquote><div><br></div><div>That's unfortunate, but it&=
#39;s easy to work around:</div><div><br></div><div><font face=3D"monospace=
, monospace">auto x =3D std::make_array(a(), b());=C2=A0</font></div></div>=
</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/CAJnLdObx9NmKJe9LR63v%3DSZjBijViPkFDM=
deAgoa2u%3Dw0vcBGQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObx9NmK=
Je9LR63v%3DSZjBijViPkFDMdeAgoa2u%3Dw0vcBGQ%40mail.gmail.com</a>.<br />
--001a114757866a986405379cc3a8--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 14 Jul 2016 13:35:19 -0500
Raw View
--001a113bf560018af405379cc67c
Content-Type: text/plain; charset=UTF-8
On 13 July 2016 at 21:30, FrankHB1989 <frankhb1989@gmail.com> wrote:
> Further, you said you had found that designers of Java made the choice you
> want, but you seem to deliberately ignore the related notes in Java
> Language Specification (as I mentioned more than once), which tells you
> that the designers of Java do not like the idea about relying on such rules.
Which leads to the following weirdness:
1. You can't write correct code in C++ today which depends on order of
evaluation
2. Hey, let's tighten the rules and pay a performance cost so people can
write code which depends on order of evaluation
3. But we should still *highly discourage* people from writing code which
depends on order of evaluation
The LTR folks think code such as:
char z[] = "abcde";
char* p = z;
*++p = *++p = *++p; // "addde"
is both reasonable to write and the only obviously correct answer is
"addde". I think code like this should be avoided and interleaving order
of evaluation, associativity and order of precedence actually makes things
harder to understand for non-experts, because they have to be able to read
and understand code like I just presented.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BNCszd%3Do4ogwWViVyNkuawnSaJ41setPg%2BhH5bOk-za%3DQ%40mail.gmail.com.
--001a113bf560018af405379cc67c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 13 July 2016 at 21:30, Frank=
HB1989 <span dir=3D"ltr"><<a href=3D"mailto:frankhb1989@gmail.com" targe=
t=3D"_blank">frankhb1989@gmail.com</a>></span> wrote:<br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Further, you said you had found =
that designers of Java made the choice you want, but you seem to deliberate=
ly ignore the related notes in Java Language Specification (as I mentioned =
more than once), which tells you that the designers of Java do not like the=
idea about relying on such rules.</blockquote></div><br>Which leads to the=
following weirdness:</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">1.=C2=A0 You can't write correct code in C++ today whi=
ch depends on order of evaluation</div><div class=3D"gmail_extra">2.=C2=A0 =
Hey, let's tighten the rules and pay a performance cost so people can w=
rite code which depends on order of evaluation</div><div class=3D"gmail_ext=
ra">3.=C2=A0 But we should still=C2=A0<i>highly discourage</i>=C2=A0people =
from writing code which depends on order of evaluation</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gm=
ail_extra">The LTR folks think code such as:</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">char z[] =3D "abcde";</div=
><div class=3D"gmail_extra">char* p =3D z;</div><div class=3D"gmail_extra">=
<div>*++p =3D *++p =3D *++p; =C2=A0// "addde"</div><div><br></div=
><div>is both reasonable to write and the only obviously correct answer is =
"addde".=C2=A0 I think code like this should be avoided and inter=
leaving order of evaluation, associativity and order of precedence actually=
makes things harder to understand for non-experts, because they have to be=
able to read and understand code like I just presented.</div><div>--=C2=A0=
</div><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><di=
v dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=
=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></=
div></div>
</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/CAGg_6%2BNCszd%3Do4ogwWViVyNkuawnSaJ4=
1setPg%2BhH5bOk-za%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
NCszd%3Do4ogwWViVyNkuawnSaJ41setPg%2BhH5bOk-za%3DQ%40mail.gmail.com</a>.<br=
/>
--001a113bf560018af405379cc67c--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Thu, 14 Jul 2016 20:45:57 +0200
Raw View
Am 14.07.2016 um 18:52 schrieb Matthew Woehlke:
> On 2016-07-14 11:50, Hyman Rosen wrote:
>> On Wed, Jul 13, 2016 at 9:37 PM, FrankHB1989 wrote:
>>> At least my opinion is not only for C++. Particularly, C++ is complicated
>>> enough. So I doubt any modification of rules can be easily settle down
>>> without confusion. The latter is not against to any concrete proposal, but
>>> it counts.
>> Strict left-to-right simplifies the rules. It cannot be more confusing to
>> specify an order than to leave the order unspecified.
> Okay... I'll dispute that.
>
> If order is unspecified, and code is correct only for a certain order,
> then I know that code is broken.
How do you know it is correct only for a certain order if none of the
compilers you or your organization is using compile in the "wrong"
order? You first have to find out that it does rely on a certain order
for you to know it is broken.
>
> If order is specified, then I have to understand *how* the order is
> specified in order to know if order-dependent code is correct or broken.
Or you have a consistent test result regardless of compiler, platform or
hardware.
>
> Therefore, the knowledge required to make a determination as to the
> correctness of code is *increased* by specified order.
>
If order is unspecified a vigilant maintainer has to check the
implementation/documentation of functions in subexpressions to determine
whether there is a latent bug because, unless you have a compiler that
happens to always evaluate in the "wrong" order, you will never know
your code has a bug without running it in your head.
If order is specified the bug becomes apparent as it manifests always
regardless of compiler. Any automated tests will have the same outcome
on every developer machine or build server. If the subexpressions do
rely on being called in a certain order the code is not broken because
the rules of the language clearly define it.
For a maintainer the status quo is "this code contains unordered
subexpressions, I wonder if that is a bug or not, let's go digging".
--
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/10f6e7bd-467a-ad71-5dac-77423a245790%40gmail.com.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 14 Jul 2016 13:46:55 -0500
Raw View
--001a113df1367c9b1b05379cef0a
Content-Type: text/plain; charset=UTF-8
On 14 July 2016 at 13:18, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> This is pointedly not true of C++; it is not used to direct the
>> operations of a computer, but instead, an abstract machine.
>>
>
> Well, then, let's buy an abstract machine that's 4% faster and evaluate
> our function arguments left-to-right.
>
It's great that you live in a utopia where performance, latency, power and
cost never, ever matters.
I'm not in that world.
When I buy a laptop or a cell phone, I care about battery life, and code
that takes more cycles tends to use more power.
There are industries (such as HFT) where speed of calculation is directly
tied to profitability.
There are industries (such as embedded) where using a faster processor
means they have to charge more for their product and customers just don't
want to pay.
Etc., etc.
What I don't understand is why you aren't just writing everything in Java,
since it's well-definedness is a much better fit for your unconstrained
utopian world.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BP4MRKwnWYk6efwJqcBC4aqKq_jgM%3DLHVBXgENF2z5Yig%40mail.gmail.com.
--001a113df1367c9b1b05379cef0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 14 July 2016 at 13:18, Hyman Rosen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gm=
ail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 14, 201=
6 at 2:01 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto:renind=
ustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">This is pointedly not true of =
C++; it is not used to direct the operations of a computer, but instead, an=
abstract machine.</div></blockquote></span><div><br>Well, then, let's =
buy an abstract machine that's 4% faster and evaluate our function argu=
ments left-to-right.<br></div></div></div></div></blockquote><div><br></div=
><div>It's great that you live in a utopia where performance, latency, =
power and cost never, ever matters.</div><div><br></div><div>I'm not in=
that world.</div><div><br></div><div>When I buy a laptop or a cell phone, =
I care about battery life, and code that takes more cycles tends to use mor=
e power.</div><div><br></div><div>There are industries (such as HFT) where =
speed of calculation is directly tied to profitability.</div><div><br></div=
><div>There are industries (such as embedded) where using a faster processo=
r means they have to charge more for their product and customers just don&#=
39;t want to pay.</div><div><br></div><div>Etc., etc.</div><div><br></div><=
div>What I don't understand is why you aren't just writing everythi=
ng in Java, since it's well-definedness is a much better fit for your u=
nconstrained utopian world.</div></div>-- <br><div class=3D"gmail_signature=
" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"=
><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:=
nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =
=C2=A0+1-847-691-1404</div></div></div></div></div>
</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/CAGg_6%2BP4MRKwnWYk6efwJqcBC4aqKq_jgM=
%3DLHVBXgENF2z5Yig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP4MR=
KwnWYk6efwJqcBC4aqKq_jgM%3DLHVBXgENF2z5Yig%40mail.gmail.com</a>.<br />
--001a113df1367c9b1b05379cef0a--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 14:53:25 -0400
Raw View
--001a1144db3e7eee8605379d056f
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 2:35 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 13 July 2016 at 21:30, FrankHB1989 <frankhb1989@gmail.com> wrote:
> 1. You can't write correct code in C++ today which depends on order of
> evaluation
>
But people write incorrect code that depends on order of evaluation without
realizing it.
> 2. Hey, let's tighten the rules and pay a performance cost so people can
> write code which depends on order of evaluation
>
The performance cost should be balanced against the correctness cost.
> 3. But we should still *highly discourage* people from writing code
> which depends on order of evaluation
>
No, we should not do that. That's a historical anomaly based on poor
design decisions. (It's all because if you push arguments right-to-left
then you can write a printf(...) which can handle an arbitrary number of
arguments by incrementing a pointer that starts at the first parameter.)
We should discourage people from writing code that is difficult to
understand.
> The LTR folks think code such as:
>
> char z[] = "abcde";
> char* p = z;
> *++p = *++p = *++p; // "addde"
>
> is both reasonable to write and the only obviously correct answer is
> "addde". I think code like this should be avoided and interleaving order
> of evaluation, associativity and order of precedence actually makes things
> harder to understand for non-experts, because they have to be able to read
> and understand code like I just presented.
>
It is not reasonable to write because the multiple increments and
indirections make it difficult to understand. But "clever" code has been
with us since K&R, when they wrote *strcpy* as while (*to++ = *from++);.
Whether or not this code is reasonable, similar code is, and it is
unreasonable to demand that the language leave its meaning unspecified. If
a meaning is to be assigned, LTR is the simplest and best rule.
--
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/CAHSYqdb2KFdb_FU_LzfCGY%3D6Hxa%3DwG0jSjUvF%2BxuvMikTzpTSQ%40mail.gmail.com.
--001a1144db3e7eee8605379d056f
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, Jul 14, 2016 at 2:35 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><span class=3D"">On 13 July 2016 at 21:30, FrankHB1989 <span dir=3D"=
ltr"><<a href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb=
1989@gmail.com</a>></span> wrote:</span></div><div class=3D"gmail_extra"=
>1.=C2=A0 You can't write correct code in C++ today which depends on or=
der of evaluation</div></div></blockquote><div><br>But people write incorre=
ct code that=C2=A0depends on order of evaluation without realizing it.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">2.=
=C2=A0 Hey, let's tighten the rules and pay a performance cost so peopl=
e can write code which depends on order of evaluation</div></div></blockquo=
te><div><br>The performance cost should be balanced against the correctness=
cost.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_extra">3.=C2=A0 But we should still=C2=A0<i>highly discourage</i>=C2=A0peo=
ple from writing code which depends on order of evaluation</div></div></blo=
ckquote><div><br>No, we should not do that.=C2=A0 That's a historical a=
nomaly based on poor design decisions. =C2=A0(It's all because if you p=
ush arguments right-to-left then you can write a printf(...) which can hand=
le an arbitrary number of arguments by incrementing a pointer that starts a=
t the first parameter.) =C2=A0We should discourage people from writing code=
that is difficult to understand.<br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra">The LTR folks think code such as:</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">char z[] =
=3D "abcde";</div><div class=3D"gmail_extra">char* p =3D z;</div>=
<div class=3D"gmail_extra"><div>*++p =3D *++p =3D *++p; =C2=A0// "addd=
e"</div><div><br></div><div>is both reasonable to write and the only o=
bviously correct answer is "addde".=C2=A0 I think code like this =
should be avoided and interleaving order of evaluation, associativity and o=
rder of precedence actually makes things harder to understand for non-exper=
ts, because they have to be able to read and understand code like I just pr=
esented.</div></div></div></blockquote><div><br>It is not reasonable to wri=
te because the multiple increments and indirections make it difficult to un=
derstand.=C2=A0 But "clever" code has been with us since K&R,=
when they wrote <b>strcpy</b> as <font face=3D"monospace, monospace">while=
(*to++ =3D *from++);</font>.=C2=A0 Whether or not this code is reasonable,=
similar code is, and it is unreasonable to demand that the language leave =
its meaning unspecified.=C2=A0 If a meaning is to be assigned, LTR is the s=
implest and best rule.<br></div></div></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/CAHSYqdb2KFdb_FU_LzfCGY%3D6Hxa%3DwG0j=
SjUvF%2BxuvMikTzpTSQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb2KF=
db_FU_LzfCGY%3D6Hxa%3DwG0jSjUvF%2BxuvMikTzpTSQ%40mail.gmail.com</a>.<br />
--001a1144db3e7eee8605379d056f--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Thu, 14 Jul 2016 21:02:23 +0200
Raw View
This is a multi-part message in MIME format.
--------------8671CCA7C6491C654FCD1012
Content-Type: text/plain; charset=UTF-8; format=flowed
Am 14.07.2016 um 20:35 schrieb Nevin Liber:
> On 13 July 2016 at 21:30, FrankHB1989 <frankhb1989@gmail.com
> <mailto:frankhb1989@gmail.com>> wrote:
>
> Further, you said you had found that designers of Java made the
> choice you want, but you seem to deliberately ignore the related
> notes in Java Language Specification (as I mentioned more than
> once), which tells you that the designers of Java do not like the
> idea about relying on such rules.
>
>
> Which leads to the following weirdness:
>
> 1. You can't write correct code in C++ today which depends on order
> of evaluation
> 2. Hey, let's tighten the rules and pay a performance cost so people
> can write code which depends on order of evaluation
> 3. But we should still /highly discourage/ people from writing code
> which depends on order of evaluation
The questions is why did they put that discouragement in there. My
speculation is the Java implementers came from a C/C++ background and
were bitten by the undefined order enough times to have it ingrained in
their subconscience so even though they eliminated that trap from their
new language they still couldn't shake off their habits. But unless we
actually go and ask the person who put that statement in the language
specification we won't know.
>
>
> The LTR folks think code such as:
>
> char z[] = "abcde";
> char* p = z;
> *++p = *++p = *++p; // "addde"
>
> is both reasonable to write and the only obviously correct answer is
> "addde". I think code like this should be avoided and interleaving
> order of evaluation, associativity and order of precedence actually
> makes things harder to understand for non-experts, because they have
> to be able to read and understand code like I just presented.
I don't know what people think but complicated code is still complicated.
Without a specified order there obviously is no "obviously correct
answer" but once *a* order is specified that changes and we know exactly
what the answer is and can reason about how the code came to that result
and whether it's the result we wanted it to produce or not.
--
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/0de4c156-f315-6928-7f66-54e8fdf597ac%40gmail.com.
--------------8671CCA7C6491C654FCD1012
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 14.07.2016 um 20:35 schrieb Nevin Liber:<br>
<blockquote
cite=3D"mid:CAGg_6+NCszd=3Do4ogwWViVyNkuawnSaJ41setPg+hH5bOk-za=3DQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">On 13 July 2016 at 21:30, FrankHB1989 <s=
pan
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frank=
hb1989@gmail.com</a>></span>
wrote:<br>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Further,
you said you had found that designers of Java made the
choice you want, but you seem to deliberately ignore the
related notes in Java Language Specification (as I
mentioned more than once), which tells you that the
designers of Java do not like the idea about relying on
such rules.</blockquote>
</div>
<br>
Which leads to the following weirdness:</div>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">1.=C2=A0 You can't write correct code in=
C++
today which depends on order of evaluation</div>
<div class=3D"gmail_extra">2.=C2=A0 Hey, let's tighten the rules an=
d
pay a performance cost so people can write code which depends
on order of evaluation</div>
<div class=3D"gmail_extra">3.=C2=A0 But we should still=C2=A0<i>hig=
hly
discourage</i>=C2=A0people from writing code which depends on
order of evaluation</div>
</div>
</blockquote>
The questions is why did they put that discouragement in there. My
speculation is the Java implementers came from a C/C++ background
and were bitten by the undefined order enough times to have it
ingrained in their subconscience so even though they eliminated that
trap from their new language they still couldn't shake off their
habits. But unless we actually go and ask the person who put that
statement in the language specification we won't know.<br>
<blockquote
cite=3D"mid:CAGg_6+NCszd=3Do4ogwWViVyNkuawnSaJ41setPg+hH5bOk-za=3DQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">The LTR folks think code such as:</div>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">char z[] =3D "abcde";</div>
<div class=3D"gmail_extra">char* p =3D z;</div>
<div class=3D"gmail_extra">
<div>*++p =3D *++p =3D *++p; =C2=A0// "addde"</div>
<div><br>
</div>
<div>is both reasonable to write and the only obviously
correct answer is "addde".=C2=A0 I think code like this should =
be
avoided and interleaving order of evaluation, associativity
and order of precedence actually makes things harder to
understand for non-experts, because they have to be able to
read and understand code like I just presented.</div>
</div>
</div>
</blockquote>
I don't know what people think but complicated code is still
complicated.<br>
Without a specified order there obviously is no "obviously correct
answer" but once *a* order is specified that changes and we know
exactly what the answer is and can reason about how the code came to
that result and whether it's the result we wanted it to produce or
not.<br>
</body>
</html>
<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/0de4c156-f315-6928-7f66-54e8fdf597ac%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0de4c156-f315-6928-7f66-54e8fdf597ac%=
40gmail.com</a>.<br />
--------------8671CCA7C6491C654FCD1012--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 15:04:33 -0400
Raw View
--001a1141fcbe55d28505379d2d5e
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 2:46 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 14 July 2016 at 13:18, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
>> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renindustries@gmail.com>
>> wrote:
>>
>>> This is pointedly not true of C++; it is not used to direct the
>>> operations of a computer, but instead, an abstract machine.
>>>
>>
>> Well, then, let's buy an abstract machine that's 4% faster and evaluate
>> our function arguments left-to-right.
>>
>
> It's great that you live in a utopia where performance, latency, power and
> cost never, ever matters.
>
I don't live in that utopia, "Ren Industries" does. In my world, C++ is
used to direct actions of computers, not abstract machines.
What I don't understand is why you aren't just writing everything in Java,
> since it's well-definedness is a much better fit for your unconstrained
> utopian world.
>
I work in whatever language my shop requires. We happen to use C++. I've
programmed in the past using Java.
"If you don't like that the Ford Pinto catches fire, go drive another car."
is not a compelling argument for driving Ford Pintos.
--
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/CAHSYqdbtnAjk5KCNZQ%3DcaKNqERBhCsyRTzXKOYrbCezjbQ4v6A%40mail.gmail.com.
--001a1141fcbe55d28505379d2d5e
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, Jul 14, 2016 at 2:46 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<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"><span =
class=3D"">On 14 July 2016 at 13:18, Hyman Rosen <span dir=3D"ltr"><<a h=
ref=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.co=
m</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Thu, Jul =
14, 2016 at 2:01 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto=
:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">This is pointedly not t=
rue of C++; it is not used to direct the operations of a computer, but inst=
ead, an abstract machine.</div></blockquote></span><div><br>Well, then, let=
's buy an abstract machine that's 4% faster and evaluate our functi=
on arguments left-to-right.<br></div></div></div></div></blockquote><div><b=
r></div></span><div>It's great that you live in a utopia where performa=
nce, latency, power and cost never, ever matters.</div></div></div></div></=
blockquote><div><br>I don't live in that utopia, "Ren Industries&q=
uot; does.=C2=A0 In my world, C++ is used to direct actions of computers, n=
ot abstract machines.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>What I =
don't understand is why you aren't just writing everything in Java,=
since it's well-definedness is a much better fit for your unconstraine=
d utopian world.</div></div></div></div></blockquote><div><br>I work in wha=
tever language my shop requires.=C2=A0 We happen to use C++.=C2=A0 I've=
programmed in the past using Java.<br>"If you don't like that the=
Ford Pinto catches fire, go drive another car." is not a compelling a=
rgument for driving Ford Pintos.</div></div></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/CAHSYqdbtnAjk5KCNZQ%3DcaKNqERBhCsyRTz=
XKOYrbCezjbQ4v6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbtnAjk5K=
CNZQ%3DcaKNqERBhCsyRTzXKOYrbCezjbQ4v6A%40mail.gmail.com</a>.<br />
--001a1141fcbe55d28505379d2d5e--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Thu, 14 Jul 2016 15:06:43 -0400
Raw View
--001a11397e2af3a2c105379d33b0
Content-Type: text/plain; charset=UTF-8
I don't live in that world, *the standard does.* It's defined in terms of
an abstract machine, not practical computers.
On Thu, Jul 14, 2016 at 3:04 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 2:46 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 14 July 2016 at 13:18, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>>
>>> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renindustries@gmail.com
>>> > wrote:
>>>
>>>> This is pointedly not true of C++; it is not used to direct the
>>>> operations of a computer, but instead, an abstract machine.
>>>>
>>>
>>> Well, then, let's buy an abstract machine that's 4% faster and evaluate
>>> our function arguments left-to-right.
>>>
>>
>> It's great that you live in a utopia where performance, latency, power
>> and cost never, ever matters.
>>
>
> I don't live in that utopia, "Ren Industries" does. In my world, C++ is
> used to direct actions of computers, not abstract machines.
>
> What I don't understand is why you aren't just writing everything in Java,
>> since it's well-definedness is a much better fit for your unconstrained
>> utopian world.
>>
>
> I work in whatever language my shop requires. We happen to use C++. I've
> programmed in the past using Java.
> "If you don't like that the Ford Pinto catches fire, go drive another
> car." is not a compelling argument for driving Ford Pintos.
>
> --
> 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/CAHSYqdbtnAjk5KCNZQ%3DcaKNqERBhCsyRTzXKOYrbCezjbQ4v6A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbtnAjk5KCNZQ%3DcaKNqERBhCsyRTzXKOYrbCezjbQ4v6A%40mail.gmail.com?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/CAMD6iD89HghziVudwsvKntqfc322qEgz1j1%2BiGf8Mkeq6anW%2BQ%40mail.gmail.com.
--001a11397e2af3a2c105379d33b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't live in that world, <i>the standard does.</i>=
=C2=A0It's defined in terms of an abstract machine, not practical compu=
ters.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu=
, Jul 14, 2016 at 3:04 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mai=
lto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 14=
, 2016 at 2:46 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On 14 July=
2016 at 13:18, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyman.r=
osen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span> wrot=
e:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><span>On Thu, Jul 14, 2016 at 2:01 PM, Ren Industr=
ies <span dir=3D"ltr"><<a href=3D"mailto:renindustries@gmail.com" target=
=3D"_blank">renindustries@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr">This is pointedly not true of C++; it is not used to di=
rect the operations of a computer, but instead, an abstract machine.</div><=
/blockquote></span><div><br>Well, then, let's buy an abstract machine t=
hat's 4% faster and evaluate our function arguments left-to-right.<br><=
/div></div></div></div></blockquote><div><br></div></span><div>It's gre=
at that you live in a utopia where performance, latency, power and cost nev=
er, ever matters.</div></div></div></div></blockquote></span><div><br>I don=
't live in that utopia, "Ren Industries" does.=C2=A0 In my wo=
rld, C++ is used to direct actions of computers, not abstract machines.<br>=
<br></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>What I don't=
understand is why you aren't just writing everything in Java, since it=
's well-definedness is a much better fit for your unconstrained utopian=
world.</div></div></div></div></blockquote></span><div><br>I work in whate=
ver language my shop requires.=C2=A0 We happen to use C++.=C2=A0 I've p=
rogrammed in the past using Java.<br>"If you don't like that the F=
ord Pinto catches fire, go drive another car." is not a compelling arg=
ument for driving Ford Pintos.</div></div></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" 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@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/CAHSYqdbtnAjk5KCNZQ%3DcaKNqERBhCsyRTz=
XKOYrbCezjbQ4v6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdbtnAjk5KCNZQ%3DcaKNqERBhCsyRTzXKOYrbCezjbQ4v6A%40mail.gmail.c=
om</a>.<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" 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/CAMD6iD89HghziVudwsvKntqfc322qEgz1j1%=
2BiGf8Mkeq6anW%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD89Hghz=
iVudwsvKntqfc322qEgz1j1%2BiGf8Mkeq6anW%2BQ%40mail.gmail.com</a>.<br />
--001a11397e2af3a2c105379d33b0--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 15:10:34 -0400
Raw View
--001a1144db3ee1e80d05379d42e5
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 3:06 PM, Ren Industries <renindustries@gmail.com>
wrote:
> I don't live in that world, *the standard does.* It's defined in terms of
> an abstract machine, not practical computers.
>
The point being what? Compilers, generating code which runs on practical
computers, follow the standard to decide how to do that. What does
abstract machine versus practical computer have to do with whether the
language should define order of evaluation?
--
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/CAHSYqdYCWjtauqQ%2BVfKwmbSgDMbdZa-2AR7%3DPLL%2B_AzM%3DfuDHQ%40mail.gmail.com.
--001a1144db3ee1e80d05379d42e5
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, Jul 14, 2016 at 3:06 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>I don't live in that world, <i>the standard does.</i>=C2=A0It's de=
fined in terms of an abstract machine, not practical computers.</div></bloc=
kquote><div><br>The point being what?=C2=A0 Compilers, generating code whic=
h runs on practical computers, follow the standard to decide how to do that=
..=C2=A0 What does abstract machine versus practical computer have to do wit=
h whether the language should define order of evaluation?=C2=A0</div></div>=
</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/CAHSYqdYCWjtauqQ%2BVfKwmbSgDMbdZa-2AR=
7%3DPLL%2B_AzM%3DfuDHQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYC=
WjtauqQ%2BVfKwmbSgDMbdZa-2AR7%3DPLL%2B_AzM%3DfuDHQ%40mail.gmail.com</a>.<br=
/>
--001a1144db3ee1e80d05379d42e5--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Thu, 14 Jul 2016 15:19:08 -0400
Raw View
--001a1144175c5b382905379d6087
Content-Type: text/plain; charset=UTF-8
The point being that a programming language does not exist to direct the
operations of a computer; it's domain is computer science. Practical
implications, *implementation details*, are not necessarily its domain. You
continually assert how something *should be, *without evidence.
The practical implications of order of evaluation are that they restrict
what can be said in the language, and they restrict what platforms that
language can be ported to *efficiently*. That means it is not simply a
"should" question, despite the fact you repeatedly assert differently. 4%
is not a small barrier; I've often had to restructure code to get less of a
performance gain. I shouldn't have to pay that cost because you believe
people should not have to think about their code as hard.
However, simply adding syntax to enforce a left to right evaluation
strategy solves both of our problems; you can teach people that, and I can
continue to write high performing code. Why no comments on that idea,
beyond your dogmatic approach that something "should" be some way without
evidence?
On Thu, Jul 14, 2016 at 3:10 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 3:06 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> I don't live in that world, *the standard does.* It's defined in terms
>> of an abstract machine, not practical computers.
>>
>
> The point being what? Compilers, generating code which runs on practical
> computers, follow the standard to decide how to do that. What does
> abstract machine versus practical computer have to do with whether the
> language should define order of evaluation?
>
> --
> 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/CAHSYqdYCWjtauqQ%2BVfKwmbSgDMbdZa-2AR7%3DPLL%2B_AzM%3DfuDHQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYCWjtauqQ%2BVfKwmbSgDMbdZa-2AR7%3DPLL%2B_AzM%3DfuDHQ%40mail.gmail.com?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/CAMD6iD-SNxV%2B4SR2aEEuxieWm35UL737%3DRS2wG2oS5HBQe9dUA%40mail.gmail.com.
--001a1144175c5b382905379d6087
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The point being that a programming language does not exist=
to direct the operations of a computer; it's domain is computer scienc=
e. Practical implications, <i>implementation details</i>, are not necessari=
ly its domain. You continually assert how something <i>should be, </i>witho=
ut evidence.=C2=A0<div><br></div><div>The practical implications of order o=
f evaluation are that they restrict what can be said in the language, and t=
hey restrict what platforms that language can be ported to=C2=A0<i>efficien=
tly</i>. That means it is not simply a "should" question, despite=
the fact you repeatedly assert differently. 4% is not a small barrier; I&#=
39;ve often had to restructure code to get less of a performance gain. I sh=
ouldn't have to pay that cost because you believe people should not hav=
e to think about their code as hard.</div><div><br></div><div>However, simp=
ly adding syntax to enforce a left to right evaluation strategy solves both=
of our problems; you can teach people that, and I can continue to write hi=
gh performing code. Why no comments on that idea, beyond your dogmatic appr=
oach that something "should" be some way without evidence?</div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul =
14, 2016 at 3:10 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hy=
man.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 14, 2016=
at 3:06 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto:renindu=
stries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don't live =
in that world, <i>the standard does.</i>=C2=A0It's defined in terms of =
an abstract machine, not practical computers.</div></blockquote></span><div=
><br>The point being what?=C2=A0 Compilers, generating code which runs on p=
ractical computers, follow the standard to decide how to do that.=C2=A0 Wha=
t does abstract machine versus practical computer have to do with whether t=
he language should define order of evaluation?=C2=A0</div></div></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" 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@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/CAHSYqdYCWjtauqQ%2BVfKwmbSgDMbdZa-2AR=
7%3DPLL%2B_AzM%3DfuDHQ%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CAHSYqdYCWjtauqQ%2BVfKwmbSgDMbdZa-2AR7%3DPLL%2B_AzM%3DfuDHQ%=
40mail.gmail.com</a>.<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" 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/CAMD6iD-SNxV%2B4SR2aEEuxieWm35UL737%3=
DRS2wG2oS5HBQe9dUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-SNxV%=
2B4SR2aEEuxieWm35UL737%3DRS2wG2oS5HBQe9dUA%40mail.gmail.com</a>.<br />
--001a1144175c5b382905379d6087--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Thu, 14 Jul 2016 21:41:13 +0200
Raw View
People are using that 4% statement as a thought terminating clich=C3=A9=20
crushing down on any opposing argument with "but 4%!".
What are the details of that test suite?
Which parts ran faster?
Which parts ran slower?
Which parts weren't affected?
Was that code in tight loops or stuff that happens once in a blue moon?
Are those real-world use cases or artifical and unrealistic best-case=20
benchmarks where everything is in hot cache?
Were there more tests running slower or more tests running faster? It=20
only mentions the range, not the distribution.
These are important points to know about this result otherwise "4%" is=20
nothig more than just a number.
--=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/6f91a978-1de6-b349-21a4-354229f7e960%40gmail.com=
..
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 15:43:03 -0400
Raw View
--94eb2c123a1002237805379db734
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 3:19 PM, Ren Industries <renindustries@gmail.com>
wrote:
> The point being that a programming language does not exist to direct the
> operations of a computer; it's domain is computer science. Practical
> implications, *implementation details*, are not necessarily its domain.
> You continually assert how something *should be, *without evidence.
>
If programming languages do not exist to direct the operations of a
computer, and their domain is computer science, then constant factors are
irrelevant. Computer science does not care if algorithms run twice as
fast, it only cares about running speed as asymptotic to a function of
problem size.
In any case, I am not talking about implementation details, I am asking
that the behavior of certain programs which are currently unspecified
should be specified. This strictly increases the number of possible legal
programs. Why is that objectionable for a program that runs on computer
science abstract machines?
The practical implications of order of evaluation are that they restrict
> what can be said in the language, and they restrict what platforms that
> language can be ported to *efficiently*. That means it is not simply a
> "should" question, despite the fact you repeatedly assert differently. 4%
> is not a small barrier; I've often had to restructure code to get less of a
> performance gain. I shouldn't have to pay that cost because you believe
> people should not have to think about their code as hard.
>
That "4%" is a scare number. Looking here
<https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01075.html>, Jason Merrill
says "In my own SPEC runs with an earlier version of the patch, most of the C++
tests did not change significantly, but xalancbmk slowed down about 1%."
However, simply adding syntax to enforce a left to right evaluation
> strategy solves both of our problems; you can teach people that, and I can
> continue to write high performing code. Why no comments on that idea,
> beyond your dogmatic approach that something "should" be some way without
> evidence?
>
Because adding new syntax so that people can choose not to use it and
continue to write potentially broken code is silly, when the change to the
language would not affect the legality or behavior of currently legal
programs.
--
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/CAHSYqdZ-dr49X1GZhdYcheLVSxMB9JO-kSj2o%3DD%3DWxnzBE3eZg%40mail.gmail.com.
--94eb2c123a1002237805379db734
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, Jul 14, 2016 at 3:19 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The point bei=
ng that a programming language does not exist to direct the operations of a=
computer; it's domain is computer science. Practical implications, <i>=
implementation details</i>, are not necessarily its domain. You continually=
assert how something <i>should be, </i>without evidence.</div></blockquote=
><div><br>If programming languages do not exist to direct the operations of=
a computer, and their domain is computer science, then constant factors ar=
e irrelevant.=C2=A0 Computer science does not care if algorithms run twice =
as fast, it only cares about running speed as asymptotic to a function of p=
roblem size.<br><br>In any case, I am not talking about implementation deta=
ils, I am asking that the behavior of certain programs which are currently =
unspecified should be specified.=C2=A0 This strictly increases the number o=
f possible legal programs.=C2=A0 Why is that objectionable for a program th=
at runs on computer science abstract machines?<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div>The practical implications of order of evaluation a=
re that they restrict what can be said in the language, and they restrict w=
hat platforms that language can be ported to=C2=A0<i>efficiently</i>. That =
means it is not simply a "should" question, despite the fact you =
repeatedly assert differently. 4% is not a small barrier; I've often ha=
d to restructure code to get less of a performance gain. I shouldn't ha=
ve to pay that cost because you believe people should not have to think abo=
ut their code as hard.</div></div></blockquote><div><br>That "4%"=
is a scare number.=C2=A0 Looking=C2=A0<a href=3D"https://gcc.gnu.org/ml/gc=
c-patches/2016-06/msg01075.html">here</a>, Jason Merrill says <font face=3D=
"arial, helvetica, sans-serif">"<tt style=3D"color:rgb(0,0,0)">In my o=
wn SPEC runs with an earlier version of the patch, most of the=C2=A0</tt><t=
t style=3D"color:rgb(0,0,0)">C++ tests did not change significantly, but xa=
lancbmk slowed down about=C2=A0</tt><tt style=3D"color:rgb(0,0,0)">1%."=
;</tt><br></font><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>However, =
simply adding syntax to enforce a left to right evaluation strategy solves =
both of our problems; you can teach people that, and I can continue to writ=
e high performing code. Why no comments on that idea, beyond your dogmatic =
approach that something "should" be some way without evidence?</d=
iv></div></blockquote><div><br>Because adding new syntax so that people can=
choose not to use it and continue to write potentially broken code is sill=
y, when the change to the language would not affect the legality or behavio=
r of currently legal programs.</div></div></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/CAHSYqdZ-dr49X1GZhdYcheLVSxMB9JO-kSj2=
o%3DD%3DWxnzBE3eZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-dr49=
X1GZhdYcheLVSxMB9JO-kSj2o%3DD%3DWxnzBE3eZg%40mail.gmail.com</a>.<br />
--94eb2c123a1002237805379db734--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 14 Jul 2016 22:21:11 +0100
Raw View
--001a11493f96ca9be005379f1403
Content-Type: text/plain; charset=UTF-8
On 14 Jul 2016 8:43 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> On Thu, Jul 14, 2016 at 3:19 PM, Ren Industries <renindustries@gmail.com>
wrote:
>>
>> The point being that a programming language does not exist to direct the
operations of a computer; it's domain is computer science. Practical
implications, implementation details, are not necessarily its domain. You
continually assert how something should be, without evidence.
>
>
> If programming languages do not exist to direct the operations of a
computer, and their domain is computer science, then constant factors are
irrelevant. Computer science does not care if algorithms run twice as
fast, it only cares about running speed as asymptotic to a function of
problem size.
That's an overly broad statement. Complexity theory is not the only branch
of computer science that cares about running times of programs.
> In any case, I am not talking about implementation details, I am asking
that the behavior of certain programs which are currently unspecified
should be specified. This strictly increases the number of possible legal
programs. Why is that objectionable for a program that runs on computer
science abstract machines?
Those programs (with specific evaluation order, for each evaluation order)
are already expressible. If you consider programs as classes of behaviors
then reducing one program to another is reducing the number of programs.
--
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/CAJnLdOZ%2BgZe6vSfP9PJ95_Zr1mX5YMn8xCmnU2Y7O4RxSi4WOQ%40mail.gmail.com.
--001a11493f96ca9be005379f1403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 14 Jul 2016 8:43 p.m., "Hyman Rosen" <<a href=3D"mailto:hym=
an.rosen@gmail.com">hyman.rosen@gmail.com</a>> wrote:<br>
><br>
> On Thu, Jul 14, 2016 at 3:19 PM, Ren Industries <<a href=3D"mailto:=
renindustries@gmail.com">renindustries@gmail.com</a>> wrote:<br>
>><br>
>> The point being that a programming language does not exist to dire=
ct the operations of a computer; it's domain is computer science. Pract=
ical implications, implementation details, are not necessarily its domain. =
You continually assert how something should be, without evidence.<br>
><br>
><br>
> If programming languages do not exist to direct the operations of a co=
mputer, and their domain is computer science, then constant factors are irr=
elevant.=C2=A0 Computer science does not care if algorithms run twice as fa=
st, it only cares about running speed as asymptotic to a function of proble=
m size.</p>
<p dir=3D"ltr">That's an overly broad statement. Complexity theory is n=
ot the only branch of computer science that cares about running times of pr=
ograms. </p>
<p dir=3D"ltr">> In any case, I am not talking about implementation deta=
ils, I am asking that the behavior of certain programs which are currently =
unspecified should be specified.=C2=A0 This strictly increases the number o=
f possible legal programs.=C2=A0 Why is that objectionable for a program th=
at runs on computer science abstract machines?</p>
<p dir=3D"ltr">Those programs (with specific evaluation order, for each eva=
luation order) are already expressible. If you consider programs as classes=
of behaviors then reducing one program to another is reducing the number o=
f programs. </p>
<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/CAJnLdOZ%2BgZe6vSfP9PJ95_Zr1mX5YMn8xC=
mnU2Y7O4RxSi4WOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ%2BgZe6=
vSfP9PJ95_Zr1mX5YMn8xCmnU2Y7O4RxSi4WOQ%40mail.gmail.com</a>.<br />
--001a11493f96ca9be005379f1403--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 17:48:28 -0400
Raw View
--001a11466834808b0405379f774e
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 5:21 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> Those programs (with specific evaluation order, for each evaluation order)
> are already expressible. If you consider programs as classes of behaviors
> then reducing one program to another is reducing the number of programs.
>
I do not consider programs as classes of behavior. I consider programs to
be collections of text strings whose interpretation is specified by a
language definition. Programmers do not create "behavior classes", they
write programs. (The question of whether two text strings represent the
same behavior class is in general undecidable.) Defining order of
evaluation increases the number of text strings to which the language
definition gives meaning (for all text string lengths above some fixed
value, if we're being pedantic).
The "behavior class" approach may be useful for compilers themselves, since
they are in the work of translating from one program to another while
proving that both are in the same behavior class. And in fact, this is
where the errors are introduced due to lack of definition in the source
language - the compiler uses the lack of defined behavior to broaden the
behavior class in which it assumes the source text resides and produces a
target text that it considers to be in the same behavior class, even though
the programmer would disagree.
--
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/CAHSYqdaN5T_R%2BwhK5oNzN4auD%3DbHG5KV%2B4WMHs-Kp14heO2Nwg%40mail.gmail.com.
--001a11466834808b0405379f774e
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, Jul 14, 2016 at 5:21 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">
</span><p dir=3D"ltr">Those programs (with specific evaluation order, for e=
ach evaluation order) are already expressible. If you consider programs as =
classes of behaviors then reducing one program to another is reducing the n=
umber of programs.</p></blockquote><div><br>I do not consider programs as c=
lasses of behavior.=C2=A0 I consider programs to be collections of text str=
ings whose interpretation is specified by a language definition.=C2=A0 Prog=
rammers do not create "behavior classes", they write programs. =
=C2=A0(The question of whether two text strings represent the same behavior=
class is in general undecidable.) =C2=A0Defining order of evaluation incre=
ases the number of text strings to which the language definition gives mean=
ing (for all text string lengths above some fixed value, if we're being=
pedantic).<br><br>The "behavior class" approach may be useful fo=
r compilers themselves, since they are in the work of translating from one =
program to another while proving that both are in the same behavior class.=
=C2=A0 And in fact, this is where the errors are introduced due to lack of =
definition in the source language - the compiler uses the lack of defined b=
ehavior to broaden the behavior class in which it assumes the source text r=
esides and produces a target text that it considers to be in the same behav=
ior class, even though the programmer would disagree.</div></div></div></di=
v>
<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/CAHSYqdaN5T_R%2BwhK5oNzN4auD%3DbHG5KV=
%2B4WMHs-Kp14heO2Nwg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaN5T=
_R%2BwhK5oNzN4auD%3DbHG5KV%2B4WMHs-Kp14heO2Nwg%40mail.gmail.com</a>.<br />
--001a11466834808b0405379f774e--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 15 Jul 2016 00:03:44 +0100
Raw View
--001a1137b98e91218c0537a0833c
Content-Type: text/plain; charset=UTF-8
On 14 Jul 2016 10:48 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> On Thu, Jul 14, 2016 at 5:21 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> Those programs (with specific evaluation order, for each evaluation
order) are already expressible. If you consider programs as classes of
behaviors then reducing one program to another is reducing the number of
programs.
>
>
> I do not consider programs as classes of behavior. I consider programs
to be collections of text strings whose interpretation is specified by a
language definition. Programmers do not create "behavior classes", they
write programs. (The question of whether two text strings represent the
same behavior class is in general undecidable.) Defining order of
evaluation increases the number of text strings to which the language
definition gives meaning (for all text string lengths above some fixed
value, if we're being pedantic).
>
> The "behavior class" approach may be useful for compilers themselves,
since they are in the work of translating from one program to another while
proving that both are in the same behavior class. And in fact, this is
where the errors are introduced due to lack of definition in the source
language - the compiler uses the lack of defined behavior to broaden the
behavior class in which it assumes the source text resides and produces a
target text that it considers to be in the same behavior class, even though
the programmer would disagree.
>
Ah, well. I consider the behavior class approach to be more productive,
since it allows one to consider whether two programs are equivalent. It
doesn't matter that this can be undecidable; we just need to be able to
exhibit positive or negative proofs in natural scenarios.
A program with unspecified behavior (and most non trivial programs have
some unspecified behavior) still has defined meaning, it just has a wider
behavior class than a program equivalent but specifying that behavior. Even
a program with undefined behavior may not be entirely undefined in meaning,
if there exists an input that avoids the undefined behavior (eg. by
halting).
--
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/CAJnLdOaEV8ZqL5ZqPYy8yVCKChrpiB5mC6i%2B01hJk-W40nngpg%40mail.gmail.com.
--001a1137b98e91218c0537a0833c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 14 Jul 2016 10:48 p.m., "Hyman Rosen" <<a href=3D"mailto:hy=
man.rosen@gmail.com">hyman.rosen@gmail.com</a>> wrote:<br>
><br>
> On Thu, Jul 14, 2016 at 5:21 PM, 'Edward Catmur' via ISO C++ S=
tandard - Future Proposals <<a href=3D"mailto:std-proposals@isocpp.org">=
std-proposals@isocpp.org</a>> wrote:<br>
>><br>
>> Those programs (with specific evaluation order, for each evaluatio=
n order) are already expressible. If you consider programs as classes of be=
haviors then reducing one program to another is reducing the number of prog=
rams.<br>
><br>
><br>
> I do not consider programs as classes of behavior.=C2=A0 I consider pr=
ograms to be collections of text strings whose interpretation is specified =
by a language definition.=C2=A0 Programmers do not create "behavior cl=
asses", they write programs. =C2=A0(The question of whether two text s=
trings represent the same behavior class is in general undecidable.) =C2=A0=
Defining order of evaluation increases the number of text strings to which =
the language definition gives meaning (for all text string lengths above so=
me fixed value, if we're being pedantic).<br>
><br>
> The "behavior class" approach may be useful for compilers th=
emselves, since they are in the work of translating from one program to ano=
ther while proving that both are in the same behavior class.=C2=A0 And in f=
act, this is where the errors are introduced due to lack of definition in t=
he source language - the compiler uses the lack of defined behavior to broa=
den the behavior class in which it assumes the source text resides and prod=
uces a target text that it considers to be in the same behavior class, even=
though the programmer would disagree.<br>
></p>
<p dir=3D"ltr">Ah, well. I consider the behavior class approach to be more =
productive, since it allows one to consider whether two programs are equiva=
lent. It doesn't matter that this can be undecidable; we just need to b=
e able to exhibit positive or negative proofs in natural scenarios.</p>
<p dir=3D"ltr">A program with unspecified behavior (and most non trivial pr=
ograms have some unspecified behavior) still has defined meaning, it just h=
as a wider behavior class than a program equivalent but specifying that beh=
avior. Even a program with undefined behavior may not be entirely undefined=
in meaning, if there exists an input that avoids the undefined behavior (e=
g. by halting). </p>
<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/CAJnLdOaEV8ZqL5ZqPYy8yVCKChrpiB5mC6i%=
2B01hJk-W40nngpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaEV8ZqL5=
ZqPYy8yVCKChrpiB5mC6i%2B01hJk-W40nngpg%40mail.gmail.com</a>.<br />
--001a1137b98e91218c0537a0833c--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 14 Jul 2016 19:21:22 -0400
Raw View
--94eb2c048e44c12b2f0537a0c3f2
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 7:03 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> A program with unspecified behavior (and most non trivial programs have
> some unspecified behavior) still has defined meaning, it just has a wider
> behavior class than a program equivalent but specifying that behavior. Even
> a program with undefined behavior may not be entirely undefined in meaning,
> if there exists an input that avoids the undefined behavior (eg. by
> halting).
>
I agree, but as I said, I see this as the problem, not as the opportunity.
The compiler has a much wider notion of the behavior class of a program
with unspecified (and undefined, even more so) behavior than the programmer
does when the programmer does not notice the dependency on unspecified
behavior. So the compiler translates the source program to a machine
language program that it believes is in the same behavior class but which
the programmer does not.
--
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/CAHSYqdaycRJEKuRWg48L-Qa9gDqKToaEZPqDDw%3DyUExp07VetQ%40mail.gmail.com.
--94eb2c048e44c12b2f0537a0c3f2
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, Jul 14, 2016 at 7:03 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<p dir=3D"ltr">A program with unspecified behavior (and most non trivial pr=
ograms have some unspecified behavior) still has defined meaning, it just h=
as a wider behavior class than a program equivalent but specifying that beh=
avior. Even a program with undefined behavior may not be entirely undefined=
in meaning, if there exists an input that avoids the undefined behavior (e=
g. by halting).</p></blockquote><div><br>I agree, but as I said, I see this=
as the problem, not as the opportunity.=C2=A0 The compiler has a much wide=
r notion of the behavior class of a program with unspecified (and undefined=
, even more so) behavior than the programmer does when the programmer does =
not notice the dependency on unspecified behavior.=C2=A0 So the compiler tr=
anslates the source program to a machine language program that it believes =
is in the same behavior class but which the programmer does not.</div></div=
></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/CAHSYqdaycRJEKuRWg48L-Qa9gDqKToaEZPqD=
Dw%3DyUExp07VetQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaycRJEKu=
RWg48L-Qa9gDqKToaEZPqDDw%3DyUExp07VetQ%40mail.gmail.com</a>.<br />
--94eb2c048e44c12b2f0537a0c3f2--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 14 Jul 2016 16:35:17 -0700
Raw View
On quinta-feira, 14 de julho de 2016 14:11:10 PDT Hyman Rosen wrote:
> I would argue that increased knowledge implies decreased confusion. More
> to the point, knowing that the order is unspecified is itself knowledge.
> You say "If order is unspecified, and code is correct only for a certain
> order, then I know that code is broken." But that means that you know the
> order is unspecified. That is the same quantum of knowledge as knowing
> that the order is particular. And the problem with unspecified order is
> when programmers do not know that the order is unspecified, or fail to
> notice that they are depending on a particular order because the code works
> (until it doesn't).
Since you have to know something, how is knowing "the order is unspecified"
different from knowing "the order is specified as XYZ" ?
As many have pointed out, LTR is not as intuitive as it might seem to you.
--
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/1780561.aKQKLafxT5%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 14 Jul 2016 16:44:14 -0700
Raw View
On quinta-feira, 14 de julho de 2016 12:36:56 PDT Hyman Rosen wrote:
> On Thu, Jul 14, 2016 at 11:53 AM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > Let me re-state my argument.
> >
> > Due to the associativity rules, in the expression
> >
> > a = b = c;
> >
> > a will get the value of the b = c assignment. For that to happen, we
> > require
> > that b = c must be run first. There's no argument here.
> >
> > Therefore, the committee ruled that the RHS of the a = x expression (with
> > x :=
> > b = c) should be evaluated first. So assignments should have evaluation
> > from
> > the right to left.
>
> Just because you say "therefore" does not mean that the second statement
> actually follows from the first.
> To wit:
>
> Due to the parenthesization rules, in the expression
> a << (b << c)
> a will be shifted by the result of the b << c shift. For that to
> happen, we require that b << c must be run first.
> There's no argument there.
>
> Therefore, the committee ruled that the RHS of the a << x expression
> (with x := b << c) should be evaluated first.
> So shifts should have evaluation from the right to the left.
>
> See how that works?
Yes. You changed the argument, though, by putting the parentheses.
I'm not saying that the rationale of the adoption by the committee was the
only possibility. I'm saying it's the one that they[*] chose to justify the
opinion.
[*] probably, because I wasn't there and don't know what exactly they
discussed.
I would have personally preferred depth-first, associativity, based on
precedence order, so
a = b = c = d;
should be equivalent to:
c = d;
b = c;
a = b;
and
a + b * c
would be
decltype(auto) x = b * c;
a + x;
which implies an evaluation order of b, c, a.
--
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/3692034.zveBzsz5YS%40tjmaciei-mobl1.
.
Author: Ren Industries <renindustries@gmail.com>
Date: Thu, 14 Jul 2016 19:48:41 -0400
Raw View
--001a114060be5bb9e10537a124d1
Content-Type: text/plain; charset=UTF-8
Okay? But that is clearly an opportunity, not a problem. It is only a
problem when programmers poorly use their tools; it is an opportunity
always to the compiler. What you see it as doesn't matter; it is clearly,
mathematically, an opportunity.
On Thu, Jul 14, 2016 at 7:21 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 7:03 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> A program with unspecified behavior (and most non trivial programs have
>> some unspecified behavior) still has defined meaning, it just has a wider
>> behavior class than a program equivalent but specifying that behavior. Even
>> a program with undefined behavior may not be entirely undefined in meaning,
>> if there exists an input that avoids the undefined behavior (eg. by
>> halting).
>>
>
> I agree, but as I said, I see this as the problem, not as the
> opportunity. The compiler has a much wider notion of the behavior class of
> a program with unspecified (and undefined, even more so) behavior than the
> programmer does when the programmer does not notice the dependency on
> unspecified behavior. So the compiler translates the source program to a
> machine language program that it believes is in the same behavior class but
> which the programmer does not.
>
> --
> 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/CAHSYqdaycRJEKuRWg48L-Qa9gDqKToaEZPqDDw%3DyUExp07VetQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaycRJEKuRWg48L-Qa9gDqKToaEZPqDDw%3DyUExp07VetQ%40mail.gmail.com?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/CAMD6iD_Gb0cFz4%2B1d80d9ZHzYLc%2B3sFHUAHuF2eWwLM9uKYxRg%40mail.gmail.com.
--001a114060be5bb9e10537a124d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Okay? But that is clearly an opportunity, not a problem. I=
t is only a problem when programmers poorly use their tools; it is an oppor=
tunity always to the compiler. What you see it as doesn't matter; it is=
clearly, mathematically, an opportunity.</div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 7:21 PM, Hyman Rosen =
<span dir=3D"ltr"><<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_b=
lank">hyman.rosen@gmail.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><span class=3D"">On Thu, Jul 14, 2016 at 7:03 PM, 'Edward Catmur&#=
39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">A program with unspecified behavior (and most non trivial pr=
ograms have some unspecified behavior) still has defined meaning, it just h=
as a wider behavior class than a program equivalent but specifying that beh=
avior. Even a program with undefined behavior may not be entirely undefined=
in meaning, if there exists an input that avoids the undefined behavior (e=
g. by halting).</p></blockquote></span><div><br>I agree, but as I said, I s=
ee this as the problem, not as the opportunity.=C2=A0 The compiler has a mu=
ch wider notion of the behavior class of a program with unspecified (and un=
defined, even more so) behavior than the programmer does when the programme=
r does not notice the dependency on unspecified behavior.=C2=A0 So the comp=
iler translates the source program to a machine language program that it be=
lieves is in the same behavior class but which the programmer does not.</di=
v></div></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" 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@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/CAHSYqdaycRJEKuRWg48L-Qa9gDqKToaEZPqD=
Dw%3DyUExp07VetQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdaycRJEKuRWg48L-Qa9gDqKToaEZPqDDw%3DyUExp07VetQ%40mail.gmail.c=
om</a>.<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" 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/CAMD6iD_Gb0cFz4%2B1d80d9ZHzYLc%2B3sFH=
UAHuF2eWwLM9uKYxRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_Gb0cF=
z4%2B1d80d9ZHzYLc%2B3sFHUAHuF2eWwLM9uKYxRg%40mail.gmail.com</a>.<br />
--001a114060be5bb9e10537a124d1--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Thu, 14 Jul 2016 20:29:31 -0400
Raw View
--94eb2c1228ae5ba1870537a1b6a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I don't really want to pursue this discussion until an actual paper has
been produced to change anything, but for the sake of completeness, taken
from
http://developers.redhat.com/blog/2016/07/13/red-hat-iso-c-standards-meetin=
g-june-2016-core-language/
which was published yesterday:
=C2=AB[...] I was concerned about one aspect of this paper, the requirement=
that
function arguments be evaluated from left to right; GCC currently evaluates
them from right to left on x86_64, because that=E2=80=99s more natural for =
the
function call psABI. Before the meeting I implemented the proposed
requirement and found a 2% performance penalty on one of the SPEC2006
tests; based on this I argued for relaxing that requirement of the paper to
say that the arguments are indeterminately sequenced, as in the alternative
offered near the end of the paper. After some discussion, the committee
decided to adopt my position=C2=BB
This fits with my memory of the discussion. For some, a 2% performance
penalty is minor, but for a sizeable portion of C++ programmers, including
those I work with (the SG14 crowd, essentially) it is not.
The 4% variance has also been mentioned, but when voting was taken, this
information played a role. I'm not sure the imposed ordering would have
been accepted anyway, that being said (I would have spoken strongly against
it, for reasons I and others have disclosed many times), but the
information quoted by Hyman, and correctly as far as I know, was not
brought up during debates, wheras the one quoted above was.
I plan not to participate anmymore in this discussion until a paper's been
put on the table. This was mostly to ensure the information used for those
still debating was correct.
2016-07-14 15:43 GMT-04:00 Hyman Rosen <hyman.rosen@gmail.com>:
> On Thu, Jul 14, 2016 at 3:19 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> The point being that a programming language does not exist to direct the
>> operations of a computer; it's domain is computer science. Practical
>> implications, *implementation details*, are not necessarily its domain.
>> You continually assert how something *should be, *without evidence.
>>
>
> If programming languages do not exist to direct the operations of a
> computer, and their domain is computer science, then constant factors are
> irrelevant. Computer science does not care if algorithms run twice as
> fast, it only cares about running speed as asymptotic to a function of
> problem size.
>
> In any case, I am not talking about implementation details, I am asking
> that the behavior of certain programs which are currently unspecified
> should be specified. This strictly increases the number of possible lega=
l
> programs. Why is that objectionable for a program that runs on computer
> science abstract machines?
>
> The practical implications of order of evaluation are that they restrict
>> what can be said in the language, and they restrict what platforms that
>> language can be ported to *efficiently*. That means it is not simply a
>> "should" question, despite the fact you repeatedly assert differently. 4=
%
>> is not a small barrier; I've often had to restructure code to get less o=
f a
>> performance gain. I shouldn't have to pay that cost because you believe
>> people should not have to think about their code as hard.
>>
>
> That "4%" is a scare number. Looking here
> <https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01075.html>, Jason Merrill
> says "In my own SPEC runs with an earlier version of the patch, most of
> the C++ tests did not change significantly, but xalancbmk slowed down
> about 1%."
>
> However, simply adding syntax to enforce a left to right evaluation
>> strategy solves both of our problems; you can teach people that, and I c=
an
>> continue to write high performing code. Why no comments on that idea,
>> beyond your dogmatic approach that something "should" be some way withou=
t
>> evidence?
>>
>
> Because adding new syntax so that people can choose not to use it and
> continue to write potentially broken code is silly, when the change to th=
e
> language would not affect the legality or behavior of currently legal
> programs.
>
> --
> 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/CAHSYqdZ-dr4=
9X1GZhdYcheLVSxMB9JO-kSj2o%3DD%3DWxnzBE3eZg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ-dr=
49X1GZhdYcheLVSxMB9JO-kSj2o%3DD%3DWxnzBE3eZg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
--=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/CAKiZDp2TtwW22XSe4YMvvTcjt%3DxNg3sRv_gQqs92%3D73=
BERJ-dQ%40mail.gmail.com.
--94eb2c1228ae5ba1870537a1b6a4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I don't really want to pursue this discussio=
n until an actual paper has been produced to change anything, but for the s=
ake of completeness, taken from <a href=3D"http://developers.redhat.com/blo=
g/2016/07/13/red-hat-iso-c-standards-meeting-june-2016-core-language/">http=
://developers.redhat.com/blog/2016/07/13/red-hat-iso-c-standards-meeting-ju=
ne-2016-core-language/</a> which was published yesterday:<br><br><div style=
=3D"margin-left:40px">=C2=AB[...] I was concerned about one aspect of this =
paper, the requirement that=20
function arguments be evaluated from left to right; GCC currently=20
evaluates them from right to left on x86_64, because that=E2=80=99s more na=
tural
for the function call psABI. Before the meeting I implemented the=20
proposed requirement and found a 2% performance penalty on one of the=20
SPEC2006 tests; based on this I argued for relaxing that requirement of=20
the paper to say that the arguments are indeterminately sequenced, as in
the alternative offered near the end of the paper. After some=20
discussion, the committee decided=C2=A0to adopt=C2=A0my position=C2=BB<br><=
br></div>This fits with my memory of the discussion. For some, a 2% perform=
ance penalty is minor, but for a sizeable portion of C++ programmers, inclu=
ding those I work with (the SG14 crowd, essentially) it is not.<br><br></di=
v>The 4% variance has also been mentioned, but when voting was taken, this =
information played a role. I'm not sure the imposed ordering would have=
been accepted anyway, that being said (I would have spoken strongly agains=
t it, for reasons I and others have disclosed many times), but the informat=
ion quoted by Hyman, and correctly as far as I know, was not brought up dur=
ing debates, wheras the one quoted above was.<br><br></div>I plan not to pa=
rticipate anmymore in this discussion until a paper's been put on the t=
able. This was mostly to ensure the information used for those still debati=
ng was correct.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">2016-07-14 15:43 GMT-04:00 Hyman Rosen <span dir=3D"ltr"><<a hre=
f=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com<=
/a>></span>:<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"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul =
14, 2016 at 3:19 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto=
:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The point being that a =
programming language does not exist to direct the operations of a computer;=
it's domain is computer science. Practical implications, <i>implementa=
tion details</i>, are not necessarily its domain. You continually assert ho=
w something <i>should be, </i>without evidence.</div></blockquote></span><d=
iv><br>If programming languages do not exist to direct the operations of a =
computer, and their domain is computer science, then constant factors are i=
rrelevant.=C2=A0 Computer science does not care if algorithms run twice as =
fast, it only cares about running speed as asymptotic to a function of prob=
lem size.<br><br>In any case, I am not talking about implementation details=
, I am asking that the behavior of certain programs which are currently uns=
pecified should be specified.=C2=A0 This strictly increases the number of p=
ossible legal programs.=C2=A0 Why is that objectionable for a program that =
runs on computer science abstract machines?<br><br></div><span class=3D""><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div>The practical implications of order o=
f evaluation are that they restrict what can be said in the language, and t=
hey restrict what platforms that language can be ported to=C2=A0<i>efficien=
tly</i>. That means it is not simply a "should" question, despite=
the fact you repeatedly assert differently. 4% is not a small barrier; I&#=
39;ve often had to restructure code to get less of a performance gain. I sh=
ouldn't have to pay that cost because you believe people should not hav=
e to think about their code as hard.</div></div></blockquote></span><div><b=
r>That "4%" is a scare number.=C2=A0 Looking=C2=A0<a href=3D"http=
s://gcc.gnu.org/ml/gcc-patches/2016-06/msg01075.html" target=3D"_blank">her=
e</a>, Jason Merrill says <font face=3D"arial, helvetica, sans-serif">"=
;<tt style=3D"color:rgb(0,0,0)">In my own SPEC runs with an earlier version=
of the patch, most of the=C2=A0</tt><tt style=3D"color:rgb(0,0,0)">C++ tes=
ts did not change significantly, but xalancbmk slowed down about=C2=A0</tt>=
<tt style=3D"color:rgb(0,0,0)">1%."</tt><br></font><br></div><span cla=
ss=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>However, simply adding synta=
x to enforce a left to right evaluation strategy solves both of our problem=
s; you can teach people that, and I can continue to write high performing c=
ode. Why no comments on that idea, beyond your dogmatic approach that somet=
hing "should" be some way without evidence?</div></div></blockquo=
te></span><div><br>Because adding new syntax so that people can choose not =
to use it and continue to write potentially broken code is silly, when the =
change to the language would not affect the legality or behavior of current=
ly legal programs.</div></div></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" 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@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/CAHSYqdZ-dr49X1GZhdYcheLVSxMB9JO-kSj2=
o%3DD%3DWxnzBE3eZg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdZ-dr49X1GZhdYcheLVSxMB9JO-kSj2o%3DD%3DWxnzBE3eZg%40mail.gma=
il.com</a>.<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" 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/CAKiZDp2TtwW22XSe4YMvvTcjt%3DxNg3sRv_=
gQqs92%3D73BERJ-dQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2TtwW2=
2XSe4YMvvTcjt%3DxNg3sRv_gQqs92%3D73BERJ-dQ%40mail.gmail.com</a>.<br />
--94eb2c1228ae5ba1870537a1b6a4--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 18:42:24 -0700 (PDT)
Raw View
------=_Part_21_1483413156.1468546944288
Content-Type: multipart/alternative;
boundary="----=_Part_22_969928001.1468546944288"
------=_Part_22_969928001.1468546944288
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=887:32:35=EF=BC=8CPeter Koch Larsen=E5=86=99=E9=81=93=EF=
=BC=9A
>
> Personally, I am disappointed that we did not get a fixed evaluation=20
> order. To me, the argument that a non-fixed evaluation order allows a=20
> theoretical speed-up in the order of up to 4% has had to much weight=20
> and perhaps even is a red herring. If you have an f(g(),h()) and both=20
> g and h have side-effects, there is already unspecified behaviour, and=20
> if they do not, the compiler is already free to choose whatever=20
> evaluation order it deems best.=20
>
First, you *have* got a way to fix evaluation long ago. Even without=20
statements, with some monadic tricks, f1(f2(f3(...))) *can *enforce the=20
order, just with a weird syntax in traditional ALGOL/C guys' view.
So actually you are disappointing with another problem. You want to forbid=
=20
others to use unsequenced evaluation (at least, by default) but they don't=
=20
agree with you. And why?
Second, as said, to choose the order solely by compiler is often very=20
difficult, if not impossible. The compiler is forced to prove the=20
equivalence between the program semantics before and after transformation=
=20
without explicit unsequenced evaluation guarantee. In practice, this has=20
almost the same effect to forbid such optimization. If you still think this=
=20
don't make sense, consider similar cases:
- Why bother to specify the special cases cannot handled by the as-if=20
rules (e.g. copy elision and merging operator new calls)?
- Why not just use GC everywhere and believe compiler will insert=20
destructor/finalizer calls appropriately?
- Why allow undefined behavior?
=20
> Instead, we could have removed a barrier for new or non-expert C++=20
> programmers who do not understand why an example such as Hymans point=20
> p =3D { read<int>(std::cin),read<int>(std::cin)} works wonderfully in=20
> their environment and passes all unit-tests in order to suddenly and=20
> mysteriously fail when porting to a new compiler or after an upgrade=20
> of the same compiler, perhaps years later. I myself might easily=20
> overlook that that code is really not working, but only appears to do=20
> so.=20
>
This "barrier" is too trivial to remove. If you can't remove the (more=20
significant) "barrier" in the cases I illustrated above, it is still=20
noob-unfriendly. I doubt this will lead to the language that is still=20
useful as in current status.
Most code relying on an explicit order without is already broken before the=
=20
rules are settled. If you want to have multiple side effects, you *should *=
care=20
the evaluation order related to side effects. Hymans is wrong because he=20
assumes this order is always the same with lexical order, which is not true=
=20
in general - the language or the machine just does not work in that way=20
without fixed order rules enforced artificially. And since the rules were=
=20
not there, you should not depend on those rules in analysis the necessity=
=20
of the fixed order, otherwise it is somehow circular justification. Without=
=20
such rules, the expressions are confusing. So they are already broken.
=20
> So let us please have some experts out there (I am not one) who can=20
> argue the case for safety and security over speed and persuade all the=20
> skilled experts such as FrankHB and Catmur about the value of a strict=20
> order evaluation.=20
>
I personally usually don't put performance as the first need. I believe=20
here the performance gain is a side effect of expressiveness.
As of safety and security, I think you ignored an important fact. If a=20
program *behaves *normally, it is not naturally guaranteed to behave=20
normally forever. To make it safe and secure, you should take actions *befo=
re=20
it runs*. Think twice: why people are scared by undefined behavior? As I've=
=20
said, fixing the order is not safe and secure. It evens make the effort=20
less effective: it may hide bugs which cannot easily be checked by machines=
=20
(i.e. most people may be lazy and ignore them until there is strange=20
behavior), cause more unsafe and insecure code in nature.
=20
> For those interested in speed, it is my belief that speed can be had=20
> in another way. A good, pragmatic specification of pure would be one=20
> way forward.=20
>
> /Peter=20
> PS: I have no problem living with assignment being right to left=20
> rather than left to right.=20
>
> On Thu, Jul 14, 2016 at 6:34 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> >=20
> > =E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B=
UTC+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=E5=86=99=E9=81=93=EF=
=BC=9A=20
> >>=20
> >> I for one would be very happy if claims on stupidity, syndroms and=20
> other=20
> >> sorts of derogatory comments were kept away from the discussion. I=20
> >> appreciate the intellect of people I discuss with, even (particularly?=
)=20
> when=20
> >> we don't see eye to eye. I appreciate Jeffrey's efforts in that=20
> direction.=20
> >>=20
> > I also appreciate that effort.=20
> >=20
> > But please don't take "avoiding derogatory comments" as some sorts of=
=20
> > political correctness. There do exist certain kinds of stupidity and=20
> they=20
> > are not just you-know-who. I have to argue that is not "personal",=20
> that's=20
> > all. Sorry if that wording makes someone unhappy.=20
> >=20
> >>=20
> >> 2016-07-13 21:48 GMT-04:00 FrankHB1989 <frank...@gmail.com>:=20
> >>>=20
> >>>=20
> >>>=20
> >>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=
=89 UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=86=99=E9=81=
=93=EF=BC=9A=20
> >>>>=20
> >>>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <frank...@gmail.com>=20
> wrote:=20
> >>>>>=20
> >>>>> The true harm of such decision is, it encourages stupidity and=20
> laziness=20
> >>>>> as the default case.=20
> >>>>=20
> >>>>=20
> >>>> Please try to stick to technical arguments on this mailing list,=20
> instead=20
> >>>> of personally attacking ("stupidity") the people who prefer a=20
> different=20
> >>>> outcome than you do.=20
> >>>>=20
> >>>> Jeffrey=20
> >>>=20
> >>>=20
> >>> I believed it was common sense that "insisting on ignorance of=20
> language=20
> >>> rules as a need in general" is stupidity, to anyone. So it was not=20
> attack to=20
> >>> anyone, esp. "personally".=20
> >>>=20
> >>> Technically, the rules consist the interface of the designed language=
..=20
> >>> How will you allow people who know little about them to decide how=20
> they=20
> >>> should be?=20
> >>>=20
> >>>=20
> >>> --=20
> >>> You received this message because you are subscribed to the Google=20
> Groups=20
> >>> "ISO C++ Standard - Future Proposals" group.=20
> >>> To unsubscribe from this group and stop receiving emails from it, sen=
d=20
> an=20
> >>> email to std-proposal...@isocpp.org.=20
> >>> To post to this group, send email to std-pr...@isocpp.org.=20
> >>> To view this discussion on the web visit=20
> >>>=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e5=
d-4e7b-80a8-7ea9279d3516%40isocpp.org.=20
>
> >>=20
> >>=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> >=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e6848a1e-f81=
2-410e-93ef-086e111e6122%40isocpp.org.=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/7b3ff60a-8a09-422b-b3c5-a357b3186cfe%40isocpp.or=
g.
------=_Part_22_969928001.1468546944288
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=887:32:35=EF=BC=8CPeter Koch Lar=
sen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
Personally, I am disappointed that we did not get a fixed evaluation
<br>order. To me, the argument =C2=A0that a non-fixed evaluation order allo=
ws a
<br>theoretical speed-up in the order of up to 4% has had to much weight
<br>and perhaps even is a red herring. If you have an f(g(),h()) and both
<br>g and h have side-effects, there is already unspecified behaviour, and
<br>if they do not, the compiler is already free to choose whatever
<br>evaluation order it deems best.
<br></blockquote><div>First, you <i>have</i> got a way to fix evaluation lo=
ng ago. Even without statements, with some monadic tricks, f1(f2(f3(...))) =
<i>can </i>enforce the order, just with a weird syntax in traditional ALGOL=
/C guys' view.<br>So actually you are disappointing with another proble=
m. You want to forbid others to use unsequenced evaluation (at least, by de=
fault) but they don't agree with you. And why?<br>Second, as said, to c=
hoose the order solely by compiler is often very difficult, if not impossib=
le. The compiler is forced to prove the equivalence between the program sem=
antics before and after transformation without explicit unsequenced evaluat=
ion guarantee. In practice, this has almost the same effect to forbid such =
optimization. If you still think this don't make sense, consider simila=
r cases:<br><ul><li>Why bother to specify the special cases cannot handled =
by the as-if rules (e.g. copy elision and merging operator new calls)?<br><=
/li><li>Why not just use GC everywhere and believe compiler will insert des=
tructor/finalizer calls appropriately?</li><li>Why allow undefined behavior=
?</li></ul>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Ins=
tead, we could have removed a barrier for new or non-expert C++
<br>programmers who do not understand why an example such as Hymans point
<br>p =3D { read<int>(std::cin),read<int>(<wbr>std::cin)} =C2=
=A0works wonderfully in
<br>their environment and passes all unit-tests in order to suddenly and
<br>mysteriously fail when porting to a new compiler or after an upgrade
<br>of the same compiler, perhaps years later. I myself might easily
<br>overlook that that code is really not working, but only appears to do
<br>so.
<br></blockquote><div>This "barrier" is too trivial to remove. If=
you can't remove the (more significant) "barrier" in the cas=
es I illustrated above, it is still noob-unfriendly. I doubt this will lead=
to the language that is still useful as in current status.<br><br>Most cod=
e relying on an explicit order without is already broken before the rules a=
re settled. If you want to have multiple side effects, you <i>should </i>ca=
re the evaluation order related to side effects. Hymans is wrong because he=
assumes this order is always the same with lexical order, which is not tru=
e in general - the language or the machine just does not work in that way w=
ithout fixed order rules enforced artificially. And since the rules were no=
t there, you should not depend on those rules in analysis the necessity of =
the fixed order, otherwise it is somehow circular justification. Without su=
ch rules, the expressions are confusing. So they are already broken.<br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So let us please =
have some experts out there (I am not one) who can
<br>argue the case for safety and security over speed and persuade all the
<br>skilled experts such as FrankHB and Catmur about the value of a strict
<br>order evaluation.
<br></blockquote><div>I personally usually don't put performance as the=
first need. I believe here the performance gain is a side effect of expres=
siveness.<br>As of safety and security, I think you ignored an important fa=
ct. If a program <i>behaves </i>normally, it is not naturally guaranteed to=
behave normally forever. To make it safe and secure, you should take actio=
ns <i>before it runs</i>. Think twice: why people are scared by undefined b=
ehavior? As I've said, fixing the order is not safe and secure. It even=
s make the effort less effective: it may hide bugs which cannot easily be c=
hecked by machines (i.e. most people may be lazy and ignore them until ther=
e is strange behavior), cause more unsafe and insecure code in nature.<br>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">For those inte=
rested in speed, it is my belief that speed can be had
<br>in another way. A good, pragmatic specification of pure would be one
<br>way forward.
<br>
<br>/Peter
<br>PS: I have no problem living with assignment being right to left
<br>rather than left to right.
<br>
<br>On Thu, Jul 14, 2016 at 6:34 AM, FrankHB1989 <<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"4pu0zjk_CwAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">frank...@gmail.com</a>> =
wrote:
<br>>
<br>>
<br>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8A=E5=8D=8810:05:05=EF=BC=8CPatrice Roy=E5=86=99=E9=81=
=93=EF=BC=9A
<br>>>
<br>>> I for one would be very happy if claims on stupidity, syndroms=
and other
<br>>> sorts of derogatory comments were kept away from the discussio=
n. I
<br>>> appreciate the intellect of people I discuss with, even (parti=
cularly?) when
<br>>> we don't see eye to eye. I appreciate Jeffrey's effort=
s in that direction.
<br>>>
<br>> I also appreciate that effort.
<br>>
<br>> But please don't take "avoiding derogatory comments"=
as some sorts of
<br>> political correctness. There do exist certain kinds of stupidity a=
nd they
<br>> are not just you-know-who. I have to argue that is not "perso=
nal", that's
<br>> all. Sorry if that wording makes someone unhappy.
<br>>
<br>>>
<br>>> 2016-07-13 21:48 GMT-04:00 FrankHB1989 <<a>frank...@gmail.c=
om</a>>:
<br>>>>
<br>>>>
<br>>>>
<br>>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:02:12=EF=BC=8CJeffrey Yasskin=E5=
=86=99=E9=81=93=EF=BC=9A
<br>>>>>
<br>>>>> On Mon, Jul 11, 2016 at 7:46 PM, FrankHB1989 <<a>fr=
ank...@gmail.com</a>> wrote:
<br>>>>>>
<br>>>>>> The true harm of such decision is, it encourages s=
tupidity and laziness
<br>>>>>> as the default case.
<br>>>>>
<br>>>>>
<br>>>>> Please try to stick to technical arguments on this mai=
ling list, instead
<br>>>>> of personally attacking ("stupidity") the pe=
ople who prefer a different
<br>>>>> outcome than you do.
<br>>>>>
<br>>>>> Jeffrey
<br>>>>
<br>>>>
<br>>>> I believed it was common sense that "insisting on ign=
orance of language
<br>>>> rules as a need in general" is stupidity, to anyone. =
So it was not attack to
<br>>>> anyone, esp. "personally".
<br>>>>
<br>>>> Technically, the rules consist the interface of the design=
ed language.
<br>>>> How will you allow people who know little about them to de=
cide how they
<br>>>> should be?
<br>>>>
<br>>>>
<br>>>> --
<br>>>> You received this message because you are subscribed to th=
e Google Groups
<br>>>> "ISO C++ Standard - Future Proposals" group.
<br>>>> To unsubscribe from this group and stop receiving emails f=
rom it, send an
<br>>>> email to <a>std-proposal...@isocpp.org</a>.
<br>>>> To post to this group, send email to <a>std-pr...@isocpp.o=
rg</a>.
<br>>>> To view this discussion on the web visit
<br>>>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/b2e0db59-3e5d-4e7b-80a8-7ea9279d3516%40isocpp.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e5d-4e7b-80a8-7ea9279d=
3516%40isocpp.org';return true;" onclick=3D"this.href=3D'https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/b2e0db59-3e5d-4e7b-80a8-=
7ea9279d3516%40isocpp.org';return true;">https://groups.google.com/a/<w=
br>isocpp.org/d/msgid/std-<wbr>proposals/b2e0db59-3e5d-4e7b-<wbr>80a8-7ea92=
79d3516%40isocpp.org</a><wbr>.
<br>>>
<br>>>
<br>> --
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"4pu0zjk_CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"4pu0zjk_CwAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.
<br>> To view this discussion on the web visit
<br>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/e6848a1e-f812-410e-93ef-086e111e6122%40isocpp.org" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e6848a1e-f812-410e-93ef-086e111e6122%40i=
socpp.org';return true;" onclick=3D"this.href=3D'https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/e6848a1e-f812-410e-93ef-086e111e=
6122%40isocpp.org';return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/e6848a1e-f812-410e-<wbr>93ef-086e111e6122%=
40isocpp.org</a><wbr>.
<br></blockquote></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/7b3ff60a-8a09-422b-b3c5-a357b3186cfe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b3ff60a-8a09-422b-b3c5-a357b3186cfe=
%40isocpp.org</a>.<br />
------=_Part_22_969928001.1468546944288--
------=_Part_21_1483413156.1468546944288--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 19:00:10 -0700 (PDT)
Raw View
------=_Part_25_126271844.1468548010322
Content-Type: multipart/alternative;
boundary="----=_Part_26_1914000420.1468548010323"
------=_Part_26_1914000420.1468548010323
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=8811:30:14=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 13, 2016 at 11:31 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8A=E5=8D=884:37:53=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> The problem is that the ordering for assignment, once specified as=20
>>> right-to-left in C++17, can never be fixed. That's heinous.
>>>
>>
>> For assignments this was actually specified long ago. See CWG 222 and CW=
G=20
>> 637. There may be more subtle risks to change.
>>
>
> CWG 222 and 637 are for C, not C++. More to the point, they do not=20
> specify order of evaluation for assignment. What are you trying to say?
>
> I am surprised of your misunderstanding. I don't remember WG14 DR number=
=20
has grown to more than 600 before. If you are not sure, here are the links:
- http://wg21.cmeerw.net/cwg/issue222
- http://wg21.cmeerw.net/cwg/issue637
In fact, C++11 is based on the resolutions of them, and the modifications=
=20
are not included in C11. And when you see the modifications, you will know=
=20
why I mentioned them here.
I was not talking about initialization, but the order itself. You insisted=
=20
on left-to-right, but it conflicts with C++11 in some cases.
If you still don't know how they interacts the issue, there is one more=20
example:
In C and C++98/03, for some initialized and distinct scalar objects x and=
=20
y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11 assignme=
nt=20
allows it for non-volatile scalars, because the C++11 rules makes it=20
effectively ordered (in such cases), with *right-to-left* order.
=20
> In any case, compatibility with C is irrelevant; the two languages are=20
> already different with respect to order. For example:
>
> C 11 N1570 6.7.9.23: "The evaluations of the initialization list=20
> expressions are indeterminately sequenced with respect to one another and=
=20
> thus the order in which any side effects occur is unspecified."
>
> C++ 17 N4527 8.5.4/4: "Within the initializer-list of a braced-init-list=
=20
> ... every value computation and side effect associated with a given=20
> initializer-clause is sequenced before every value computation and side=
=20
> effect associated with any initializer-clause that follows it in the=20
> comma-separated list of the initializer-list."
>
--=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/dd968f7a-58ff-4673-b66e-6c8bbbed8751%40isocpp.or=
g.
------=_Part_26_1914000420.1468548010323
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=8811:30:14=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 11:31=
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"1Li-zTFMCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=
=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:37:53=EF=BC=8CHy=
man Rosen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote"><div>The problem is that the ordering for assign=
ment, once specified as right-to-left in C++17, can never be fixed.=C2=A0 T=
hat's heinous.</div></div></div></div></blockquote><div><br>For assignm=
ents this was actually specified long ago. See CWG 222 and CWG 637. There m=
ay be more subtle risks to change.</div></div></blockquote><div><br>CWG 222=
and 637 are for C, not C++.=C2=A0 More to the point, they do not specify o=
rder of evaluation for assignment.=C2=A0 What are you trying to say?<br><br=
></div></div></div></div></blockquote><div>I am surprised of your misunders=
tanding. I don't remember WG14 DR number has grown to more than 600 bef=
ore. If you are not sure, here are the links:<br><ul><li>http://wg21.cmeerw=
..net/cwg/issue222</li><li>http://wg21.cmeerw.net/cwg/issue637</li></ul>In f=
act, C++11 is based on the resolutions of them, and the modifications are n=
ot included in C11. And when you see the modifications, you will know why I=
mentioned them here.<br><br>I was not talking about initialization, but th=
e order itself. You insisted on left-to-right, but it conflicts with C++11 =
in some cases.<br><br>If you still don't know how they interacts the is=
sue, there is one more example:<br><br>In C and C++98/03, for some initiali=
zed and distinct scalar objects x and y, x ^=3D y ^=3D x ^=3D y will cause =
undefined behavior, but C++11 assignment allows it for non-volatile scalars=
, because the C++11 rules makes it effectively ordered (in such cases), wit=
h <i>right-to-left</i> order.<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>In=
any case, compatibility with C is irrelevant; the two languages are alread=
y different with respect to order.=C2=A0 For example:<br><br>C 11 N1570 <a =
href=3D"http://6.7.9.23" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F6.7.9.23\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHt9Dlw9xjXapUcP3zRQN6VcxfFLg';return=
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%=
2F%2F6.7.9.23\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHt9Dlw9xjXapUcP3zRQN6=
VcxfFLg';return true;">6.7.9.23</a>: "The evaluations of the initi=
alization list expressions are indeterminately sequenced with respect to on=
e another and thus the order in which any side effects occur is unspecified=
.."<br><br>C++ 17 N4527 8.5.4/4: "Within the initializer-list of a=
braced-init-list ... every value computation and side effect associated wi=
th a given initializer-clause is sequenced before every value computation a=
nd side effect associated with any initializer-clause that follows it in th=
e comma-separated list of the initializer-list."</div></div></div></di=
v>
</blockquote></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/dd968f7a-58ff-4673-b66e-6c8bbbed8751%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd968f7a-58ff-4673-b66e-6c8bbbed8751=
%40isocpp.org</a>.<br />
------=_Part_26_1914000420.1468548010323--
------=_Part_25_126271844.1468548010322--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 19:22:31 -0700 (PDT)
Raw View
------=_Part_509_53248262.1468549351619
Content-Type: multipart/alternative;
boundary="----=_Part_510_1834590578.1468549351619"
------=_Part_510_1834590578.1468549351619
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=8811:50:51=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 13, 2016 at 9:37 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> At least my opinion is not only for C++. Particularly, C++ is complicate=
d=20
>> enough. So I doubt any modification of rules can be easily settle down=
=20
>> without confusion. The latter is not against to any concrete proposal, b=
ut=20
>> it counts.
>>
>
> Strict left-to-right simplifies the rules. It cannot be more confusing t=
o=20
> specify an order than to leave the order unspecified.
>
Will it really simplifies the rules, literally? I don't think so. If fact,=
=20
it depends.
There are difficulties to make "left-to-right" clear in C++. You can see=20
P0145R2 has *many *words to be inserted to the draft. (I personally only=20
think the definition inserted in 1.9/13 is beneficial because it will make=
=20
something talked here not so lengthy.) If you think you can solve the=20
problem, you should show your better and clearer wording to the committee.
Another example is the Java Language Specification with a lot of words to=
=20
clarify the attitude of authors about relying on fixed order. As informal=
=20
wording, this can surely be omitted but it may lead to more confusion.
=20
Though it is irrelevant to the core problems here, but this is the problem=
=20
you may have to solve.
>
> the changes make some portable code in previous version of C++ lose some=
=20
>> precisely specified semantics properties
>>
>
> I know you believe that it is important for C++ programmers to be able to=
=20
> express in their programs that they want subexpressions to be deliberatel=
y=20
> unordered. I believe this ability is not only unimportant, but that the=
=20
> vast majority of C++ programmers have never even thought of embedding suc=
h=20
> semantics into their code, and would not do so if informed of the=20
> possibility. I believe that it is wrong to prevent the adoption of a=20
> sensible rule that would prevent errors in code from spontaneously=20
> appearing in order to preserve the ability to express something unimporta=
nt.
>
On the contrary, I think *everyone* *should *think about it, whether=20
deciding to actually embedded it in the code or not. Side effects, in=20
traditional view of theoretical computer science, are monsters. Careless=20
use of side effects (including ignorant of which order is really needed)=20
are essential bugs (which are difficult to be checked by machines), even it=
=20
does not produce a program with unexpected behavior occasionally. To make=
=20
(esp. uneducated noob) programmers too easy to forget their danger is not a=
=20
good thing sounds to me. As an end-user, I don't want to rely on programs=
=20
with such potential risks as possible. So I believe that it is wrong to=20
make it as the default cases, at least of a serious general-purposed=20
language (rather than some configurable DSL).
So that is pure value judgment conflict. I think we are already clear about=
=20
it.
=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/e4396b24-9a22-484f-ba6f-50afacda427a%40isocpp.or=
g.
------=_Part_510_1834590578.1468549351619
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=8811:50:51=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 9:37 =
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"7lCzyFFNCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>At least my opinion is n=
ot only for C++. Particularly, C++ is complicated enough. So I doubt any mo=
dification of rules can be easily settle down without confusion. The latter=
is not against to any concrete proposal, but it counts.<br></div></div></b=
lockquote><div><br>Strict left-to-right simplifies the rules.=C2=A0 It cann=
ot be more confusing to specify an order than to leave the order unspecifie=
d.<br></div></div></div></div></blockquote><div>Will it really simplifies t=
he rules, literally? I don't think so. If fact, it depends.<br><br>Ther=
e are difficulties to make "left-to-right" clear in C++. You can =
see P0145R2 has <i>many </i>words to be inserted to the draft. (I personall=
y only think the definition inserted in 1.9/13 is beneficial because it wil=
l make something talked here not so lengthy.) If you think you can solve th=
e problem, you should show your better and clearer wording to the committee=
..<br><br>Another example is the Java Language Specification with a lot of w=
ords to clarify the attitude of authors about relying on fixed order. As in=
formal wording, this can surely be omitted but it may lead to more confusio=
n.<br>=C2=A0<br>Though it is irrelevant to the core problems here, but this=
is the problem you may have to solve.<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>the changes mak=
e some portable code in previous version of C++ lose some precisely specifi=
ed semantics properties</div></div></blockquote><div><br>I know you believe=
that it is important for C++ programmers to be able to express in their pr=
ograms that they want subexpressions to be deliberately unordered.=C2=A0 I =
believe this ability is not only unimportant, but that the vast majority of=
C++ programmers have never even thought of embedding such semantics into t=
heir code, and would not do so if informed of the possibility.=C2=A0 I beli=
eve that it is wrong to prevent the adoption of a sensible rule that would =
prevent errors in code from spontaneously appearing in order to preserve th=
e ability to express something unimportant.</div></div></div></div></blockq=
uote><div>On the contrary, I think <i>everyone</i> <i>should </i>think abou=
t it, whether deciding to actually embedded it in the code or not. Side eff=
ects, in traditional view of theoretical computer science, are monsters. Ca=
reless use of side effects (including ignorant of which order is really nee=
ded) are essential bugs (which are difficult to be checked by machines), ev=
en it does not produce a program with unexpected behavior occasionally. To =
make (esp. uneducated noob) programmers too easy to forget their danger is =
not a good thing sounds to me. As an end-user, I don't want to rely on =
programs with such potential risks as possible. So I believe that it is wro=
ng to make it as the default cases, at least of a serious general-purposed =
language (rather than some configurable DSL).<br><br>So that is pure value =
judgment conflict. I think we are already clear about it.<br><br><br>=C2=A0=
<br></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/e4396b24-9a22-484f-ba6f-50afacda427a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e4396b24-9a22-484f-ba6f-50afacda427a=
%40isocpp.org</a>.<br />
------=_Part_510_1834590578.1468549351619--
------=_Part_509_53248262.1468549351619--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 23:31:27 -0700 (PDT)
Raw View
------=_Part_53_313098851.1468564287505
Content-Type: multipart/alternative;
boundary="----=_Part_54_774631108.1468564287506"
------=_Part_54_774631108.1468564287506
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:01:28=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 13, 2016 at 10:00 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8A=E5=8D=8812:12:08=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> The "stupidity and laziness" argument demands that the programming=20
>>> language should contain constructs that must not be used, and that will=
act=20
>>> as traps for the unwary. The notion that this is a desirable feature a=
gain=20
>>> seems to me so irrational that it beggars belief.
>>>
>>> No. I don't express that. Any constructs should be used at ones' own=20
>> risks. If you don't want to use something, that's OK. If you don't want =
to=20
>> see the code use such features, then tag the code using them as of "bad=
=20
>> code style" with sufficient reasons which are *not so subjective* (when=
=20
>> you want to convince others). But "I'm not using it" is certainly not a=
=20
>> good excuse to *forbid *it used *by others through the language=20
>> specification*, unless you want to keep those users away. Since C++ is=
=20
>> not designed as noob-oriented by you, and there are some people do rely =
on=20
>> something you want to remove, I think your point is problematic. If you=
=20
>> want to remove something indisputably, you have to prove that it does=20
>> nothing useful to *almost anyone* or there are sufficient ways as=20
>> *replacement*, and/or it is harmful *in almost any case*. This is not=20
>> the case here.
>>
>
> C++ is a programming language, used to direct the actions of a computer. =
=20
> It is meaningless to say that a programming language contains constructs=
=20
> that can be "used at one's own risk". That is Stockholm Syndrome and=20
> misplaced nerd hubris. If such constructs exist in the language, it mean=
s=20
> that the language has been poorly specified, so that it is easy for=20
> programmers to use the constructs incorrectly. The solution is not to wa=
rn=20
> the programmers but to fix the language.
>
> Be practical. You use the language by writing and reading code, if you=20
does not also write specification to extend the language. There are risks=
=20
of buggy implementations. There are risks of misunderstanding the language=
=20
rules. There are risks of typos. Some of them are your responsibilities.=20
Some of them are others' responsibilities. Everything may be risky, more or=
=20
less. Do they all meaningless? How can a user avoid them totally? Or do you=
=20
mean every language is poorly specified?
=20
> Again, with respect to order of evaluation, we are speaking of specifying=
=20
> behavior which is currently unspecified. It appears to be very important=
=20
> to you that programmers be able to deliberately express in their C++ code=
=20
> that they want subexpressions to be unordered, but I believe that it is=
=20
> important to no one else, and certainly not a reason to avoid adopting a=
=20
> rule that would be of actual benefit to programmers.
>
Your belief is conflicts to the fact again. There are more than one people=
=20
needing expressiveness or opportunity of optimization only can be=20
effectively allowed by unsequenced evaluation just in this topic. I believe=
=20
there are committee members who think the same.
=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/09c411d8-7dba-463b-9f2c-5399b0143f27%40isocpp.or=
g.
------=_Part_54_774631108.1468564287506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:01:28=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 10:00=
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"_CZsG-ZNCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=
=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:1=
2:08=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">The "stupidity and laziness" arg=
ument demands that the programming language should contain constructs that =
must not be used, and that will act as traps for the unwary.=C2=A0 The noti=
on that this is a desirable feature again seems to me so irrational that it=
beggars belief.</div><div><br></div></blockquote><div>No. I don't expr=
ess that. Any constructs should be used at ones' own risks. If you don&=
#39;t want to use something, that's OK. If you don't want to see th=
e code use such features, then tag the code using them as of "bad code=
style" with sufficient reasons which are <i>not so subjective</i> (wh=
en you want to convince others).=C2=A0 But "I'm not using it"=
is certainly not a good excuse to <i>forbid </i>it used <i>by others throu=
gh the language specification</i>, unless you want to keep those users away=
.. Since C++ is not designed as noob-oriented by you, and there are some peo=
ple do rely on something you want to remove, I think your point is problema=
tic. If you want to remove something indisputably, you have to prove that i=
t does nothing useful to <i>almost anyone</i> or there are sufficient ways =
as <i>replacement</i>, and/or it is harmful <i>in almost any case</i>. This=
is not the case here.</div></div></blockquote><div><br>C++ is a programmin=
g language, used to direct the actions of a computer.=C2=A0 It is meaningle=
ss to say that a programming language contains constructs that can be "=
;used at one's own risk".=C2=A0 That is Stockholm Syndrome and mis=
placed nerd hubris.=C2=A0 If such constructs exist in the language, it mean=
s that the language has been poorly specified, so that it is easy for progr=
ammers to use the constructs incorrectly.=C2=A0 The solution is not to warn=
the programmers but to fix the language.<br><br></div></div></div></div></=
blockquote><div>Be practical. You use the language by writing and reading c=
ode, if you does not also write specification to extend the language. There=
are risks of buggy implementations. There are risks of misunderstanding th=
e language rules. There are risks of typos. Some of them are your responsib=
ilities. Some of them are others' responsibilities. Everything may be r=
isky, more or less. Do they all meaningless? How can a user avoid them tota=
lly? Or do you mean every language is poorly specified?<br><br>=C2=A0<br></=
div><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=
class=3D"gmail_quote"><div>Again, with respect to order of evaluation, we =
are speaking of specifying behavior which is currently unspecified.=C2=A0 I=
t appears to be very important to you that programmers be able to deliberat=
ely express in their C++ code that they want subexpressions to be unordered=
, but I believe that it is important to no one else, and certainly not a re=
ason to avoid adopting a rule that would be of actual benefit to programmer=
s.</div></div></div></div></blockquote><div>Your belief is conflicts to the=
fact again. There are more than one people needing expressiveness or oppor=
tunity of optimization only can be effectively allowed by unsequenced evalu=
ation just in this topic. I believe there are committee members who think t=
he same.<br>=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" 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/09c411d8-7dba-463b-9f2c-5399b0143f27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09c411d8-7dba-463b-9f2c-5399b0143f27=
%40isocpp.org</a>.<br />
------=_Part_54_774631108.1468564287506--
------=_Part_53_313098851.1468564287505--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 23:42:52 -0700 (PDT)
Raw View
------=_Part_560_308535931.1468564972096
Content-Type: multipart/alternative;
boundary="----=_Part_561_1060662420.1468564972097"
------=_Part_561_1060662420.1468564972097
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:08:01=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 13, 2016 at 10:30 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> Some of your points are plainly technically incorrect, despite of what=
=20
>> values you want to achieve. For example, the language (not only C++) is=
=20
>> certainly allowed with both specified and unspecified evaluation order o=
n=20
>> expressions, just in different cases with different grammars. You are=20
>> actually not only insisting on evaluation order; you also don't want any=
=20
>> conforming extensions, just because you think that is right. This point =
is=20
>> what I mostly against to.
>>
>
> I don't understand what this means. What grammars? What extensions? I a=
m=20
> speaking of order of evaluation in C++ expressions.
> =20
>
You can write ';' to express specific evaluation order between expressions=
=20
(though currently it can't be used in single full expression). When you=20
write ',', there there is no such guarantee currently, unless the ',' is a=
=20
builtin operator. You want to change the rule to make ',' behaves like ';'=
=20
about semantics about order. Extension like __unsequenced(x, y) can be=20
provided to override your rules of ',', but you seem to dislike them just=
=20
because you think doing that is wrong.
=20
> Further, you said you had found that designers of Java made the choice yo=
u=20
>> want, but you seem to deliberately ignore the related notes in Java=20
>> Language Specification (as I mentioned more than once), which tells you=
=20
>> that the designers of Java do not like the idea about relying on such=20
>> rules. This clearly contradicts your belief. Why you adopt the point=20
>> selectively?
>>
>
> The Java designers came from decades of having internalized the prejudice=
=20
> against relying on evaluation order because they used languages where it=
=20
> was unspecified. They decided to specify the order (and made the correct=
=20
> choices), but could not overcome the burden of their habits.
>
Why do you think that is the burden of their habits? They seem to have=20
reasons to warn people about the order rules and treat such rules are=20
merely compromise.=20
>
> I personally don't write or want to review such code.
>>
>
> Sometimes it's the code that's bad and sometimes it's the language that's=
=20
> bad. Sometimes claiming the former is a means to avoid fixing the latter=
..
>
But there are clear reason to support the former, and the reasons of the=20
latter are still based fully on personal value judgements.
--=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/8d6f7e59-e3ff-43ee-9d0d-720718c74174%40isocpp.or=
g.
------=_Part_561_1060662420.1468564972097
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:08:01=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 10:30=
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"u8Vzn0FOCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Some of your points a=
re plainly technically incorrect, despite of what values you want to achiev=
e. For example, the language (not only C++) is certainly allowed with both =
specified and unspecified evaluation order on expressions, just in differen=
t cases with different grammars. You are actually not only insisting on eva=
luation order; you also don't want any conforming extensions, just beca=
use you think that is right. This point is what I mostly against to.<br></d=
iv></div></blockquote><div><br>I don't understand what this means.=C2=
=A0 What grammars? What extensions?=C2=A0 I am speaking of order of evaluat=
ion in C++ expressions.<br>=C2=A0</div></div></div></div></blockquote><div>=
You can write ';' to express specific evaluation order between expr=
essions (though currently it can't be used in single full expression). =
When you write ',', there there is no such guarantee currently, unl=
ess the ',' is a builtin operator. You want to change the rule to m=
ake ',' behaves like ';' about semantics about order. Exten=
sion like __unsequenced(x, y) can be provided to override your rules of =
9;,', but you seem to dislike them just because you think doing that is=
wrong.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>Further, you said you had found that designers of J=
ava made the choice you want, but you seem to deliberately ignore the relat=
ed notes in Java Language Specification (as I mentioned more than once), wh=
ich tells you that the designers of Java do not like the idea about relying=
on such rules. This clearly contradicts your belief. Why you adopt the poi=
nt selectively?<br></div></div></blockquote><div><br>The Java designers cam=
e from decades of having internalized the prejudice against relying on eval=
uation order because they used languages where it was unspecified.=C2=A0 Th=
ey decided to specify the order (and made the correct choices), but could n=
ot overcome the burden of their habits.<br></div></div></div></div></blockq=
uote><div>Why do you think that is the burden of their habits? They seem to=
have reasons to warn people about the order rules and treat such rules are=
merely compromise. <br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>I personally don't write or w=
ant to review such code.</div></div></blockquote><div><br>Sometimes it'=
s the code that's bad and sometimes it's the language that's ba=
d.=C2=A0 Sometimes claiming the former is a means to avoid fixing the latte=
r.</div></div></div></div></blockquote><div>But there are clear reason to s=
upport the former, and the reasons of the latter are still based fully on p=
ersonal value judgements.<br><br></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/8d6f7e59-e3ff-43ee-9d0d-720718c74174%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d6f7e59-e3ff-43ee-9d0d-720718c74174=
%40isocpp.org</a>.<br />
------=_Part_561_1060662420.1468564972097--
------=_Part_560_308535931.1468564972096--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 23:54:36 -0700 (PDT)
Raw View
------=_Part_47_1672772278.1468565676755
Content-Type: multipart/alternative;
boundary="----=_Part_48_2124791125.1468565676755"
------=_Part_48_2124791125.1468565676755
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:11:53=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 13, 2016 at 11:02 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> Or do you really believe there can only be one evaluation order in the=
=20
>> world, or users of C++ should not touch any one of them other than=20
>> left-to-right order?
>>
>
> Yes. A programming language is used to direct the operations of a=20
> computer. The constructs of the language should be precisely defined so=
=20
> that the programmer does not write ambiguous directions. The constructs =
of=20
> the language should be defined so that it is not easy for programmers to=
=20
> unwittingly write ambiguous directions.
>
No. First, a programming language is not guaranteed to direct the=20
operations of a computer. It can be translated in multiple passes in any=20
order irrelevant to the order you imagined. This way is used by majority of=
=20
(if no all) of C++ implementations. And to eliminate necessary intermediate=
=20
layer is often bad, e.g. MSVC has difficulties to implement 2 phase name=20
lookup due to the compiler is initially designed without an AST. You have=
=20
no proof to make it not harder under your rules, which is far more=20
troublesome than bearing "ambiguous directions".
Second, the reason of defined constructs to force people does not write=20
so-called "ambiguous" directions is absurd. It's up to the users, and you=
=20
are not able to speak for all of them.
Third, even if you have disciplined every user to obey your rules=20
successfully, users can invent something they want. When they call it a=20
"language", you claims disable again.
--=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/1de9b093-0251-4bb1-a256-07f8d676e590%40isocpp.or=
g.
------=_Part_48_2124791125.1468565676755
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:11:53=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 11:02=
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"BcWcjndOCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Or do you really beli=
eve there can only be one evaluation order in the world, or users of C++ sh=
ould not touch any one of them other than left-to-right order?</div></div><=
/blockquote><div><br>Yes.=C2=A0 A programming language is used to direct th=
e operations of a computer.=C2=A0 The constructs of the language should be =
precisely defined so that the programmer does not write ambiguous direction=
s.=C2=A0 The constructs of the language should be defined so that it is not=
easy for programmers to unwittingly write ambiguous directions.</div></div=
></div></div></blockquote><div>No. First, a programming language is not gua=
ranteed to direct the operations of a computer. It can be translated in mul=
tiple passes in any order irrelevant to the order you imagined. This way is=
used by majority of (if no all) of C++ implementations. And to eliminate n=
ecessary intermediate layer is often bad, e.g. MSVC has difficulties to imp=
lement 2 phase name lookup due to the compiler is initially designed withou=
t an AST. You have no proof to make it not harder under your rules, which i=
s far more troublesome than bearing "ambiguous directions".<br>Se=
cond, the reason of defined constructs to force people does not write so-ca=
lled "ambiguous" directions is absurd. It's up to the users, =
and you are not able to speak for all of them.<br>Third, even if you have <=
span class=3D"op_dict3_font24 op_dict3_marginRight">disciplined every user =
to obey your rules successfully, users can invent something they want. When=
they call it a "language", you claims disable again.<br><br></sp=
an><br></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/1de9b093-0251-4bb1-a256-07f8d676e590%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1de9b093-0251-4bb1-a256-07f8d676e590=
%40isocpp.org</a>.<br />
------=_Part_48_2124791125.1468565676755--
------=_Part_47_1672772278.1468565676755--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 14 Jul 2016 23:58:34 -0700 (PDT)
Raw View
------=_Part_562_299770257.1468565914081
Content-Type: multipart/alternative;
boundary="----=_Part_563_1189463031.1468565914081"
------=_Part_563_1189463031.1468565914081
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:15:34=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 13, 2016 at 11:28 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>>
>> - Leave it unseqenced, if intended.
>>
>>
> The proportion of C++ code that has intentional lack of sequence is 0, to=
=20
> a great number of decimal places. Using this as a reason to not adopt=20
> rules that would prevent latent errors from being expressed years after=
=20
> they are written is wrong.
>
If this is true, it is mostly because the author has not considered about=
=20
it yet. To avoiding thinking is not worth encouraging, because it can=20
easily cause errors with significantly higher cost.
--=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/8f619ee5-5533-4629-8e96-427d79413341%40isocpp.or=
g.
------=_Part_563_1189463031.1468565914081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:15:34=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 11:28=
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"dgRy9KpOCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Leave it unse=
qenced, if intended.</li></ul></div></div></blockquote><div><br>The proport=
ion of C++ code that has intentional lack of sequence is 0, to a great numb=
er of decimal places.=C2=A0 Using this as a reason to not adopt rules that =
would prevent latent errors from being expressed years after they are writt=
en is wrong.</div></div></div></div></blockquote><div><br>If this is true, =
it is mostly because the author has not considered about it yet. To avoidin=
g thinking is not worth encouraging, because it can easily cause errors wit=
h significantly higher cost.<br><br></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/8f619ee5-5533-4629-8e96-427d79413341%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8f619ee5-5533-4629-8e96-427d79413341=
%40isocpp.org</a>.<br />
------=_Part_563_1189463031.1468565914081--
------=_Part_562_299770257.1468565914081--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 00:02:35 -0700 (PDT)
Raw View
------=_Part_555_1464645957.1468566155492
Content-Type: multipart/alternative;
boundary="----=_Part_556_610318527.1468566155493"
------=_Part_556_610318527.1468566155493
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:21:16=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 12:07 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> If people don't know enough to their languages, they have nothing to=20
>> conform.
>>
>
> The f(new T, new T) discussion first appeared in 2009, some ten years=20
> after C++ was standardized. So the people who "don't enough to their=20
> languages" included the entire universe of C++ programmers. That's not t=
he=20
> fault of the programmers, that's the fault of the language.
>
That's ashamed for attitude of some users, rather the language design.
It was 2009. Why you allow raw 'new' occurred here in such way? You should=
=20
have known that the 'new' should be used in very exceptional cases and you=
=20
don't need to worry it in general.
--=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/163371cf-7088-45c4-b874-8270c68ba7d7%40isocpp.or=
g.
------=_Part_556_610318527.1468566155493
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:21:16=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 12:07=
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"6dwDoPpOCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>If people don't know enough to =
their languages, they have nothing to conform.</div></div></blockquote><div=
><br>The <font face=3D"monospace, monospace">f(new T, new T)</font> discuss=
ion first appeared in 2009, some ten years after C++ was standardized.=C2=
=A0 So the people who "don't enough to their languages" inclu=
ded the entire universe of C++ programmers.=C2=A0 That's not the fault =
of the programmers, that's the fault of the language.</div></div></div>=
</div></blockquote><div><br>That's ashamed for attitude of some users, =
rather the language design.<br><br>It was 2009. Why you allow raw 'new&=
#39; occurred here in such way? You should have known that the 'new'=
; should be used in very exceptional cases and you don't need to worry =
it in general.<br><br></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/163371cf-7088-45c4-b874-8270c68ba7d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/163371cf-7088-45c4-b874-8270c68ba7d7=
%40isocpp.org</a>.<br />
------=_Part_556_610318527.1468566155493--
------=_Part_555_1464645957.1468566155492--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 00:11:49 -0700 (PDT)
Raw View
------=_Part_588_1039180417.1468566709541
Content-Type: multipart/alternative;
boundary="----=_Part_589_564916839.1468566709541"
------=_Part_589_564916839.1468566709541
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:26:39=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 12:22 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> At least to treat evaluation order same to some other mysterious order *=
is=20
>> *destroying the teachability because in general they are unrelated=20
>> things. I don't think encouraging such illusion is a good result of=20
>> teaching.
>>
>> If someone insist on that should be the case of C++, I'm sorry to see=20
>> that C++ stands against to the majority of intellectuals and it will for=
ces=20
>> learners to waste more time on such topics if they unfortunately touched=
=20
>> C++ at first. This result again conflicts to teachability.
>>
>
> That's correct. C++ evaluation order should be strictly left-to-right,=
=20
> and then programmers should simply be taught that this is the rule. =20
> Additionally, they might have to be untaught the PEMDAS rule they learned=
=20
> in school; in the expression a() + b() * c(), we do not order the calls=
=20
> as b(), c(), a() even though the multiplication happens before the=20
> addition.
>
That's because poor mathematical education does not teach them enough about=
=20
why this can work. As you, most of the victims have no notion of deduction=
=20
systems. Only when the expressions are free from side effects, they have no=
=20
need to care of the order. Once side effects are allowed, the world changes=
=20
totally. It is wrong to apply such poor knowledge here, it just does not=20
work.
And I should argue that PEMDAS rules are nonsense if one uses no infix=20
notation, and infix notation is often useless and harmful in many practical=
=20
cases out of school, but that is another story.
--=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/82eacbf1-e640-4d9f-878f-8b642869c467%40isocpp.or=
g.
------=_Part_589_564916839.1468566709541
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:26:39=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 12:22=
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"pRUR6UVPCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>At least to treat eva=
luation order same to some other mysterious order <i>is </i>destroying the =
teachability because in general they are unrelated things. I don't thin=
k encouraging such illusion is a good result of teaching.<br><br>If someone=
insist on that should be the case of C++, I'm sorry to see that C++ st=
ands against to the majority of intellectuals and it will forces learners t=
o waste more time on such topics if they unfortunately touched C++ at first=
.. This result again conflicts to teachability.</div></div></blockquote><div=
><br>That's correct.=C2=A0 C++ evaluation order should be strictly left=
-to-right, and then programmers should simply be taught that this is the ru=
le.=C2=A0 Additionally, they might have to be untaught the PEMDAS rule they=
learned in school; in the expression <font face=3D"monospace, monospace">a=
() + b() * c()</font>, we do not order the calls as <font face=3D"monospace=
, monospace">b()</font>, <font face=3D"monospace, monospace">c()</font>, <f=
ont face=3D"monospace, monospace">a()</font> even though the multiplication=
happens before the addition.</div></div></div></div></blockquote><div><br>=
That's because poor mathematical education does not teach them enough a=
bout why this can work. As you, most of the victims have no notion of deduc=
tion systems. Only when the expressions are free from side effects, they ha=
ve no need to care of the order. Once side effects are allowed, the world c=
hanges totally. It is wrong to apply such poor knowledge here, it just does=
not work.<br><br>And I should argue that PEMDAS rules are nonsense if one =
uses no infix notation, and infix notation is often useless and harmful in =
many practical cases out of school, but that is another story.<br><br><br><=
/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/82eacbf1-e640-4d9f-878f-8b642869c467%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82eacbf1-e640-4d9f-878f-8b642869c467=
%40isocpp.org</a>.<br />
------=_Part_589_564916839.1468566709541--
------=_Part_588_1039180417.1468566709541--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 00:17:37 -0700 (PDT)
Raw View
------=_Part_549_1311401995.1468567057434
Content-Type: multipart/alternative;
boundary="----=_Part_550_333110030.1468567057434"
------=_Part_550_333110030.1468567057434
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=882:11:30=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 12:52 PM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:
>
>> On 2016-07-14 11:50, Hyman Rosen wrote:
>> > Strict left-to-right simplifies the rules. It cannot be more confusin=
g=20
>> to
>> > specify an order than to leave the order unspecified.
>>
>> Okay... I'll dispute that.
>>
>> If order is unspecified, and code is correct only for a certain order,
>> then I know that code is broken.
>>
>> If order is specified, then I have to understand *how* the order is
>> specified in order to know if order-dependent code is correct or broken.
>>
>> Therefore, the knowledge required to make a determination as to the
>> correctness of code is *increased* by specified order.
>
>
> I would argue that increased knowledge implies decreased confusion. More=
=20
> to the point, knowing that the order is unspecified is itself knowledge. =
=20
> You say "If order is unspecified, and code is correct only for a certain=
=20
> order, then I know that code is broken." But that means that you know th=
e=20
> order is unspecified. That is the same quantum of knowledge as knowing=
=20
> that the order is particular. And the problem with unspecified order is=
=20
> when programmers do not know that the order is unspecified, or fail to=20
> notice that they are depending on a particular order because the code wor=
ks=20
> (until it doesn't).
>
No. Knowing too much is not beneficial. Requiring to know too much is=20
harmful as it is against to many goals. I doubt you are lack of knowledge=
=20
about "separating interface from implementation" and "principle of least=20
privilege".
--=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/e1e36c93-1ea1-41fb-8a00-adda8fd1a769%40isocpp.or=
g.
------=_Part_550_333110030.1468567057434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=882:11:30=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 12:52 PM=
, Matthew Woehlke <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"Lr5Ct_5UCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">mwoehlk...@gmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex">On 2016-07-14 11:50, Hyman Rosen wrote:<span><br>
> Strict left-to-right simplifies the rules.=C2=A0 It cannot be more con=
fusing to<br>
> specify an order than to leave the order unspecified.<br>
<br>
</span>Okay... I'll dispute that.<br>
<br>
If order is unspecified, and code is correct only for a certain order,<br>
then I know that code is broken.<br>
<br>
If order is specified, then I have to understand *how* the order is<br>
specified in order to know if order-dependent code is correct or broken.<br=
>
<br>
Therefore, the knowledge required to make a determination as to the<br>
correctness of code is *increased* by specified order.</blockquote><div><br=
>I would argue that increased knowledge implies decreased confusion.=C2=A0 =
More to the point, knowing that the order is unspecified is itself knowledg=
e.=C2=A0 You say "If order is unspecified, and code is correct only fo=
r a certain order,=C2=A0then I know that code is broken." =C2=A0But th=
at means that you know the order is unspecified.=C2=A0 That is the same qua=
ntum of knowledge as knowing that the order is particular.=C2=A0 And the pr=
oblem with unspecified order is when programmers do not know that the order=
is unspecified, or fail to notice that they are depending on a particular =
order because the code works (until it doesn't).</div></div></div></div=
></blockquote><div><br>No. Knowing too much is not beneficial. Requiring to=
know too much is harmful as it is against to many goals. I doubt you are l=
ack of knowledge about "separating interface from implementation"=
and "principle of least privilege".<br><br></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/e1e36c93-1ea1-41fb-8a00-adda8fd1a769%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e1e36c93-1ea1-41fb-8a00-adda8fd1a769=
%40isocpp.org</a>.<br />
------=_Part_550_333110030.1468567057434--
------=_Part_549_1311401995.1468567057434--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 00:30:13 -0700 (PDT)
Raw View
------=_Part_45_998860879.1468567813279
Content-Type: multipart/alternative;
boundary="----=_Part_46_1418500723.1468567813279"
------=_Part_46_1418500723.1468567813279
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=882:36:01=EF=BC=8CNevin ":-)" Liber=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 13 July 2016 at 21:30, FrankHB1989 <frank...@gmail.com <javascript:>>=
=20
> wrote:
>
>> Further, you said you had found that designers of Java made the choice=
=20
>> you want, but you seem to deliberately ignore the related notes in Java=
=20
>> Language Specification (as I mentioned more than once), which tells you=
=20
>> that the designers of Java do not like the idea about relying on such ru=
les.
>
>
> Which leads to the following weirdness:
>
> 1. You can't write correct code in C++ today which depends on order of=
=20
> evaluation
>
No. You can, but with some verbosity, because the language is still lack of=
=20
some mechanism to specify the order explicitly by need clearly and easily=
=20
enough.
=20
> 2. Hey, let's tighten the rules and pay a performance cost so people can=
=20
> write code which depends on order of evaluation
>
But changing rules to overriding other evaluation strategy is a not good=20
solution of that for many reasons I've discussed.
=20
> 3. But we should still *highly discourage* people from writing code=20
> which depends on order of evaluation
>
> You can't avoid people like Hyman Rosen disagreeing with you about this=
=20
point. Things grow more complicated once you accept half-baked solution=20
without enough consensus.
=20
>
> The LTR folks think code such as:
>
> char z[] =3D "abcde";
> char* p =3D z;
> *++p =3D *++p =3D *++p; // "addde"
>
> is both reasonable to write and the only obviously correct answer is=20
> "addde". I think code like this should be avoided and interleaving order=
=20
> of evaluation, associativity and order of precedence actually makes thing=
s=20
> harder to understand for non-experts, because they have to be able to rea=
d=20
> and understand code like I just presented.
>
I agree with you on this point.
But I should to say if we do not infix notations, there are no need to=20
consider precedence and associativity rules will be simplified.=20
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>=20
> +1-847-691-1404
>
--=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/9265805a-e7b6-4f2f-88f9-0cdba0195708%40isocpp.or=
g.
------=_Part_46_1418500723.1468567813279
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=882:36:01=EF=BC=8CNevin ":-=
)" Liber=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>On 13 July 2016 at 21:30, FrankHB1989 <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"tbGeLVVWCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">frank...@gmail.com</a>></span> wrote:<br><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">Further, you said you had found that=
designers of Java made the choice you want, but you seem to deliberately i=
gnore the related notes in Java Language Specification (as I mentioned more=
than once), which tells you that the designers of Java do not like the ide=
a about relying on such rules.</blockquote></div><br>Which leads to the fol=
lowing weirdness:</div><div><br></div><div>1.=C2=A0 You can't write cor=
rect code in C++ today which depends on order of evaluation</div></div></bl=
ockquote><div>No. You can, but with some verbosity, because the language is=
still lack of some mechanism to specify the order explicitly by need clear=
ly and easily enough.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>2.=C2=A0 Hey, let's tighten the rules =
and pay a performance cost so people can write code which depends on order =
of evaluation</div><div></div></div></blockquote><div>But changing rules to=
overriding other evaluation strategy is a not good solution of that for ma=
ny reasons I've discussed.<br>=C2=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>3.=C2=A0 But we should still=C2=
=A0<i>highly discourage</i>=C2=A0people from writing code which depends on =
order of evaluation</div><div><br></div></div></blockquote><div>You can'=
;t avoid people like Hyman Rosen disagreeing with you about this point. Thi=
ngs grow more complicated once you accept half-baked solution without enoug=
h consensus.<br>=C2=A0<br></div><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><br></div><div>The LTR folks think code =
such as:</div><div><br></div><div>char z[] =3D "abcde";</div><div=
>char* p =3D z;</div><div><div>*++p =3D *++p =3D *++p; =C2=A0// "addde=
"</div><div><br></div><div>is both reasonable to write and the only ob=
viously correct answer is "addde".=C2=A0 I think code like this s=
hould be avoided and interleaving order of evaluation, associativity and or=
der of precedence actually makes things harder to understand for non-expert=
s, because they have to be able to read and understand code like I just pre=
sented.</div></div></div></blockquote><div>I agree with you on this point.<=
br>But I should to say if we do not infix notations, there are no need to c=
onsider precedence and associativity rules will be simplified. <br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>--=C2=
=A0</div><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin "=
;:-)" Liber=C2=A0 <mailto:<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"tbGeLVVWCwAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">ne...@eviloverlord.com</a><wbr>> =C2=A0+1-8=
47-691-1404</div></div></div></div></div>
</div></div>
</blockquote></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/9265805a-e7b6-4f2f-88f9-0cdba0195708%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9265805a-e7b6-4f2f-88f9-0cdba0195708=
%40isocpp.org</a>.<br />
------=_Part_46_1418500723.1468567813279--
------=_Part_45_998860879.1468567813279--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 02:55:27 -0700 (PDT)
Raw View
------=_Part_571_856889943.1468576527549
Content-Type: multipart/alternative;
boundary="----=_Part_572_298139231.1468576527549"
------=_Part_572_298139231.1468576527549
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=882:47:37=EF=BC=8CNevin ":-)" Liber=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 14 July 2016 at 13:18, Hyman Rosen <hyman...@gmail.com <javascript:>>=
=20
> wrote:
>
>> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renind...@gmail.com=20
>> <javascript:>> wrote:
>>
>>> This is pointedly not true of C++; it is not used to direct the=20
>>> operations of a computer, but instead, an abstract machine.
>>>
>>
>> Well, then, let's buy an abstract machine that's 4% faster and evaluate=
=20
>> our function arguments left-to-right.
>>
>
> It's great that you live in a utopia where performance, latency, power an=
d=20
> cost never, ever matters.
>
> I'm not in that world.
>
> When I buy a laptop or a cell phone, I care about battery life, and code=
=20
> that takes more cycles tends to use more power.
>
> Sadly in this world even manufacturers do not give enough respect to=20
performance requirements...=20
To me, the biggest problem is memory efficient. Almost every browser (with=
=20
GUI) will eat up my RAM in a few minutes with normal workloads, and I have=
=20
nothing to do except to restart it periodically. (I hate OOM killer.) How=
=20
are they endorsed? And why I have no other choices?
As far as I see, easiness is one of the greatest excuse of to make bad=20
programs by the developers.
=20
> There are industries (such as HFT) where speed of calculation is directly=
=20
> tied to profitability.
>
> There are industries (such as embedded) where using a faster processor=20
> means they have to charge more for their product and customers just don't=
=20
> want to pay.
>
> Etc., etc.
>
> What I don't understand is why you aren't just writing everything in Java=
,=20
> since it's well-definedness is a much better fit for your unconstrained=
=20
> utopian world.
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>=20
> +1-847-691-1404
>
--=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/3c2ee73e-b7d7-496b-b3d5-1263c8c7049b%40isocpp.or=
g.
------=_Part_572_298139231.1468576527549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=882:47:37=EF=BC=8CNevin ":-=
)" Liber=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">On 14 July 2016 at 13:18, Hyman Rosen <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"TJl4HvdWCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">hyman...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><span>On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <span d=
ir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"TJl4HvdWCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">renind...@gmail.com</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr">This is pointedly not true of C++; it is not used to direct t=
he operations of a computer, but instead, an abstract machine.</div></block=
quote></span><div><br>Well, then, let's buy an abstract machine that=
9;s 4% faster and evaluate our function arguments left-to-right.<br></div><=
/div></div></div></blockquote><div><br></div><div>It's great that you l=
ive in a utopia where performance, latency, power and cost never, ever matt=
ers.</div><div><br></div><div>I'm not in that world.</div><div><br></di=
v><div>When I buy a laptop or a cell phone, I care about battery life, and =
code that takes more cycles tends to use more power.</div><div><br></div></=
div></div></div></blockquote><div>Sadly in this world even manufacturers do=
not give enough respect to performance requirements... <br><br>To me, the =
biggest problem is memory efficient. Almost every browser (with GUI) will e=
at up my RAM in a few minutes with normal workloads, and I have nothing to =
do except to restart it periodically. (I hate OOM killer.) How are they end=
orsed? And why I have no other choices?<br><br>As far as I see, easiness is=
one of the greatest excuse of to make bad programs by the developers.<br>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>There are industries (su=
ch as HFT) where speed of calculation is directly tied to profitability.</d=
iv><div><br></div><div>There are industries (such as embedded) where using =
a faster processor means they have to charge more for their product and cus=
tomers just don't want to pay.</div><div><br></div><div>Etc., etc.</div=
><div><br></div><div>What I don't understand is why you aren't just=
writing everything in Java, since it's well-definedness is a much bett=
er fit for your unconstrained utopian world.</div></div>-- <br><div><div di=
r=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"TJl4HvdWCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">ne...@eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div></=
div></div></div></div>
</div></div>
</blockquote></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/3c2ee73e-b7d7-496b-b3d5-1263c8c7049b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c2ee73e-b7d7-496b-b3d5-1263c8c7049b=
%40isocpp.org</a>.<br />
------=_Part_572_298139231.1468576527549--
------=_Part_571_856889943.1468576527549--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 04:00:53 -0700 (PDT)
Raw View
------=_Part_26_479653519.1468580453239
Content-Type: multipart/alternative;
boundary="----=_Part_27_1251097816.1468580453239"
------=_Part_27_1251097816.1468580453239
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=883:04:55=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 2:46 PM, Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>> wrote:
>
>> On 14 July 2016 at 13:18, Hyman Rosen <hyman...@gmail.com <javascript:>>=
=20
>> wrote:
>>
>>> On Thu, Jul 14, 2016 at 2:01 PM, Ren Industries <renind...@gmail.com=20
>>> <javascript:>> wrote:
>>>
>>>> This is pointedly not true of C++; it is not used to direct the=20
>>>> operations of a computer, but instead, an abstract machine.
>>>>
>>>
>>> Well, then, let's buy an abstract machine that's 4% faster and evaluate=
=20
>>> our function arguments left-to-right.
>>>
>>
>> It's great that you live in a utopia where performance, latency, power=
=20
>> and cost never, ever matters.
>>
>
> I don't live in that utopia, "Ren Industries" does. In my world, C++ is=
=20
> used to direct actions of computers, not abstract machines.
>
> Then you are alien. In this world, semantics of C++ is defined by abstrac=
t=20
machine, which is explicit in the standard. Machines usually run code=20
transformed from C++, but not C++ source. The compiler frontend needs to=20
know nothing about machine when generating machine-independent code.
=20
> What I don't understand is why you aren't just writing everything in Java=
,=20
>> since it's well-definedness is a much better fit for your unconstrained=
=20
>> utopian world.
>>
>
> I work in whatever language my shop requires. We happen to use C++. I'v=
e=20
> programmed in the past using Java.
> "If you don't like that the Ford Pinto catches fire, go drive another=20
> car." is not a compelling argument for driving Ford Pintos.
>
To reduce all kinds of cost, try to ask turning back to Java.
--=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/9c3b7230-5d2f-4ad9-a162-28ac93eafad5%40isocpp.or=
g.
------=_Part_27_1251097816.1468580453239
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:04:55=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 2:46 PM,=
Nevin Liber <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"RqghvuhXCwAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">ne...@eviloverlord.com</a>></span> wrote:<=
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"><span>On 14 July 2016 at=
13:18, Hyman Rosen <span dir=3D"ltr"><<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"RqghvuhXCwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">hyman...@gmail.com</a>></span> wr=
ote:<br></span><div><div class=3D"gmail_quote"><span><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span>On Thu, Jul=
14, 2016 at 2:01 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RqghvuhXCwAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">renind...@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">This is pointedly=
not true of C++; it is not used to direct the operations of a computer, bu=
t instead, an abstract machine.</div></blockquote></span><div><br>Well, the=
n, let's buy an abstract machine that's 4% faster and evaluate our =
function arguments left-to-right.<br></div></div></div></div></blockquote><=
div><br></div></span><div>It's great that you live in a utopia where pe=
rformance, latency, power and cost never, ever matters.</div></div></div></=
div></blockquote><div><br>I don't live in that utopia, "Ren Indust=
ries" does.=C2=A0 In my world, C++ is used to direct actions of comput=
ers, not abstract machines.<br><br></div></div></div></div></blockquote><di=
v>Then you are alien. In this world, semantics of C++ is defined by abstrac=
t machine, which is explicit in the standard. Machines usually run code tra=
nsformed from C++, but not C++ source. The compiler frontend needs to know =
nothing about machine when generating machine-independent code.<br>=C2=A0<b=
r></div><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 class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>What I don't understand=
is why you aren't just writing everything in Java, since it's well=
-definedness is a much better fit for your unconstrained utopian world.</di=
v></div></div></div></blockquote><div><br>I work in whatever language my sh=
op requires.=C2=A0 We happen to use C++.=C2=A0 I've programmed in the p=
ast using Java.<br>"If you don't like that the Ford Pinto catches =
fire, go drive another car." is not a compelling argument for driving =
Ford Pintos.</div></div></div></div></blockquote><div>To reduce all kinds o=
f cost, try to ask turning back to Java.<br><br></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/9c3b7230-5d2f-4ad9-a162-28ac93eafad5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9c3b7230-5d2f-4ad9-a162-28ac93eafad5=
%40isocpp.org</a>.<br />
------=_Part_27_1251097816.1468580453239--
------=_Part_26_479653519.1468580453239--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 04:08:10 -0700 (PDT)
Raw View
------=_Part_563_1803638410.1468580890897
Content-Type: multipart/alternative;
boundary="----=_Part_564_926875274.1468580890898"
------=_Part_564_926875274.1468580890898
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=883:43:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 3:19 PM, Ren Industries <renind...@gmail.com=20
> <javascript:>> wrote:
>
>> The point being that a programming language does not exist to direct the=
=20
>> operations of a computer; it's domain is computer science. Practical=20
>> implications, *implementation details*, are not necessarily its domain.=
=20
>> You continually assert how something *should be, *without evidence.
>>
>
> If programming languages do not exist to direct the operations of a=20
> computer, and their domain is computer science, then constant factors are=
=20
> irrelevant. Computer science does not care if algorithms run twice as=20
> fast, it only cares about running speed as asymptotic to a function of=20
> problem size.
>
This is not I heard. Computer architecture study *is *concerned about the=
=20
constant factor.
>
> In any case, I am not talking about implementation details, I am asking=
=20
> that the behavior of certain programs which are currently unspecified=20
> should be specified. This strictly increases the number of possible lega=
l=20
> programs. Why is that objectionable for a program that runs on computer=
=20
> science abstract machines?
>
> You are asking exposing implementation details into interface constraints=
,=20
*unconditionally*.
=20
To increase the number of possible legal programs is not the goal of a=20
practical language. Why bother a language worrying about too few programs=
=20
are legal?
=20
> The practical implications of order of evaluation are that they restrict=
=20
>> what can be said in the language, and they restrict what platforms that=
=20
>> language can be ported to *efficiently*. That means it is not simply a=
=20
>> "should" question, despite the fact you repeatedly assert differently. 4=
%=20
>> is not a small barrier; I've often had to restructure code to get less o=
f a=20
>> performance gain. I shouldn't have to pay that cost because you believe=
=20
>> people should not have to think about their code as hard.
>>
>
> That "4%" is a scare number. Looking here=20
> <https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01075.html>, Jason Merrill=
=20
> says "In my own SPEC runs with an earlier version of the patch, most of=
=20
> the C++ tests did not change significantly, but xalancbmk slowed down=20
> about 1%."
>
> However, simply adding syntax to enforce a left to right evaluation=20
>> strategy solves both of our problems; you can teach people that, and I c=
an=20
>> continue to write high performing code. Why no comments on that idea,=20
>> beyond your dogmatic approach that something "should" be some way withou=
t=20
>> evidence?
>>
>
> Because adding new syntax so that people can choose not to use it and=20
> continue to write potentially broken code is silly, when the change to th=
e=20
> language would not affect the legality or behavior of currently legal=20
> programs.
>
You still have no evidence beyond your personal value judgement. That seems=
=20
to be ignorance and prejudice.
--=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/58004604-62f5-43f2-bd14-65b08dfb911e%40isocpp.or=
g.
------=_Part_564_926875274.1468580890898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:43:24=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 3:19 PM,=
Ren Industries <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"3fEjiAJaCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">renind...@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">The point being that a programming lan=
guage does not exist to direct the operations of a computer; it's domai=
n is computer science. Practical implications, <i>implementation details</i=
>, are not necessarily its domain. You continually assert how something <i>=
should be, </i>without evidence.</div></blockquote><div><br>If programming =
languages do not exist to direct the operations of a computer, and their do=
main is computer science, then constant factors are irrelevant.=C2=A0 Compu=
ter science does not care if algorithms run twice as fast, it only cares ab=
out running speed as asymptotic to a function of problem size.<br></div></d=
iv></div></div></blockquote><div>This is not I heard. Computer architecture=
study <i>is </i>concerned about the constant factor.<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div><br>In any case, I am not talking about implementation details,=
I am asking that the behavior of certain programs which are currently unsp=
ecified should be specified.=C2=A0 This strictly increases the number of po=
ssible legal programs.=C2=A0 Why is that objectionable for a program that r=
uns on computer science abstract machines?<br><br></div></div></div></div><=
/blockquote><div>You are asking exposing implementation details into interf=
ace constraints, <i>unconditionally</i>.<br>=C2=A0<br>To increase the numbe=
r of possible legal programs is not the goal of a practical language. Why b=
other a language worrying about too few programs are legal?<br>=C2=A0<br></=
div><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=
class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
The practical implications of order of evaluation are that they restrict wh=
at can be said in the language, and they restrict what platforms that langu=
age can be ported to=C2=A0<i>efficiently</i>. That means it is not simply a=
"should" question, despite the fact you repeatedly assert differ=
ently. 4% is not a small barrier; I've often had to restructure code to=
get less of a performance gain. I shouldn't have to pay that cost beca=
use you believe people should not have to think about their code as hard.</=
div></div></blockquote><div><br>That "4%" is a scare number.=C2=
=A0 Looking=C2=A0<a href=3D"https://gcc.gnu.org/ml/gcc-patches/2016-06/msg0=
1075.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fml%2Fgcc-pat=
ches%2F2016-06%2Fmsg01075.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEkJ3=
WntPgs2_bC2TVxyGaI_l541w';return true;" onclick=3D"this.href=3D'htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fml%2Fgcc-patches%2=
F2016-06%2Fmsg01075.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEkJ3WntPgs=
2_bC2TVxyGaI_l541w';return true;">here</a>, Jason Merrill says <font fa=
ce=3D"arial, helvetica, sans-serif">"<tt style=3D"color:rgb(0,0,0)">In=
my own SPEC runs with an earlier version of the patch, most of the=C2=A0</=
tt><tt style=3D"color:rgb(0,0,0)">C++ tests did not change significantly, b=
ut xalancbmk slowed down about=C2=A0</tt><tt style=3D"color:rgb(0,0,0)">1%.=
"</tt><br></font><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Howe=
ver, simply adding syntax to enforce a left to right evaluation strategy so=
lves both of our problems; you can teach people that, and I can continue to=
write high performing code. Why no comments on that idea, beyond your dogm=
atic approach that something "should" be some way without evidenc=
e?</div></div></blockquote><div><br>Because adding new syntax so that peopl=
e can choose not to use it and continue to write potentially broken code is=
silly, when the change to the language would not affect the legality or be=
havior of currently legal programs.</div></div></div></div></blockquote><di=
v>You still have no evidence beyond your personal value judgement. That see=
ms to be ignorance and prejudice.<br><br></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/58004604-62f5-43f2-bd14-65b08dfb911e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58004604-62f5-43f2-bd14-65b08dfb911e=
%40isocpp.org</a>.<br />
------=_Part_564_926875274.1468580890898--
------=_Part_563_1803638410.1468580890897--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 15 Jul 2016 04:24:30 -0700 (PDT)
Raw View
------=_Part_34_746038339.1468581870968
Content-Type: multipart/alternative;
boundary="----=_Part_35_585815742.1468581870968"
------=_Part_35_585815742.1468581870968
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=887:21:43=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 7:03 PM, 'Edward Catmur' via ISO C++ Standard -=
=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>
>> A program with unspecified behavior (and most non trivial programs have=
=20
>> some unspecified behavior) still has defined meaning, it just has a wide=
r=20
>> behavior class than a program equivalent but specifying that behavior. E=
ven=20
>> a program with undefined behavior may not be entirely undefined in meani=
ng,=20
>> if there exists an input that avoids the undefined behavior (eg. by=20
>> halting).
>>
>
> I agree, but as I said, I see this as the problem, not as the=20
> opportunity. The compiler has a much wider notion of the behavior class =
of=20
> a program with unspecified (and undefined, even more so) behavior than th=
e=20
> programmer does when the programmer does not notice the dependency on=20
> unspecified behavior. So the compiler translates the source program to a=
=20
> machine language program that it believes is in the same behavior class b=
ut=20
> which the programmer does not.
>
Programs have the semantics. Whether the semantics meet to the required=20
meaning depends. Behavior is the external appearance of the program being=
=20
executed. It is not related to meaning directly. If there is no=20
specification of what problems set the program should solve, it just can't=
=20
be judged as meaningful one or not.
To provide different behavior "class"es is useful to clarify the=20
responsibility. Existence of any undefined behavior will make you lose the=
=20
guarantees of any predictable properties from the semantic rules.=20
Unspecified behavior exists as a way to specify what you should not rely on=
=20
but still allowed to be presented. Well-defined behavior is the predictable=
=20
thing you can safely rely on. These notions have nothing to do with=20
compilers; they are contents of the contract among designers of the=20
language, authors of the implementations and users of the=20
language/implementations (programmers). Concrete machines here are again=20
irrelevant because they are merely implementation details.
--=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/82b7696b-d748-4824-a6f1-aec749e1904a%40isocpp.or=
g.
------=_Part_35_585815742.1468581870968
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=887:21:43=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 7:03 PM,=
'Edward Catmur' via ISO C++ Standard - Future Proposals <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"-daiTuxlCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">std-pr...@isocpp.org</a>></span> wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<p dir=3D"ltr">A program with unspecified behavior (and most non trivial pr=
ograms have some unspecified behavior) still has defined meaning, it just h=
as a wider behavior class than a program equivalent but specifying that beh=
avior. Even a program with undefined behavior may not be entirely undefined=
in meaning, if there exists an input that avoids the undefined behavior (e=
g. by halting).</p></blockquote><div><br>I agree, but as I said, I see this=
as the problem, not as the opportunity.=C2=A0 The compiler has a much wide=
r notion of the behavior class of a program with unspecified (and undefined=
, even more so) behavior than the programmer does when the programmer does =
not notice the dependency on unspecified behavior.=C2=A0 So the compiler tr=
anslates the source program to a machine language program that it believes =
is in the same behavior class but which the programmer does not.</div></div=
></div></div></blockquote><div>Programs have the semantics. Whether the sem=
antics meet to the required meaning depends. Behavior is the external appea=
rance of the program being executed. It is not related to meaning directly.=
If there is no specification of what problems set the program should solve=
, it just can't be judged as meaningful one or not.<br><br>To provide d=
ifferent behavior "class"es is useful to clarify the responsibili=
ty. Existence of any undefined behavior will make you lose the guarantees o=
f any predictable properties from the semantic rules. Unspecified behavior =
exists as a way to specify what you should not rely on but still allowed to=
be presented. Well-defined behavior is the predictable thing you can safel=
y rely on. These notions have nothing to do with compilers; they are conten=
ts of the contract among designers of the language, authors of the implemen=
tations and users of the language/implementations (programmers). Concrete m=
achines here are again irrelevant because they are merely implementation de=
tails.<br></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/82b7696b-d748-4824-a6f1-aec749e1904a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82b7696b-d748-4824-a6f1-aec749e1904a=
%40isocpp.org</a>.<br />
------=_Part_35_585815742.1468581870968--
------=_Part_34_746038339.1468581870968--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 09:25:09 -0400
Raw View
--001a114084686097850537ac8dcf
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 7:35 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Since you have to know something, how is knowing "the order is unspecified"
> different from knowing "the order is specified as XYZ" ?
>
When the order is specified, you don't have to know it. If you write code
with an order dependency, the order will always be the same. So either it
immediately doesn't work and you fix it, or it does work and then it will
work forever. When the order is unspecified and you write code with an
order dependency and it works, that latent error may manifest years later.
And that last is true even when you know that the order is unspecified,
because it's easy to make a mistake and not notice.
As many have pointed out, LTR is not as intuitive as it might seem to you.
It's not that it's intuitive, it's that it's trivially easy to learn. The
first time you need to know the order (presumably because you wrote
order-dependent code that went the wrong way), you learn the rule, which
can be expressed in one sentence, and it's so sharp and clear that you
never forget it. Instead we have the hash that C, C++, and now C++17 have
made of things.
--
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/CAHSYqda124XgDv7Pbxrkq%2BffCs4iX_BD%2BKDSyw7aEG-bJGfpHw%40mail.gmail.com.
--001a114084686097850537ac8dcf
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, Jul 14, 2016 at 7:35 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Since you have to know somet=
hing, how is knowing "the order is unspecified"<br>
different from knowing "the order is specified as XYZ" ?<br></blo=
ckquote><div><br>When the order is specified, you don't have to know it=
..=C2=A0 If you write code with an order dependency, the order will always b=
e the same.=C2=A0 So either it immediately doesn't work and you fix it,=
or it does work and then it will work forever.=C2=A0 When the order is uns=
pecified and you write code with an order dependency and it works, that lat=
ent error may manifest years later.=C2=A0 And that last is true even when y=
ou know that the order is unspecified, because it's easy to make a mist=
ake and not notice.<br><br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As many have pointed out, LTR is not as intuitive as it might seem to you.<=
/blockquote><div><br></div><div>It's not that it's intuitive, it=
9;s that it's trivially easy to learn.=C2=A0 The first time you need to=
know the order (presumably because you wrote order-dependent code that wen=
t the wrong way), you learn the rule, which can be expressed in one sentenc=
e, and it's so sharp and clear that you never forget it.=C2=A0 Instead =
we have the hash that C, C++, and now C++17 have made of things.</div></div=
></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/CAHSYqda124XgDv7Pbxrkq%2BffCs4iX_BD%2=
BKDSyw7aEG-bJGfpHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda124Xg=
Dv7Pbxrkq%2BffCs4iX_BD%2BKDSyw7aEG-bJGfpHw%40mail.gmail.com</a>.<br />
--001a114084686097850537ac8dcf--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 09:31:38 -0400
Raw View
--001a114c843a879aaa0537aca488
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 7:44 PM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> Yes. You changed the argument, though, by putting the parentheses.
>
How does that change the argument?
I would have personally preferred depth-first, associativity, based on
> precedence order, so
>
> a = b = c = d;
>
> should be equivalent to:
> c = d;
> b = c;
> a = b;
>
> and
> a + b * c
> would be
> decltype(auto) x = b * c;
> a + x;
> which implies an evaluation order of b, c, a.
That's even worse than the mess we have now. I don't know whether to
congratulate you or cry.
Following your suggestion, a + b * c evaluates in the order b, c, a while a
* x + b * c evaluates in the order a, x, b, c?
Do you see why this is not a good idea?
--
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/CAHSYqdaq4xrb-Ju3CW7gDQeOf7iQDcJUjhc7%2BCOCBVas%2BjGyvA%40mail.gmail.com.
--001a114c843a879aaa0537aca488
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, Jul 14, 2016 at 7:44 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">Yes. You changed the argumen=
t, though, by putting the parentheses.<br></blockquote><div><br></div><div>=
How does that change the argument?<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">I would have personally preferred depth-first, associativity, based on<=
br>
precedence order, so<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D b =3D c =3D d;<br>
<br>
should be equivalent to:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c =3D d;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b =3D c;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D b;<br>
<br>
and<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a + b * c<br>
would be<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(auto) x =3D b * c;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a + x;<br>
which implies an evaluation order of b, c, a.</blockquote><div><br></div><d=
iv>That's even worse than the mess we have now.=C2=A0 I don't know =
whether to congratulate you or cry.<br>Following your suggestion, a + b * c=
evaluates in the order b, c, a while a * x + b * c evaluates in the order =
a, x, b, c?<br>Do you see why this is not a good idea?=C2=A0</div></div></d=
iv></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/CAHSYqdaq4xrb-Ju3CW7gDQeOf7iQDcJUjhc7=
%2BCOCBVas%2BjGyvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaq4xrb=
-Ju3CW7gDQeOf7iQDcJUjhc7%2BCOCBVas%2BjGyvA%40mail.gmail.com</a>.<br />
--001a114c843a879aaa0537aca488--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 09:40:35 -0400
Raw View
--94eb2c06fb2e934f3d0537acc4d3
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 7:48 PM, Ren Industries <renindustries@gmail.com>
wrote:
> Okay? But that is clearly an opportunity, not a problem. It is only a
> problem when programmers poorly use their tools; it is an opportunity
> always to the compiler. What you see it as doesn't matter; it is clearly,
> mathematically, an opportunity.
>
Blaming users is how designers always try to deflect blame from their own
errors.
"A user interface is like a joke. If you have to explain it, it's not very
good."
In this case, one piece of language design has sent thousands of
programmers down the garden path. That is bad design. The "opportunity"
that compilers are taking advantage of is illusory - it leads them to
create translated programs that do not do what the authors of the original
programs want them to do. When the problem is discovered, the original
programs need to be rewritten so that the "opportunity" goes away.
--
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/CAHSYqdY1z1z%2B1XCecqY-kaJObm4n7er6m0FrtnF9YHgzXCFXSA%40mail.gmail.com.
--94eb2c06fb2e934f3d0537acc4d3
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, Jul 14, 2016 at 7:48 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Okay? But that is clearly an opportunity, not a problem. It is only a prob=
lem when programmers poorly use their tools; it is an opportunity always to=
the compiler. What you see it as doesn't matter; it is clearly, mathem=
atically, an opportunity.</div></blockquote><div><br></div><div>Blaming use=
rs is how designers always try to deflect blame from their own errors.<br>&=
quot;A user interface is like a joke.=C2=A0 If you have to explain it, it&#=
39;s not very good."<br><br>In this case, one piece of language design=
has sent thousands of programmers down the garden path.=C2=A0 That is bad =
design.=C2=A0 The "opportunity" that compilers are taking advanta=
ge of is illusory - it leads them to create translated programs that do not=
do what the authors of the original programs want them to do.=C2=A0 When t=
he problem is discovered, the original programs need to be rewritten so tha=
t the "opportunity" goes away.</div></div></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/CAHSYqdY1z1z%2B1XCecqY-kaJObm4n7er6m0=
FrtnF9YHgzXCFXSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY1z1z%2B=
1XCecqY-kaJObm4n7er6m0FrtnF9YHgzXCFXSA%40mail.gmail.com</a>.<br />
--94eb2c06fb2e934f3d0537acc4d3--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 09:53:21 -0400
Raw View
--94eb2c123a1034da4a0537acf21b
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 8:29 PM, Patrice Roy <patricer@gmail.com> wrote:
>
> For some, a 2% performance penalty is minor, but for a sizeable portion of
> C++ programmers, including those I work with (the SG14 crowd, essentially)
> it is not.
>
For the record, this is a small performance penalty on one benchmark of a
suite. It is being quoted as if it represents that much of a penalty to
all C++ programs.
--
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/CAHSYqdah_GdPH9yi9f%2Bb15qH8FVLM-kDQFvQ0Ju__S3Q78rj3Q%40mail.gmail.com.
--94eb2c123a1034da4a0537acf21b
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, Jul 14, 2016 at 8:29 PM, Patrice Roy <span dir=3D"ltr"><<a href=3D"m=
ailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>></spa=
n> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>For some=
, a 2% performance penalty is minor, but for a sizeable portion of C++ prog=
rammers, including those I work with (the SG14 crowd, essentially) it is no=
t.</div></div></div></blockquote><div><br></div><div>For the record, this i=
s a small performance penalty on one benchmark of a suite.=C2=A0 It is bein=
g quoted as if it represents that much of a penalty to all C++ programs.</d=
iv></div></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/CAHSYqdah_GdPH9yi9f%2Bb15qH8FVLM-kDQF=
vQ0Ju__S3Q78rj3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdah_GdPH9=
yi9f%2Bb15qH8FVLM-kDQFvQ0Ju__S3Q78rj3Q%40mail.gmail.com</a>.<br />
--94eb2c123a1034da4a0537acf21b--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 10:31:58 -0400
Raw View
--94eb2c048e44561f830537ad7c08
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 9:42 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> First, you *have* got a way to fix evaluation long ago. Even without
> statements, with some monadic tricks, f1(f2(f3(...))) *can *enforce the
> order, just with a weird syntax in traditional ALGOL/C guys' view.
>
No. My goal is not to find a way to express fixed order of evaluation. My
goal is to have all expressions have fixed order of evaluation, because we
know from experience that having unspecified order leads to latent errors.
I want that fixed order to be strict left-to-right because that is the
easiest order to learn and remember, and matches the order in which code is
written and read.
> So actually you are disappointing with another problem. You want to forbid
> others to use unsequenced evaluation (at least, by default) but they don't
> agree with you. And why?
>
The only "other" who wants to express unsequenced evaluation in C++ appears
to be you. Can you, for example, point to a C++ textbook which explains to
its readers how to deliberately express such a thing, as opposed to warning
them on how to avoid it? It should not be the case that the language
design privileges an obscure ability used by no programmers (with
probability 1) when it leads to many programmers introducing latent errors
into their code. That's why.
> Second, as said, to choose the order solely by compiler is often very
> difficult, if not impossible. The compiler is forced to prove the
> equivalence between the program semantics before and after transformation
> without explicit unsequenced evaluation guarantee. In practice, this has
> almost the same effect to forbid such optimization.
>
No one (with probability 1) cares. I understand you feel that specifying
unsequenced behavior is important. I am trying to tell you, over and over
again, that it isn't important to anyone else (with probability 1). No
programmer (with probability 1) sits down and thinks "how do I tell the
compiler to evaluate these subexpressions in arbitrary order".
If you still think this don't make sense, consider similar cases:
>
> - Why bother to specify the special cases cannot handled by the as-if
> rules (e.g. copy elision and merging operator new calls)?
>
> Merging operator new calls is a bad idea too. Requiring copy elision
helps when returning objects that use custom allocators.
>
> - Why not just use GC everywhere and believe compiler will insert
> destructor/finalizer calls appropriately?
>
> GC is one aspect of resource handling; the RAII paradigm unifies all
resource handling. What does "compiler will insert calls appropriately"
mean, and why is that a bad thing? The compiler currently expends a great
deal of effort to insert appropriate destructor calls for stack unwinding
during exception handling, for example. Experience shows as well that GC
does not relieve programmers from the problem of resource control over
memory. See Java References: From Strong to Soft to Weak to Phantom
<https://www.rallydev.com/blog/engineering/java-references-strong-soft-weak-phantom>,
for
example.
>
> - Why allow undefined behavior?
>
> Indeed. Undefined behavior is a curse on the language and should be
eliminated wherever possible.
> Most code relying on an explicit order without is already broken before
> the rules are settled.
>
That's the point. That's why the language needs explicit order. It's
because code is broken silently. It appears to work because the platform
on which it is built matches the programmer's expectation, and will break
when built on another platform
> If you want to have multiple side effects, you *should *care the
> evaluation order related to side effects.
>
Yes. And that means that there should be such an order.
> Hymans is wrong because he assumes this order is always the same with
> lexical order, which is not true in general - the language or the machine
> just does not work in that way without fixed order rules enforced
> artificially.
>
I do not "assume" that this is the order, I *want* this to be the order.
And "artificially"? I wasn't aware that programming languages are in any
way natural. Programming languages are intelligently (sometimes) designed
artifacts. Whether or not they define evaluation order is a choice made by
the designer. Neither choice is "natural". Some choices are merely
longstanding.
And since the rules were not there, you should not depend on those rules in
> analysis the necessity of the fixed order, otherwise it is somehow circular
> justification. Without such rules, the expressions are confusing. So they
> are already broken.
>
Again: the necessity for fixed order is that programmers accidentally write
code that depends on a fixed order without realizing that they have done
so, and their code works because their platform's order of evaluation
matches what they want. But since that order is not required, this is a
latent error that may manifest years later when the program is built on a
different platform.
As of safety and security, I think you ignored an important fact. If a
> program *behaves *normally, it is not naturally guaranteed to behave
> normally forever. To make it safe and secure, you should take actions *before
> it runs*. Think twice: why people are scared by undefined behavior? As
> I've said, fixing the order is not safe and secure. It evens make the
> effort less effective: it may hide bugs which cannot easily be checked by
> machines (i.e. most people may be lazy and ignore them until there is
> strange behavior), cause more unsafe and insecure code in nature.
>
This is backwards and wrong. When the language has unspecified and
undefined behavior, this means that translated programs can work in a
variety of ways, some of which may be contrary to the intentions of the
programmer who did not realize that such behavior was allowed. When a
programmer is dealing only with specified and defined behavior, then the
program will indeed work normally forever; a change in platform cannot
change the behavior of the program.
Undefined behavior is bad. Unspecified behavior is bad.
--
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/CAHSYqdaavPVwvbJH4o%2BpfLUcmRtuaAGC5S_G%3D%3DsoqjRGQtu2Jw%40mail.gmail.com.
--94eb2c048e44561f830537ad7c08
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, Jul 14, 2016 at 9:42 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>First, you <i>have</i=
> got a way to fix evaluation long ago. Even without statements, with some =
monadic tricks, f1(f2(f3(...))) <i>can </i>enforce the order, just with a w=
eird syntax in traditional ALGOL/C guys' view.<br></div></div></blockqu=
ote><div><br></div><div>No.=C2=A0 My goal is not to find a way to express f=
ixed order of evaluation.=C2=A0 My goal is to have all expressions have fix=
ed order of evaluation, because we know from experience that having unspeci=
fied order leads to latent errors.=C2=A0 I want that fixed order to be stri=
ct left-to-right because that is the easiest order to learn and remember, a=
nd matches the order in which code is written and read.</div><div>=C2=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div>So actually you are disappoin=
ting with another problem. You want to forbid others to use unsequenced eva=
luation (at least, by default) but they don't agree with you. And why?<=
br></div></div></blockquote><div><br></div><div>The only "other" =
who wants to express unsequenced evaluation in C++ appears to be you.=C2=A0=
Can you, for example, point to a C++ textbook which explains to its reader=
s how to deliberately express such a thing, as opposed to warning them on h=
ow to avoid it?=C2=A0 It should not be the case that the language design pr=
ivileges an obscure ability used by no programmers (with probability 1) whe=
n it leads to many programmers introducing latent errors into their code.=
=C2=A0 That's why.</div><div>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>Second, as said, to choose the order solely by compiler is of=
ten very difficult, if not impossible. The compiler is forced to prove the =
equivalence between the program semantics before and after transformation w=
ithout explicit unsequenced evaluation guarantee. In practice, this has alm=
ost the same effect to forbid such optimization.</div></div></blockquote><d=
iv><br></div><div>No one (with probability 1) cares.=C2=A0 I understand you=
feel that specifying unsequenced behavior is important.=C2=A0 I am trying =
to tell you, over and over again, that it isn't important to anyone els=
e (with probability 1).=C2=A0 No programmer (with probability 1) sits down =
and thinks "how do I tell the compiler to evaluate these subexpression=
s in arbitrary order".</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div> If you still think this don't make sense, consider simil=
ar cases:<br><ul><li>Why bother to specify the special cases cannot handled=
by the as-if rules (e.g. copy elision and merging operator new calls)?<br>=
</li></ul></div></div></blockquote><div>Merging operator new calls is a bad=
idea too.=C2=A0 Requiring copy elision helps when returning objects that u=
se custom allocators.</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><ul><li>W=
hy not just use GC everywhere and believe compiler will insert destructor/f=
inalizer calls appropriately?</li></ul></div></div></blockquote><div>GC is =
one aspect of resource handling; the RAII paradigm unifies all resource han=
dling.=C2=A0 What does "compiler will insert calls appropriately"=
mean, and why is that a bad thing?=C2=A0 The compiler currently expends a =
great deal of effort to insert appropriate destructor calls for stack unwin=
ding during exception handling, for example.=C2=A0 Experience shows as well=
that GC does not relieve programmers from the problem of resource control =
over memory.=C2=A0 See=C2=A0<a href=3D"https://www.rallydev.com/blog/engine=
ering/java-references-strong-soft-weak-phantom">Java References: From Stron=
g to Soft to Weak to Phantom</a>,=C2=A0for example.<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div><ul><li>Why allow undefined behavior?</li></ul></d=
iv></div></blockquote><div>Indeed.=C2=A0 Undefined behavior is a curse on t=
he language and should be eliminated wherever possible.<br>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>Most code relying on an explicit order w=
ithout is already broken before the rules are settled.</div></div></blockqu=
ote><div><br></div><div>That's the point.=C2=A0 That's why the lang=
uage needs explicit order.=C2=A0 It's because code is broken silently.=
=C2=A0 It appears to work because the platform on which it is built matches=
the programmer's expectation, and will break when built on another pla=
tform</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> If =
you want to have multiple side effects, you <i>should </i>care the evaluati=
on order related to side effects.</div></div></blockquote><div><br></div><d=
iv>Yes.=C2=A0 And that means that there should be such an order.</div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> Hymans is wrong bec=
ause he assumes this order is always the same with lexical order, which is =
not true in general - the language or the machine just does not work in tha=
t way without fixed order rules enforced artificially.</div></div></blockqu=
ote><div><br></div><div>I do not "assume" that this is the order,=
I *want* this to be the order.=C2=A0 And "artificially"?=C2=A0 I=
wasn't aware that programming languages are in any way natural.=C2=A0 =
Programming languages are intelligently (sometimes) designed artifacts.=C2=
=A0 Whether or not they define evaluation order is a choice made by the des=
igner.=C2=A0 Neither choice is "natural".=C2=A0 Some choices are =
merely longstanding.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div> And since the rules were not there, you should not depend on those ru=
les in analysis the necessity of the fixed order, otherwise it is somehow c=
ircular justification. Without such rules, the expressions are confusing. S=
o they are already broken.<br></div></div></blockquote><div><br></div><div>=
Again: the necessity for fixed order is that programmers accidentally write=
code that depends on a fixed order without realizing that they have done s=
o, and their code works because their platform's order of evaluation ma=
tches what they want.=C2=A0 But since that order is not required, this is a=
latent error that may manifest years later when the program is built on a =
different platform.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
div>As of safety and security, I think you ignored an important fact. If a =
program <i>behaves </i>normally, it is not naturally guaranteed to behave n=
ormally forever. To make it safe and secure, you should take actions <i>bef=
ore it runs</i>. Think twice: why people are scared by undefined behavior? =
As I've said, fixing the order is not safe and secure. It evens make th=
e effort less effective: it may hide bugs which cannot easily be checked by=
machines (i.e. most people may be lazy and ignore them until there is stra=
nge behavior), cause more unsafe and insecure code in nature.</div></div></=
blockquote><div><br></div><div>This is backwards and wrong.=C2=A0 When the =
language has unspecified and undefined behavior, this means that translated=
programs can work in a variety of ways, some of which may be contrary to t=
he intentions of the programmer who did not realize that such behavior was =
allowed.=C2=A0 When a programmer is dealing only with specified and defined=
behavior, then the program will indeed work normally forever; a change in =
platform cannot change the behavior of the program.</div><div><br></div><di=
v>Undefined behavior is bad.=C2=A0 Unspecified behavior is bad.</div></div>=
</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/CAHSYqdaavPVwvbJH4o%2BpfLUcmRtuaAGC5S=
_G%3D%3DsoqjRGQtu2Jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaavP=
VwvbJH4o%2BpfLUcmRtuaAGC5S_G%3D%3DsoqjRGQtu2Jw%40mail.gmail.com</a>.<br />
--94eb2c048e44561f830537ad7c08--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 15 Jul 2016 07:37:15 -0700
Raw View
On sexta-feira, 15 de julho de 2016 09:53:21 PDT Hyman Rosen wrote:
> On Thu, Jul 14, 2016 at 8:29 PM, Patrice Roy <patricer@gmail.com> wrote:
> > For some, a 2% performance penalty is minor, but for a sizeable portion of
> > C++ programmers, including those I work with (the SG14 crowd, essentially)
> > it is not.
>
> For the record, this is a small performance penalty on one benchmark of a
> suite. It is being quoted as if it represents that much of a penalty to
> all C++ programs.
The point is that one benchmark is enough to prove that the performance impact
or gain can happen. It's not a theoretical exercise, it's real: swapping the
order of evaluation of a given program HAS BEEN PROVEN to either improve or
worsen a particular task.
--
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/1561371.ulApAJsJGD%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 15 Jul 2016 07:39:32 -0700
Raw View
On sexta-feira, 15 de julho de 2016 09:31:38 PDT Hyman Rosen wrote:
> Following your suggestion, a + b * c evaluates in the order b, c, a while a
> * x + b * c evaluates in the order a, x, b, c?
> Do you see why this is not a good idea?
Ok, I see why it isn't depth first. But this also means you see why
((a = b) = c) = d;
doesn't change order either.
--
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/86462798.zcKDWB8zAD%40tjmaciei-mobl1.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 10:53:19 -0400
Raw View
--001a114ab99cb0193d0537adc8f1
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 14, 2016 at 10:22 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> There are difficulties to make "left-to-right" clear in C++. You can see
> P0145R2 has *many *words to be inserted to the draft.
>
Nonsense. The canonical insert is like the one for the shift operator - a
single sentence, "The expression E1 is sequenced before the expression E2."
Since this should be true for all binary operators, it could potentially
be lifted into the beginning of chapter 5.
Some of the excess verbiage is because the decisions made in P0145R2 are
wrong. It should not need to say that the order of evaluation of operands
to a binary operator implemented as an overloaded function matches the
order for the native operator, because the correct order is left-to-right
for both. The error of making assignment right-to-left and leaving
argument evaluation order unspecified leads to the necessity for this
wording.
On the contrary, I think *everyone* *should *think about it, whether
> deciding to actually embedded it in the code or not. Side effects, in
> traditional view of theoretical computer science, are monsters. Careless
> use of side effects (including ignorant of which order is really needed)
> are essential bugs (which are difficult to be checked by machines), even it
> does not produce a program with unexpected behavior occasionally. To make
> (esp. uneducated noob) programmers too easy to forget their danger is not a
> good thing sounds to me. As an end-user, I don't want to rely on programs
> with such potential risks as possible. So I believe that it is wrong to
> make it as the default cases, at least of a serious general-purposed
> language (rather than some configurable DSL).
>
> So that is pure value judgment conflict. I think we are already clear
> about it.
>
Again, the problem is that programmers accidentally rely on order of side
effects without realizing they have done so, and do not realize their error
because their platform matches their expectations. It is useless to exhort
people to think about it. It is a fact of human attention that no one is
hyper vigilant all the time. (Just think about the sheer number of
incidents where young children die in hot cars because a parent simply
forgets that the child is there.) A language design that requires such
hyper vigilance in order to avoid errors is a poor and broken design.
Then, once the language has a defined order, depending on that order is not
an error, any more than depending on the order of a(); b(); is an error.
Thinking otherwise is a remnant of decades of programming in poorly
specified languages.
--
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/CAHSYqdbGOHkFrETO_ysSDu-68pnJppU2TYmmSmhM%2B%2B2AwKJS4g%40mail.gmail.com.
--001a114ab99cb0193d0537adc8f1
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, Jul 14, 2016 at 10:22 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>There are difficulti=
es to make "left-to-right" clear in C++. You can see P0145R2 has =
<i>many </i>words to be inserted to the draft.</div></div></blockquote><div=
><br></div><div>Nonsense.=C2=A0 The canonical insert is like the one for th=
e shift operator - a single sentence, "The expression E1 is sequenced =
before the expression E2." =C2=A0Since this should be true for all bin=
ary operators, it could potentially be lifted into the beginning of chapter=
5.</div><div><br></div><div>Some of the excess verbiage is because the dec=
isions made in P0145R2 are wrong.=C2=A0 It should not need to say that the =
order of evaluation of operands to a binary operator implemented as an over=
loaded function matches the order for the native operator, because the corr=
ect order is left-to-right for both.=C2=A0 The error of making assignment r=
ight-to-left and leaving argument evaluation order unspecified leads to the=
necessity for this wording.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>On the contrary, I think <i>everyone</i> <i>should </i>think =
about it, whether deciding to actually embedded it in the code or not. Side=
effects, in traditional view of theoretical computer science, are monsters=
.. Careless use of side effects (including ignorant of which order is really=
needed) are essential bugs (which are difficult to be checked by machines)=
, even it does not produce a program with unexpected behavior occasionally.=
To make (esp. uneducated noob) programmers too easy to forget their danger=
is not a good thing sounds to me. As an end-user, I don't want to rely=
on programs with such potential risks as possible. So I believe that it is=
wrong to make it as the default cases, at least of a serious general-purpo=
sed language (rather than some configurable DSL).<br><br>So that is pure va=
lue judgment conflict. I think we are already clear about it.</div></div></=
blockquote><div><br></div><div>Again, the problem is that programmers accid=
entally rely on order of side effects without realizing they have done so, =
and do not realize their error because their platform matches their expecta=
tions.=C2=A0 It is useless to exhort people to think about it.=C2=A0 It is =
a fact of human attention that no one is hyper vigilant all the time. =C2=
=A0(Just think about the sheer number of incidents where young children die=
in hot cars because a parent simply forgets that the child is there.) =C2=
=A0A language design that requires such hyper vigilance in order to avoid e=
rrors is a poor and broken design.<br><br>Then, once the language has a def=
ined order, depending on that order is not an error, any more than dependin=
g on the order of <font face=3D"monospace, monospace">a(); b();</font> is a=
n error.=C2=A0 Thinking otherwise is a remnant of decades of programming in=
poorly specified languages.</div></div></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/CAHSYqdbGOHkFrETO_ysSDu-68pnJppU2TYmm=
SmhM%2B%2B2AwKJS4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbGOHkF=
rETO_ysSDu-68pnJppU2TYmmSmhM%2B%2B2AwKJS4g%40mail.gmail.com</a>.<br />
--001a114ab99cb0193d0537adc8f1--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 11:12:02 -0400
Raw View
--001a1141ca489c0f9a0537ae0b71
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 15, 2016 at 2:31 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8A=E5=8D=8812:01:28=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> C++ is a programming language, used to direct the actions of a computer.
>> It is meaningless to say that a programming language contains constructs
>> that can be "used at one's own risk". That is Stockholm Syndrome and
>> misplaced nerd hubris. If such constructs exist in the language, it mea=
ns
>> that the language has been poorly specified, so that it is easy for
>> programmers to use the constructs incorrectly. The solution is not to w=
arn
>> the programmers but to fix the language.
>>
>> Be practical. You use the language by writing and reading code, if you
> does not also write specification to extend the language. There are risks
> of buggy implementations. There are risks of misunderstanding the languag=
e
> rules. There are risks of typos. Some of them are your responsibilities.
> Some of them are others' responsibilities. Everything may be risky, more =
or
> less. Do they all meaningless? How can a user avoid them totally? Or do y=
ou
> mean every language is poorly specified?
>
A programming language is a user interface. It is the responsibility of
the language designer to make the affordances of the language as clear and
distinct as possible, so that when people are using the language it is easy
for them to communicate their intentions, and such that it is difficult for
people to accidentally say one thing when they meant another. For example,
this is why Fortran's implicitly typed (by their first letter) variables
are wrong; by not requiring declarations, a programmer can make a
typographical error and silently access a different variable. This is why,
in Ada, comparisons are not associative; it is rare that someone who writes=
a
<=3D b <=3D c in C++ wants the result that is actually computed.
As Rabbi Tarfon said in Pirkei Avot 2:16
<http://www.chabad.org/library/article_cdo/aid/682513/jewish/English-Text.h=
tm>,
"You are not required to complete the work, but neither are you free to
desist from it." Or as we also say, "The perfect is the enemy of the
good." Just because language design cannot fix everything is not an excuse
to avoid fixing what it can.
Your belief is conflicts to the fact again. There are more than one people
> needing expressiveness or opportunity of optimization only can be
> effectively allowed by unsequenced evaluation just in this topic. I belie=
ve
> there are committee members who think the same.
>
There are people who want to leave order unspecified on the grounds that
the compiler can take advantage of that for optimization. I have not seen
anyone but you saying that programmers want to visibly express a request
for unspecified order in their C++ code.
--=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/CAHSYqdas_k6K2Za8fDQZy9fXsfj0MPPZGeixcN%2Bg7qHei=
mstUQ%40mail.gmail.com.
--001a1141ca489c0f9a0537ae0b71
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, Jul 15, 2016 at 2:31 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=
=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:0=
1:28=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<span class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>C++ is a pr=
ogramming language, used to direct the actions of a computer.=C2=A0 It is m=
eaningless to say that a programming language contains constructs that can =
be "used at one's own risk".=C2=A0 That is Stockholm Syndrome=
and misplaced nerd hubris.=C2=A0 If such constructs exist in the language,=
it means that the language has been poorly specified, so that it is easy f=
or programmers to use the constructs incorrectly.=C2=A0 The solution is not=
to warn the programmers but to fix the language.<br><br></div></div></div>=
</div></blockquote></span><div>Be practical. You use the language by writin=
g and reading code, if you does not also write specification to extend the =
language. There are risks of buggy implementations. There are risks of misu=
nderstanding the language rules. There are risks of typos. Some of them are=
your responsibilities. Some of them are others' responsibilities. Ever=
ything may be risky, more or less. Do they all meaningless? How can a user =
avoid them totally? Or do you mean every language is poorly specified?<br><=
/div></div></blockquote><div><br></div><div>A programming language is a use=
r interface.=C2=A0 It is the responsibility of the language designer to mak=
e the affordances of the language as clear and distinct as possible, so tha=
t when people are using the language it is easy for them to communicate the=
ir intentions, and such that it is difficult for people to accidentally say=
one thing when they meant another.=C2=A0 For example, this is why Fortran&=
#39;s implicitly typed (by their first letter) variables are wrong; by not =
requiring declarations, a programmer can make a typographical error and sil=
ently access a different variable.=C2=A0 This is why, in Ada, comparisons a=
re not associative; it is rare that someone who writes <font face=3D"monosp=
ace, monospace">a <=3D b <=3D c</font> in C++ wants the result that i=
s actually computed.</div><div><br></div><div>As Rabbi Tarfon said in <a hr=
ef=3D"http://www.chabad.org/library/article_cdo/aid/682513/jewish/English-T=
ext.htm">Pirkei Avot 2:16</a>, "You are not required to complete the w=
ork, but neither are you free to desist from it." =C2=A0Or as we also =
say, "The perfect is the enemy of the good." =C2=A0Just because l=
anguage design cannot fix everything is not an excuse to avoid fixing what =
it can.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Your belief is =
conflicts to the fact again. There are more than one people needing express=
iveness or opportunity of optimization only can be effectively allowed by u=
nsequenced evaluation just in this topic. I believe there are committee mem=
bers who think the same.</div></div></blockquote><div><br></div><div>There =
are people who want to leave order unspecified on the grounds that the comp=
iler can take advantage of that for optimization.=C2=A0 I have not seen any=
one but you saying that programmers want to visibly express a request for u=
nspecified order in their C++ code.=C2=A0</div></div></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/CAHSYqdas_k6K2Za8fDQZy9fXsfj0MPPZGeix=
cN%2Bg7qHeimstUQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdas_k6K2Z=
a8fDQZy9fXsfj0MPPZGeixcN%2Bg7qHeimstUQ%40mail.gmail.com</a>.<br />
--001a1141ca489c0f9a0537ae0b71--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 11:20:20 -0400
Raw View
--001a114fda9c4f9fed0537ae291b
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 2:42 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> You can write ';' to express specific evaluation order between expressions
> (though currently it can't be used in single full expression). When you
> write ',', there there is no such guarantee currently, unless the ',' is a
> builtin operator. You want to change the rule to make ',' behaves like ';'
> about semantics about order. Extension like __unsequenced(x, y) can be
> provided to override your rules of ',', but you seem to dislike them just
> because you think doing that is wrong.
>
Yes, I want comma in the context of function call sequence the evaluation
of arguments from left to right. I do not dislike an __unsequenced(x, y)
construct; in fact, I wholeheartedly approve of it, because it places the
locus of expressiveness in exactly the right place - the rare case where a
programmer consciously wants to tell the compiler that order doesn't matter.
Why do you think that is the burden of their habits? They seem to have
> reasons to warn people about the order rules and treat such rules are
> merely compromise.
>
We don't warn people about a(); b(); Why should we warn people about f(a(),
b())? It's because the people doing the warning have internalized that the
latter is a problem because they have for so long used languages where in
fact it was a problem. But you can still warn people that having multiple
side effects can confuse understanding of what code is doing, simply
because it increases the cognitive load - what the programmer has to keep
in mind while reading the code.
--
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/CAHSYqdbWT9Xi%3DEb0Y%3DmN8Wo5r%2BU5cQtwV3bNGbcn82utQkBm9Q%40mail.gmail.com.
--001a114fda9c4f9fed0537ae291b
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, Jul 15, 2016 at 2:42 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>You can write ';&=
#39; to express specific evaluation order between expressions (though curre=
ntly it can't be used in single full expression). When you write ',=
', there there is no such guarantee currently, unless the ',' i=
s a builtin operator. You want to change the rule to make ',' behav=
es like ';' about semantics about order. Extension like __unsequenc=
ed(x, y) can be provided to override your rules of ',', but you see=
m to dislike them just because you think doing that is wrong.<br></div></di=
v></blockquote><div><br>Yes, I want comma in the context of function call s=
equence the evaluation of arguments from left to right.=C2=A0 I do not disl=
ike an=C2=A0<font face=3D"monospace, monospace">__unsequenced(x, y)</font> =
construct; in fact, I wholeheartedly approve of it, because it places the l=
ocus of expressiveness in exactly the right place - the rare case where a p=
rogrammer consciously wants to tell the compiler that order doesn't mat=
ter.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Why do you think t=
hat is the burden of their habits? They seem to have reasons to warn people=
about the order rules and treat such rules are merely compromise.<br></div=
></div></blockquote><div><br></div><div>We don't warn people about <fon=
t face=3D"monospace, monospace">a(); b();</font> =C2=A0Why should we warn p=
eople about <font face=3D"monospace, monospace">f(a(), b())</font>?=C2=A0 I=
t's because the people doing the warning have internalized that the lat=
ter is a problem because they have for so long used languages where in fact=
it was a problem.=C2=A0 But you can still warn people that having multiple=
side effects can confuse understanding of what code is doing, simply becau=
se it increases the cognitive load - what the programmer has to keep in min=
d while reading the code.</div></div></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/CAHSYqdbWT9Xi%3DEb0Y%3DmN8Wo5r%2BU5cQ=
twV3bNGbcn82utQkBm9Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbWT9=
Xi%3DEb0Y%3DmN8Wo5r%2BU5cQtwV3bNGbcn82utQkBm9Q%40mail.gmail.com</a>.<br />
--001a114fda9c4f9fed0537ae291b--
.
Author: inkwizytoryankes@gmail.com
Date: Fri, 15 Jul 2016 08:28:25 -0700 (PDT)
Raw View
------=_Part_282_1285517598.1468596505785
Content-Type: multipart/alternative;
boundary="----=_Part_283_318349113.1468596505793"
------=_Part_283_318349113.1468596505793
Content-Type: text/plain; charset=UTF-8
On Wednesday, July 13, 2016 at 7:58:49 PM UTC+2, Hyman Rosen wrote:
>
> On Wed, Jul 13, 2016 at 11:36 AM, Ren Industries <renind...@gmail.com
> <javascript:>> wrote:
>
>> Why would the simplicity of teaching anything matter more than anything
>> else? IEEE 754 is incredibly hard to teach, with many odd nuances to it,
>> yet it is used because those nuances lead to better results. Modeling after
>> the mathematical concepts underlying the operations may lead to more
>> difficult to teach, but also has clear benefits, as DV explained.
>>
>
> The nuances of C++ order of evaluation lead to worse results and dubious
> benefits.
>
> And of course, C++'s implementation of IEEE 754 is broken too, so maybe
> your analogy is more apt than you realize,
> (Broken how? For example, C++ does not require that the following program
> succeed:
> #include <assert.h>
> int main() { volatile float i = 1.f; assert(i / 3.f == 1.f / 3.f); }
> On my x86 Linux box, it fails when built with -mno-sse but works when SSE
> instructions are used.)
>
You should never use `==` for floating points. Each operation can have
rounding errors that will break strick equality (`1.0 / 3.0 * 3.0 != 1.0`).
Btw how you want made this code portable if two machines have different
floating point units? You example show this exactly because `-mno-sse` is
completely different machine than with sse.
Who will pay penalty for not matching expected float accuracy?
--
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/097c22c3-0643-4477-a684-1c75065bd945%40isocpp.org.
------=_Part_283_318349113.1468596505793
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 13, 2016 at 7:58:49 PM UTC+2, H=
yman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Wed, Jul 13, 2016 at 11:36 AM, Ren I=
ndustries <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"9z_41rgFCwAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">renind...@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr">Why would the simplicity of teaching anythin=
g matter more than anything else? IEEE 754 is incredibly hard to teach, wit=
h many odd nuances to it, yet it is used because those nuances lead to bett=
er results. Modeling after the mathematical concepts underlying the operati=
ons may lead to more difficult to teach, but also has clear benefits, as DV=
explained.</div></blockquote><div><br>The nuances of C++ order of evaluati=
on lead to worse results and dubious benefits.<br><br>And of course, C++=
9;s implementation of IEEE 754 is broken too, so maybe your analogy is more=
apt than you realize,<br>(Broken how?=C2=A0 For example, C++ does not requ=
ire that the following program succeed:<br><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0=C2=A0#include <assert.h></font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 =C2=A0=C2=A0int main() { volatile float i=
=3D 1.f; assert(i / 3.f =3D=3D 1.f / 3.f); }</font><br><font face=3D"arial=
, helvetica, sans-serif">On my x86 Linux box, it fails when built with -mno=
-sse but works when SSE instructions are used.)</font></div></div></div></d=
iv></blockquote><div>You should never use `=3D=3D` for floating points. Eac=
h operation can have rounding errors that will break strick equality (`1.0 =
/ 3.0 * 3.0 !=3D 1.0`).<br>Btw how you want made this code portable if two =
machines have different floating point units? You example show this exactly=
because `<font face=3D"arial, helvetica, sans-serif">-mno-sse</font>` is c=
ompletely different machine than with sse.<br>Who will pay penalty for not =
matching expected float accuracy?<br></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/097c22c3-0643-4477-a684-1c75065bd945%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/097c22c3-0643-4477-a684-1c75065bd945=
%40isocpp.org</a>.<br />
------=_Part_283_318349113.1468596505793--
------=_Part_282_1285517598.1468596505785--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 11:35:39 -0400
Raw View
--001a114fda9c0da3780537ae6072
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 2:54 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> No. First, a programming language is not guaranteed to direct the
> operations of a computer.
>
WIth probability 1, no programmer writes computer programs that are not
intended to direct the operations of a computer. The fact that various
operations are needed in order to get some program to direct the operations
of some computer is only relevant when those operations warp the program so
that the computer does not operate in the way the programmer intended.
Second, the reason of defined constructs to force people does not write
> so-called "ambiguous" directions is absurd. It's up to the users, and you
> are not able to speak for all of them.
>
Because, with probability 1, programmers write programs intended to direct
the operations of a computer, it is seldom likely that the programmer wants
to express lack of concern about the order in which things happen. The
programmer may be writing a concurrent program in which events are expected
to happen simultaneously, or the programmer may in fact not care about the
order of two things. But with probability 1, no programmer wants to
express in the C++ code that two operations should be done in arbitrary
order. What does happen with probability greater than 0 is that a
programmer writes code in which things must happen in some order, but
expresses it in a way that the language does not require happen in that
order, while the underlying platform happens to produce the desired order.
This introduces a latent error into the code, which can manifest years
later when the program is built on a platform that produces a different
order.
> Third, even if you have disciplined every user to obey your rules
> successfully, users can invent something they want. When they call it a
> "language", you claims disable again.
>
When the language design is good, users do not need to be "disciplined"
into "obeying" rules.
--
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/CAHSYqdZjcyW9PV3EqJ7BiavJhB6cJjB61sC5Hxbk5h%2BkTPWJsQ%40mail.gmail.com.
--001a114fda9c0da3780537ae6072
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, Jul 15, 2016 at 2:54 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>No. First, a programm=
ing language is not guaranteed to direct the operations of a computer.</div=
></div></blockquote><div><br></div><div>WIth probability 1, no programmer w=
rites computer programs that are not intended to direct the operations of a=
computer.=C2=A0 The fact that various operations are needed in order to ge=
t some program to direct the operations of some computer is only relevant w=
hen those operations warp the program so that the computer does not operate=
in the way the programmer intended.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>Second, the reason of defined constructs to force peo=
ple does not write so-called "ambiguous" directions is absurd. It=
's up to the users, and you are not able to speak for all of them.<br><=
/div></div></blockquote><div><br></div><div>Because, with probability 1, pr=
ogrammers write programs intended to direct the operations of a computer, i=
t is seldom likely that the programmer wants to express lack of concern abo=
ut the order in which things happen.=C2=A0 The programmer may be writing a =
concurrent program in which events are expected to happen simultaneously, o=
r the programmer may in fact not care about the order of two things.=C2=A0 =
But with probability 1, no programmer wants to express in the C++ code that=
two operations should be done in arbitrary order.=C2=A0 What does happen w=
ith probability greater than 0 is that a programmer writes code in which th=
ings must happen in some order, but expresses it in a way that the language=
does not require happen in that order, while the underlying platform happe=
ns to produce the desired order.=C2=A0 This introduces a latent error into =
the code, which can manifest years later when the program is built on a pla=
tform that produces a different order.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div>Third, even if you have <span>disciplined every us=
er to obey your rules successfully, users can invent something they want. W=
hen they call it a "language", you claims disable again.</span></=
div></div></blockquote><div><br></div><div>When the language design is good=
, users do not need to be "disciplined" into "obeying" =
rules.=C2=A0</div></div></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/CAHSYqdZjcyW9PV3EqJ7BiavJhB6cJjB61sC5=
Hxbk5h%2BkTPWJsQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZjcyW9PV=
3EqJ7BiavJhB6cJjB61sC5Hxbk5h%2BkTPWJsQ%40mail.gmail.com</a>.<br />
--001a114fda9c0da3780537ae6072--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 11:42:02 -0400
Raw View
--001a1144db3eea5bb80537ae769d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 15, 2016 at 2:58 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8A=E5=8D=8812:15:34=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Wed, Jul 13, 2016 at 11:28 PM, FrankHB1989 <frank...@gmail.com> wrote=
:
>>>
>>>
>>> - Leave it unseqenced, if intended.
>>>
>>> The proportion of C++ code that has intentional lack of sequence is 0,
>> to a great number of decimal places. Using this as a reason to not adop=
t
>> rules that would prevent latent errors from being expressed years after
>> they are written is wrong.
>>
> If this is true, it is mostly because the author has not considered about
> it yet.
>
No, this is true because it's unnecessary. The programmer is writing a
program to direct the actions of a computer. As long as the computer
behaves as the programmer wishes, it is not necessary for the programmer to
consider every possible other way of writing the program.
> To avoiding thinking is not worth encouraging, because it can easily caus=
e
> errors with significantly higher cost.
>
The error that this sort of thinking is causing is poor design of C++.
--=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/CAHSYqda03MgDmX8TJYHg8hiGT_Q7FcOKaAPw8mLoYo-_UqV=
ORQ%40mail.gmail.com.
--001a1144db3eea5bb80537ae769d
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, Jul 15, 2016 at 2:58 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 20=
16=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=
=E5=8D=8812:15:34=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<span class=
=3D""><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 cl=
ass=3D"gmail_quote">On Wed, Jul 13, 2016 at 11:28 PM, FrankHB1989 <span dir=
=3D"ltr"><<a rel=3D"nofollow">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Leave it unseqen=
ced, if intended.</li></ul></div></div></blockquote><div>The proportion of =
C++ code that has intentional lack of sequence is 0, to a great number of d=
ecimal places.=C2=A0 Using this as a reason to not adopt rules that would p=
revent latent errors from being expressed years after they are written is w=
rong.</div></div></div></div></blockquote></span><div>If this is true, it i=
s mostly because the author has not considered about it yet.</div></div></b=
lockquote><div><br></div><div>No, this is true because it's unnecessary=
..=C2=A0 The programmer is writing a program to direct the actions of a comp=
uter.=C2=A0 As long as the computer behaves as the programmer wishes, it is=
not necessary for the programmer to consider every possible other way of w=
riting the program.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div> To avoiding thinking is not worth encouraging, bec=
ause it can easily cause errors with significantly higher cost.</div></div>=
</blockquote><div><br></div><div>The error that this sort of thinking is ca=
using is poor design of C++.</div></div></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/CAHSYqda03MgDmX8TJYHg8hiGT_Q7FcOKaAPw=
8mLoYo-_UqVORQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda03MgDmX8T=
JYHg8hiGT_Q7FcOKaAPw8mLoYo-_UqVORQ%40mail.gmail.com</a>.<br />
--001a1144db3eea5bb80537ae769d--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 11:44:02 -0400
Raw View
--94eb2c06fb2e153bca0537ae7e4a
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 3:02 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> That's ashamed for attitude of some users, rather the language design.
>
Poor interface designers deflect blame by blaming users.
> It was 2009. Why you allow raw 'new' occurred here in such way?
>
Poor interface designers deflect blame by blaming users.
--
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/CAHSYqdbPuui4-K1ejx88UgVQMYaZiY6HXwEBWE2_vmdh72qY%2Bw%40mail.gmail.com.
--94eb2c06fb2e153bca0537ae7e4a
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, Jul 15, 2016 at 3:02 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>That's ashamed fo=
r attitude of some users, rather the language design.<br></div></div></bloc=
kquote><div><br></div><div>Poor interface designers deflect blame by blamin=
g users.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It wa=
s 2009. Why you allow raw 'new' occurred here in such way?</div></d=
iv></blockquote><div><br></div><div>Poor interface designers deflect blame =
by blaming users.</div></div></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/CAHSYqdbPuui4-K1ejx88UgVQMYaZiY6HXwEB=
WE2_vmdh72qY%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbPuui4-K=
1ejx88UgVQMYaZiY6HXwEBWE2_vmdh72qY%2Bw%40mail.gmail.com</a>.<br />
--94eb2c06fb2e153bca0537ae7e4a--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 11:52:40 -0400
Raw View
--94eb2c06fb2ef221140537ae9cdd
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 3:11 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> That's correct. C++ evaluation order should be strictly left-to-right,
>> and then programmers should simply be taught that this is the rule.
>> Additionally, they might have to be untaught the PEMDAS rule they learned
>> in school; in the expression a() + b() * c(), we do not order the calls
>> as b(), c(), a() even though the multiplication happens before the
>> addition.
>>
>
> That's because poor mathematical education does not teach them enough
> about why this can work.
>
No, PEMDAS is not poor mathematical education. It is correct mathematical
convention.
> As you, most of the victims have no notion of deduction systems.
>
What is a "deduction system"?
> Only when the expressions are free from side effects, they have no need to
> care of the order. Once side effects are allowed, the world changes
> totally. It is wrong to apply such poor knowledge here, it just does not
> work.
>
This is what new programmers need to be taught. It is not poor knowledge,
it is knowledge not applicable to this context. The PEMDAS rules do
express the correct precedence and associativity in C++ for the operators
they cover.
And I should argue that PEMDAS rules are nonsense if one uses no infix
> notation, and infix notation is often useless and harmful in many practical
> cases out of school, but that is another story.
>
It is the essence of weird nerdiness to attempt to change notational
conventions used by nearly everyone.
--
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/CAHSYqdbhPeBnsM_ojginjRzhTYnLQx6vWSZFQo7BeGATc7K-Fw%40mail.gmail.com.
--94eb2c06fb2ef221140537ae9cdd
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, Jul 15, 2016 at 3:11 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D""><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 cl=
ass=3D"gmail_quote"><div>That's correct.=C2=A0 C++ evaluation order sho=
uld be strictly left-to-right, and then programmers should simply be taught=
that this is the rule.=C2=A0 Additionally, they might have to be untaught =
the PEMDAS rule they learned in school; in the expression <font face=3D"mon=
ospace, monospace">a() + b() * c()</font>, we do not order the calls as <fo=
nt face=3D"monospace, monospace">b()</font>, <font face=3D"monospace, monos=
pace">c()</font>, <font face=3D"monospace, monospace">a()</font> even thoug=
h the multiplication happens before the addition.</div></div></div></div></=
blockquote></span><div><br>That's because poor mathematical education d=
oes not teach them enough about why this can work.</div></div></blockquote>=
<div><br></div><div>No, PEMDAS is not poor mathematical education.=C2=A0 It=
is correct mathematical convention.</div><div>=C2=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div> As you, most of the victims have =
no notion of deduction systems.</div></div></blockquote><div><br></div><div=
>What is a "deduction system"?</div><div>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div> Only when the expressions are=
free from side effects, they have no need to care of the order. Once side =
effects are allowed, the world changes totally. It is wrong to apply such p=
oor knowledge here, it just does not work.<br></div></div></blockquote><div=
><br></div><div>This is what new programmers need to be taught.=C2=A0 It is=
not poor knowledge, it is knowledge not applicable to this context.=C2=A0 =
The PEMDAS rules do express the correct precedence and associativity in C++=
for the operators they cover.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>And I should argue that PEMDAS rules are nonse=
nse if one uses no infix notation, and infix notation is often useless and =
harmful in many practical cases out of school, but that is another story.</=
div></div></blockquote><div><br></div><div>It is the essence of weird nerdi=
ness to attempt to change notational conventions used by nearly everyone.</=
div></div></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/CAHSYqdbhPeBnsM_ojginjRzhTYnLQx6vWSZF=
Qo7BeGATc7K-Fw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbhPeBnsM_o=
jginjRzhTYnLQx6vWSZFQo7BeGATc7K-Fw%40mail.gmail.com</a>.<br />
--94eb2c06fb2ef221140537ae9cdd--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 12:03:07 -0400
Raw View
--001a114fda9c4df8b50537aec29d
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 3:17 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> No. Knowing too much is not beneficial. Requiring to know too much is
> harmful as it is against to many goals. I doubt you are lack of knowledge
> about "separating interface from implementation" and "principle of least
> privilege".
>
You would be surprised :-) I believe that information wants to be free,
and that not infrequently, a separated interface hides aspects of an
implementation that would be better served if users could see them.
Information hiding inverts the hierarchy of wisdom and experience; it
assumes the designers of the past have the foresight to conceal exactly the
correct information from the programmers of the future.
--
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/CAHSYqdZ1%3DJCp6HM4LhPTGkkXMM8JvdERJMEjZO6-tzCZmPgRXg%40mail.gmail.com.
--001a114fda9c4df8b50537aec29d
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, Jul 15, 2016 at 3:17 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>No. Kno=
wing too much is not beneficial. Requiring to know too much is harmful as i=
t is against to many goals. I doubt you are lack of knowledge about "s=
eparating interface from implementation" and "principle of least =
privilege".</div></div></blockquote><div><br></div><div>You would be s=
urprised :-) =C2=A0I believe that information wants to be free, and that no=
t infrequently, a separated interface hides aspects of an implementation th=
at would be better served if users could see them.=C2=A0 Information hiding=
inverts the hierarchy of wisdom and experience; it assumes the designers o=
f the past have the foresight to conceal exactly the correct information fr=
om the programmers of the future.</div></div></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/CAHSYqdZ1%3DJCp6HM4LhPTGkkXMM8JvdERJM=
EjZO6-tzCZmPgRXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ1%3DJCp=
6HM4LhPTGkkXMM8JvdERJMEjZO6-tzCZmPgRXg%40mail.gmail.com</a>.<br />
--001a114fda9c4df8b50537aec29d--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 12:14:37 -0400
Raw View
--94eb2c123a1075efb00537aeebc7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 15, 2016 at 7:00 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8A=E5=8D=883:04:55=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> I don't live in that utopia, "Ren Industries" does. In my world, C++ is
>> used to direct actions of computers, not abstract machines.
>>
> Then you are alien. In this world, semantics of C++ is defined by abstrac=
t
> machine, which is explicit in the standard. Machines usually run code
> transformed from C++, but not C++ source. The compiler frontend needs to
> know nothing about machine when generating machine-independent code.
>
C++ Standard 1.9: "This International Standard places no requirement on the
structure of conforming implementations. In particular, they need not copy
or emulate the structure of the abstract machine. Rather, conforming
implementations are required to emulate (only) the observable behavior of
the abstract machine"
Programmers write C++ programs in order to direct operations of computers.
When the computer runs under the control of the program, the computer
emulates the operations of the abstract machine. The operations needed to
get the program to direct the actions of the computer are irrelevant. They
only become relevant when they misinterpret the intentions of the
programmer so that the computer does not operate in the way the programmer
intended.
To reduce all kinds of cost, try to ask turning back to Java.
>
I don't know why you believe turning back to Java would reduce all kinds of
cost (nor is this the pace to discuss that).
--=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/CAHSYqdbFvwa4kqXbWgxt4myexUiL8zXwaxYzhfE8fnn5VUR=
C_g%40mail.gmail.com.
--94eb2c123a1075efb00537aeebc7
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, Jul 15, 2016 at 7:00 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=
=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:04=
:55=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><span class=3D""><div>I don't =
live in that utopia, "Ren Industries" does.=C2=A0 In my world, C+=
+ is used to direct actions of computers, not abstract machines.<br></div><=
/span></div></div></div></blockquote><div>Then you are alien. In this world=
, semantics of C++ is defined by abstract machine, which is explicit in the=
standard. Machines usually run code transformed from C++, but not C++ sour=
ce. The compiler frontend needs to know nothing about machine when generati=
ng machine-independent code.<br></div></div></blockquote><div><br>C++ Stand=
ard 1.9: "This International Standard places no requirement on the str=
ucture of conforming implementations. In particular, they need not copy or =
emulate the structure of the abstract machine. Rather, conforming implement=
ations are required to emulate (only) the observable behavior of the abstra=
ct machine"</div><div><br></div><div>Programmers write C++ programs in=
order to direct operations of computers.=C2=A0 When the computer runs unde=
r the control of the program, the computer emulates the operations of the a=
bstract machine.=C2=A0 The operations needed to get the program to direct t=
he actions of the computer are irrelevant.=C2=A0 They only become relevant =
when they misinterpret the intentions of the programmer so that the compute=
r does not operate in the way the programmer intended.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div>To reduce all kinds of cost, try to =
ask turning back to Java.</div></div></blockquote><div><br></div><div>I don=
't know why you believe turning back to Java would reduce all kinds of =
cost (nor is this the pace to discuss that).=C2=A0</div></div></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/CAHSYqdbFvwa4kqXbWgxt4myexUiL8zXwaxYz=
hfE8fnn5VURC_g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbFvwa4kqXb=
Wgxt4myexUiL8zXwaxYzhfE8fnn5VURC_g%40mail.gmail.com</a>.<br />
--94eb2c123a1075efb00537aeebc7--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 12:30:16 -0400
Raw View
--001a114fda9c67c6640537af23b2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 15, 2016 at 7:08 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8A=E5=8D=883:43:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> If programming languages do not exist to direct the operations of a
>> computer, and their domain is computer science, then constant factors ar=
e
>> irrelevant. Computer science does not care if algorithms run twice as
>> fast, it only cares about running speed as asymptotic to a function of
>> problem size.
>>
> This is not I heard. Computer architecture study *is *concerned about the
> constant factor.
>
Computer architecture is not computer science. The concerns of computer
architecture are not the concerns of computer programming languages. The
famous attempt to associate the two, the Intel 432 "Ada on a chip", was a
disaster.
> You are asking exposing implementation details into interface constraints=
,
> *unconditionally*.
>
I am doing nothing of the sort. I am talking about fixing errors in the
design of the programming language C++. The notions of interface and
implementation are high-level concepts that can be programmed in C++, but
they are not C++ itself.
> To increase the number of possible legal programs is not the goal of a
> practical language. Why bother a language worrying about too few programs
> are legal?
>
In this case, because the illegal programs are not detected by the
programming environments that translate them. Therefore it is correct to
make them legal and give them defined behavior.
> Because adding new syntax so that people can choose not to use it and
>> continue to write potentially broken code is silly, when the change to t=
he
>> language would not affect the legality or behavior of currently legal
>> programs.
>>
> You still have no evidence beyond your personal value judgement. That
> seems to be ignorance and prejudice.
>
My thesis is simple - unspecified behavior leads to latent errors and is of
no practical benefit, and left-to-right evaluation is the best
specification to use. My goal is to make sure that silence is not taken
for approval. The C++ Committee has been wrong many times before, and they
are wrong again. If I cannot change the outcome, I can at least say "I
told you so."
--=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/CAHSYqdYqrp%2BoKDvAXMKGb7Ujka-LUg6KdQ7u5TiKGFuYx=
hEYaA%40mail.gmail.com.
--001a114fda9c67c6640537af23b2
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, Jul 15, 2016 at 7:08 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=
=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:43=
:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If programmi=
ng languages do not exist to direct the operations of a computer, and their=
domain is computer science, then constant factors are irrelevant.=C2=A0 Co=
mputer science does not care if algorithms run twice as fast, it only cares=
about running speed as asymptotic to a function of problem size.<br></div>=
</div></div></div></blockquote></span><div>This is not I heard. Computer ar=
chitecture study <i>is </i>concerned about the constant factor.<br></div></=
div></blockquote><div><br></div><div>Computer architecture is not computer =
science.=C2=A0 The concerns of computer architecture are not the concerns o=
f computer programming languages.=C2=A0 The famous attempt to associate the=
two, the Intel 432 "Ada on a chip", was a disaster.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>You are asking exposing =
implementation details into interface constraints, <i>unconditionally</i>.<=
br></div></div></blockquote><div><br></div><div>I am doing nothing of the s=
ort.=C2=A0 I am talking about fixing errors in the design of the programmin=
g language C++.=C2=A0 The notions of interface and implementation are high-=
level concepts that can be programmed in C++, but they are not C++ itself.<=
/div><div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>To incre=
ase the number of possible legal programs is not the goal of a practical la=
nguage. Why bother a language worrying about too few programs are legal?<br=
></div></div></blockquote><div><br></div><div>In this case, because the ill=
egal programs are not detected by the programming environments that transla=
te them.=C2=A0 Therefore it is correct to make them legal and give them def=
ined behavior.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><spa=
n class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te"><div>Because adding new syntax so that people can choose not to use it =
and continue to write potentially broken code is silly, when the change to =
the language would not affect the legality or behavior of currently legal p=
rograms.</div></div></div></div></blockquote></span><div>You still have no =
evidence beyond your personal value judgement. That seems to be ignorance a=
nd prejudice.</div></div></blockquote><div><br></div><div>My thesis is simp=
le - unspecified behavior leads to latent errors and is of no practical ben=
efit, and left-to-right evaluation is the best specification to use.=C2=A0 =
My goal is to make sure that silence is not taken for approval.=C2=A0 The C=
++ Committee has been wrong many times before, and they are wrong again.=C2=
=A0 If I cannot change the outcome, I can at least say "I told you so.=
"</div></div></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/CAHSYqdYqrp%2BoKDvAXMKGb7Ujka-LUg6KdQ=
7u5TiKGFuYxhEYaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqrp%2Bo=
KDvAXMKGb7Ujka-LUg6KdQ7u5TiKGFuYxhEYaA%40mail.gmail.com</a>.<br />
--001a114fda9c67c6640537af23b2--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 12:38:02 -0400
Raw View
--001a114ab99c36e1200537af3faa
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 7:24 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> To provide different behavior "class"es is useful to clarify the
> responsibility. Existence of any undefined behavior will make you lose the
> guarantees of any predictable properties from the semantic rules.
> Unspecified behavior exists as a way to specify what you should not rely on
> but still allowed to be presented. Well-defined behavior is the predictable
> thing you can safely rely on. These notions have nothing to do with
> compilers; they are contents of the contract among designers of the
> language, authors of the implementations and users of the
> language/implementations (programmers). Concrete machines here are again
> irrelevant because they are merely implementation details.
>
Concrete machines carry out the actions of the abstract machine. They are
the most relevant part of the programming process because they are the
reason the program was written. It is in the actions carried out by the
concrete machine that the programmer can discover whether the program has
errors - that is, whether the interpretation of its intent by the
environment matches the intent of the programmer.
Unspecified behavior is a problem when programmers can easily write
programs that have unspecified behavior without realizing it. When
unspecified behavior has no practical benefit and the behavior of the
constructs involved can be easily specified, it is an error in the
programming language design not to specify that behavior.
--
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/CAHSYqdbhW8xWW78JCtBd_T5hNDSaMTMyZqOP%2BG26ORuGbXiHvA%40mail.gmail.com.
--001a114ab99c36e1200537af3faa
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, Jul 15, 2016 at 7:24 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>To prov=
ide different behavior "class"es is useful to clarify the respons=
ibility. Existence of any undefined behavior will make you lose the guarant=
ees of any predictable properties from the semantic rules. Unspecified beha=
vior exists as a way to specify what you should not rely on but still allow=
ed to be presented. Well-defined behavior is the predictable thing you can =
safely rely on. These notions have nothing to do with compilers; they are c=
ontents of the contract among designers of the language, authors of the imp=
lementations and users of the language/implementations (programmers). Concr=
ete machines here are again irrelevant because they are merely implementati=
on details.</div></div></blockquote><div><br></div><div><br></div><div>Conc=
rete machines carry out the actions of the abstract machine.=C2=A0 They are=
the most relevant part of the programming process because they are the rea=
son the program was written.=C2=A0 It is in the actions carried out by the =
concrete machine that the programmer can discover whether the program has e=
rrors - that is, whether the interpretation of its intent by the environmen=
t matches the intent of the programmer.<br><br>Unspecified behavior is a pr=
oblem when programmers can easily write programs that have unspecified beha=
vior without realizing it.=C2=A0 When unspecified behavior has no practical=
benefit and the behavior of the constructs involved can be easily specifie=
d, it is an error in the programming language design not to specify that be=
havior.</div></div></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/CAHSYqdbhW8xWW78JCtBd_T5hNDSaMTMyZqOP=
%2BG26ORuGbXiHvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbhW8xWW7=
8JCtBd_T5hNDSaMTMyZqOP%2BG26ORuGbXiHvA%40mail.gmail.com</a>.<br />
--001a114ab99c36e1200537af3faa--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 12:45:33 -0400
Raw View
--001a114fda9c0b74c20537af5ae1
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 10:37 AM, Thiago Macieira <thiago@macieira.org>
wrote:
>
> The point is that one benchmark is enough to prove that the performance
> impact
> or gain can happen. It's not a theoretical exercise, it's real: swapping
> the
> order of evaluation of a given program HAS BEEN PROVEN to either improve or
> worsen a particular task.
And the point is that decades of experience with C++ have proven that
unspecified order of evaluation causes latent errors, and so unspecified
order of evaluation HAS BEEN PROVEN to worsen the cost of programming in
C++. In my opinion, the cost demonstrated by the benchmark is
insignificant for practical use of C++ while the cost of latent errors is
large, and therefore the C++ Committee has incorrectly weighed those costs
in deciding what to do.
And mixing l-to-r, r-to-l, and unspecified behavior requirements into one
expression is ridiculous. The one good thing coming from Oulu with respect
to evaluation order is that at least function argument evaluation must be
sequenced in *some* order.
--
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/CAHSYqdZcE%2BZm-C44fz8jnyUQcjZmtRbD%2BnqGXsVC_vEjAf5F1w%40mail.gmail.com.
--001a114fda9c0b74c20537af5ae1
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, Jul 15, 2016 at 10:37 AM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex">The point is that one benchmark is enough =
to prove that the performance impact<br>
or gain can happen. It's not a theoretical exercise, it's real: swa=
pping the<br>
order of evaluation of a given program HAS BEEN PROVEN to either improve or=
<br>
worsen a particular task.</blockquote><div><br></div><div>And the point is =
that decades of experience with C++ have proven that unspecified order of e=
valuation causes latent errors, and so unspecified order of evaluation HAS =
BEEN PROVEN to worsen the cost of programming in C++.=C2=A0 In my opinion, =
the cost demonstrated by the benchmark is insignificant for practical use o=
f C++ while the cost of latent errors is large, and therefore the C++ Commi=
ttee has incorrectly weighed those costs in deciding what to do.<br><br>And=
mixing l-to-r, r-to-l, and unspecified behavior requirements into one expr=
ession is ridiculous.=C2=A0 The one good thing coming from Oulu with respec=
t to evaluation order is that at least function argument evaluation must be=
sequenced in *some* order.</div></div></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/CAHSYqdZcE%2BZm-C44fz8jnyUQcjZmtRbD%2=
BnqGXsVC_vEjAf5F1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZcE%2B=
Zm-C44fz8jnyUQcjZmtRbD%2BnqGXsVC_vEjAf5F1w%40mail.gmail.com</a>.<br />
--001a114fda9c0b74c20537af5ae1--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 12:55:48 -0400
Raw View
--001a114c843ab8ac280537af7eff
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 10:39 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On sexta-feira, 15 de julho de 2016 09:31:38 PDT Hyman Rosen wrote:
> > Following your suggestion, a + b * c evaluates in the order b, c, a
> while a
> > * x + b * c evaluates in the order a, x, b, c?
> > Do you see why this is not a good idea?
>
> Ok, I see why it isn't depth first. But this also means you see why
>
> ((a = b) = c) = d;
>
> doesn't change order either.
Yes, that's my point. Precedence and associativity tell you how to fully
parenthesize expressions. They *do not* imply an order of evaluation!
Then evaluation *does* proceed depth-first! But when an operator node has
several operands, there still remains the question of the order in which
they should be evaluated. The C++ Committee has decided that the
associativity of assignment should inform the order in which the two
operands of an assignment are evaluated. I believe this decision is wrong
and confusing.
--
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/CAHSYqdY8cE10fjM1WVUUZBZ2ph_FXC%3D96eYA5GWgLSE17bD9DQ%40mail.gmail.com.
--001a114c843ab8ac280537af7eff
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, Jul 15, 2016 at 10:39 AM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On sext=
a-feira, 15 de julho de 2016 09:31:38 PDT Hyman Rosen wrote:<br>
> Following your suggestion, a + b * c evaluates in the order b, c, a wh=
ile a<br>
> * x + b * c evaluates in the order a, x, b, c?<br>
> Do you see why this is not a good idea?<br>
<br>
</span>Ok, I see why it isn't depth first. But this also means you see =
why<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ((a =3D b) =3D c) =3D d;<br>
<br>
doesn't change order either.</blockquote><div><br>Yes, that's my po=
int.=C2=A0 Precedence and associativity tell you how to fully parenthesize =
expressions.=C2=A0 They *do not* imply an order of evaluation!=C2=A0 Then e=
valuation *does* proceed depth-first! But when an operator node has several=
operands, there still remains the question of the order in which they shou=
ld be evaluated.=C2=A0 The C++ Committee has decided that the associativity=
of assignment should inform the order in which the two operands of an assi=
gnment are evaluated.=C2=A0 I believe this decision is wrong and confusing.=
</div></div></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/CAHSYqdY8cE10fjM1WVUUZBZ2ph_FXC%3D96e=
YA5GWgLSE17bD9DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY8cE10fj=
M1WVUUZBZ2ph_FXC%3D96eYA5GWgLSE17bD9DQ%40mail.gmail.com</a>.<br />
--001a114c843ab8ac280537af7eff--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 13:21:58 -0400
Raw View
--001a114ab99c50e2660537afdc0f
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 11:28 AM, <inkwizytoryankes@gmail.com> wrote:
>
> On Wednesday, July 13, 2016 at 7:58:49 PM UTC+2, Hyman Rosen wrote:
>>
>> (Broken how? For example, C++ does not require that the following
>> program succeed:
>> #include <assert.h>
>> int main() { volatile float i = 1.f; assert(i / 3.f == 1.f / 3.f); }
>> On my x86 Linux box, it fails when built with -mno-sse but works when SSE
>> instructions are used.)
>>
> You should never use `==` for floating points. Each operation can have
> rounding errors that will break strick equality (`1.0 / 3.0 * 3.0 != 1.0`).
>
This is false. Floating-point numbers have exact values and may be
compared for equality with the expected meaning. Floating-point operations
are well-defined and do not have "rounding errors" (except for some
higher-order functions like the trigonometric ones which are not required
to be correct to the last bit - likely another mistake in specification,
but this problem is hard). The results of floating-point operations are
rounded to the nearest representable result, however.
The reason this code sometimes triggers the assertion is that the C++
Standard gives implementations permission to do bad things:
"The values of the floating operands and the results of floating
expressions may be represented in greater precision and range than that
required by the type; the types are not changed thereby."
So in the code above, the expression i / 3. and the expression 1 / 3. may
be evaluated at different precision (likely i / 3. in an extended register
and 1 / 3. as a precomputed constant value) and therefore the equality test
fails. But that's not because floating-point arithmetic has round-off
errors, it's because the designers of C++ followed C in favoring speed over
correctness using knowledge of then extant floating-point hardware - with
this permission granted, the compiler does not have to convert the extended
register to a float value before doing the comparison. As it happens, with
SSE the compiler can just generate a "compare as float" instruction so the
problem goes away.
> Btw how you want made this code portable if two machines have different
> floating point units? You example show this exactly because `-mno-sse` is
> completely different machine than with sse.
> Who will pay penalty for not matching expected float accuracy?
>
I want this code to be portable by having the language specify what
floating-point operations do. It is unconscionable that evaluating the
same floating-point expression multiple times can give different results.
A programming language that decided that 2 + 2 should occasionally yield 5
would not get very far. But too many people have the notion that
floating-point arithmetic isn't accurate anyway, and has round-off errors,
so what the heck, no one cares anyway, let's be wrong but fast.
--
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/CAHSYqdZmPCNT8O1Z%2BGOV2JvWmc9bO%3Dh_6%3D6PfPJxYXgpe_uHYQ%40mail.gmail.com.
--001a114ab99c50e2660537afdc0f
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, Jul 15, 2016 at 11:28 AM, <span dir=3D"ltr"><<a href=3D"mailto:inkw=
izytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb=
(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Wednesday, July 13, 201=
6 at 7:58:49 PM UTC+2, Hyman Rosen wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>(Broken how?=C2=A0 For example, C++ do=
es not require that the following program succeed:<br><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0=C2=A0#include <assert.h></font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=A0int main() { volat=
ile float i =3D 1.f; assert(i / 3.f =3D=3D 1.f / 3.f); }</font><br><font fa=
ce=3D"arial, helvetica, sans-serif">On my x86 Linux box, it fails when buil=
t with -mno-sse but works when SSE instructions are used.)</font></div></di=
v></div></div></blockquote><div>You should never use `=3D=3D` for floating =
points. Each operation can have rounding errors that will break strick equa=
lity (`1.0 / 3.0 * 3.0 !=3D 1.0`).<br></div></div></blockquote><div><br></d=
iv><div>This is false.=C2=A0 Floating-point numbers have exact values and m=
ay be compared for equality with the expected meaning.=C2=A0 Floating-point=
operations are well-defined and do not have "rounding errors" (e=
xcept for some higher-order functions like the trigonometric ones which are=
not required to be correct to the last bit - likely another mistake in spe=
cification, but this problem is hard).=C2=A0 The results of floating-point =
operations are rounded to the nearest representable result, however.<br><br=
>The reason this code sometimes triggers the assertion is that the C++ Stan=
dard gives implementations permission to do bad things:<br>=C2=A0 =C2=A0 &q=
uot;The values of the floating operands and the results of floating express=
ions may be represented in greater precision and range than that required b=
y the type; the types are not changed thereby."<br><br>So in the code =
above, the expression i / 3. and the expression 1 / 3. may be evaluated at =
different precision (likely i / 3. in an extended register and 1 / 3. as a =
precomputed constant value) and therefore the equality test fails.=C2=A0 Bu=
t that's not because floating-point arithmetic has round-off errors, it=
's because the designers of C++ followed C in favoring speed over corre=
ctness using knowledge of then extant floating-point hardware - with this p=
ermission granted, the compiler does not have to convert the extended regis=
ter to a float value before doing the comparison.=C2=A0 As it happens, with=
SSE the compiler can just generate a "compare as float" instruct=
ion so the problem goes away.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div>Btw how you want made this code portable if two machines ha=
ve different floating point units? You example show this exactly because `<=
font face=3D"arial, helvetica, sans-serif">-mno-sse</font>` is completely d=
ifferent machine than with sse.<br>Who will pay penalty for not matching ex=
pected float accuracy?</div></div></blockquote><div><br></div><div>I want t=
his code to be portable by having the language specify what floating-point =
operations do.=C2=A0 It is unconscionable that evaluating the same floating=
-point expression multiple times can give different results.=C2=A0 A progra=
mming language that decided that 2 + 2 should occasionally yield 5 would no=
t get very far.=C2=A0 But too many people have the notion that floating-poi=
nt arithmetic isn't accurate anyway, and has round-off errors, so what =
the heck, no one cares anyway, let's be wrong but fast.</div></div></di=
v></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/CAHSYqdZmPCNT8O1Z%2BGOV2JvWmc9bO%3Dh_=
6%3D6PfPJxYXgpe_uHYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZmPC=
NT8O1Z%2BGOV2JvWmc9bO%3Dh_6%3D6PfPJxYXgpe_uHYQ%40mail.gmail.com</a>.<br />
--001a114ab99c50e2660537afdc0f--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 15 Jul 2016 13:48:38 -0400
Raw View
On 2016-07-15 11:35, Hyman Rosen wrote:
> But with probability 1, no programmer wants to express in the C++
> code that two operations should be done in arbitrary order.
Really? No programmer, ever, in any language or in the history of
computing, has written code *knowing* that some subexpressions can be
safely executed in any order and *knowingly* expecting the compiler to
chose the order that is most efficient?
I'm not buying it.
That's like saying that no programmer wants to express that a
multiplication of an integer by a literal power of two can be performed
by a bit shift instead. Because there is really no sane reason why a
programmer should have to *go out of their way* to express knowledge
that an operation can be performed in a manner more efficient than the
"obvious" manner according to the way in which the code is written.
No one, however, is suggesting that compilers should not be permitted to
implement other optimizations because the programmer did not bend over
backwards to state that they wanted optimization. I don't quite get why
you insist on a different standard for execution ordering.
The reality is that (good) programmers know and understand the idea of
compiler optimizations and avoid going out of their way to write
"efficient" code, *because they trust the compiler* to Do The Right
Thing. Especially when it comes to things like function argument
ordering, where the platform calling convention can make a big
difference which ordering is most efficient.
Frankly, I find your rhetoric... draconian. I doubt you're convincing
anyone by speaking in such a manner. Try toning it down?
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nmb7lr%24hu5%241%40ger.gmane.org.
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 14:48:19 -0400
Raw View
--001a113f3d02fa71cf0537b10f02
Content-Type: text/plain; charset=UTF-8
This is ridiculous; Java has strict IEEE 754 semantics, and it *costs them
dearly in terms of performance.* C++ allows for closer to metal semantics,
as this leads to better performance. If you wish to remove the reason
people use C++ (performance), then why use C++ at all?
On Fri, Jul 15, 2016 at 1:21 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Fri, Jul 15, 2016 at 11:28 AM, <inkwizytoryankes@gmail.com> wrote:
>>
>> On Wednesday, July 13, 2016 at 7:58:49 PM UTC+2, Hyman Rosen wrote:
>>>
>>> (Broken how? For example, C++ does not require that the following
>>> program succeed:
>>> #include <assert.h>
>>> int main() { volatile float i = 1.f; assert(i / 3.f == 1.f / 3.f); }
>>> On my x86 Linux box, it fails when built with -mno-sse but works when
>>> SSE instructions are used.)
>>>
>> You should never use `==` for floating points. Each operation can have
>> rounding errors that will break strick equality (`1.0 / 3.0 * 3.0 != 1.0`).
>>
>
> This is false. Floating-point numbers have exact values and may be
> compared for equality with the expected meaning. Floating-point operations
> are well-defined and do not have "rounding errors" (except for some
> higher-order functions like the trigonometric ones which are not required
> to be correct to the last bit - likely another mistake in specification,
> but this problem is hard). The results of floating-point operations are
> rounded to the nearest representable result, however.
>
> The reason this code sometimes triggers the assertion is that the C++
> Standard gives implementations permission to do bad things:
> "The values of the floating operands and the results of floating
> expressions may be represented in greater precision and range than that
> required by the type; the types are not changed thereby."
>
> So in the code above, the expression i / 3. and the expression 1 / 3. may
> be evaluated at different precision (likely i / 3. in an extended register
> and 1 / 3. as a precomputed constant value) and therefore the equality test
> fails. But that's not because floating-point arithmetic has round-off
> errors, it's because the designers of C++ followed C in favoring speed over
> correctness using knowledge of then extant floating-point hardware - with
> this permission granted, the compiler does not have to convert the extended
> register to a float value before doing the comparison. As it happens, with
> SSE the compiler can just generate a "compare as float" instruction so the
> problem goes away.
>
>
>> Btw how you want made this code portable if two machines have different
>> floating point units? You example show this exactly because `-mno-sse`
>> is completely different machine than with sse.
>> Who will pay penalty for not matching expected float accuracy?
>>
>
> I want this code to be portable by having the language specify what
> floating-point operations do. It is unconscionable that evaluating the
> same floating-point expression multiple times can give different results.
> A programming language that decided that 2 + 2 should occasionally yield 5
> would not get very far. But too many people have the notion that
> floating-point arithmetic isn't accurate anyway, and has round-off errors,
> so what the heck, no one cares anyway, let's be wrong but fast.
>
> --
> 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/CAHSYqdZmPCNT8O1Z%2BGOV2JvWmc9bO%3Dh_6%3D6PfPJxYXgpe_uHYQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZmPCNT8O1Z%2BGOV2JvWmc9bO%3Dh_6%3D6PfPJxYXgpe_uHYQ%40mail.gmail.com?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/CAMD6iD-Q5BRYLF7GQf6YP-58au%3DFaQwsKgGFC4jAPfkNQFBQJQ%40mail.gmail.com.
--001a113f3d02fa71cf0537b10f02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is ridiculous; Java has strict IEEE 754 semantics, an=
d it <i>costs them dearly in terms of performance.</i>=C2=A0C++ allows for =
closer to metal semantics, as this leads to better performance. If you wish=
to remove the reason people use C++ (performance), then why use C++ at all=
?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Ju=
l 15, 2016 at 1:21 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:=
hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Jul 15, 20=
16 at 11:28 AM, <span dir=3D"ltr"><<a href=3D"mailto:inkwizytoryankes@g=
mail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>></span> wrote=
:</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wednesday, Ju=
ly 13, 2016 at 7:58:49 PM UTC+2, Hyman Rosen wrote:</span><span class=3D"">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>(Bro=
ken how?=C2=A0 For example, C++ does not require that the following program=
succeed:<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=A0#includ=
e <assert.h></font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0=C2=A0int main() { volatile float i =3D 1.f; assert(i / 3.f =3D=
=3D 1.f / 3.f); }</font><br><font face=3D"arial, helvetica, sans-serif">On =
my x86 Linux box, it fails when built with -mno-sse but works when SSE inst=
ructions are used.)</font></div></div></div></div></blockquote><div>You sho=
uld never use `=3D=3D` for floating points. Each operation can have roundin=
g errors that will break strick equality (`1.0 / 3.0 * 3.0 !=3D 1.0`).<br><=
/div></span></div></blockquote><div><br></div><div>This is false.=C2=A0 Flo=
ating-point numbers have exact values and may be compared for equality with=
the expected meaning.=C2=A0 Floating-point operations are well-defined and=
do not have "rounding errors" (except for some higher-order func=
tions like the trigonometric ones which are not required to be correct to t=
he last bit - likely another mistake in specification, but this problem is =
hard).=C2=A0 The results of floating-point operations are rounded to the ne=
arest representable result, however.<br><br>The reason this code sometimes =
triggers the assertion is that the C++ Standard gives implementations permi=
ssion to do bad things:<br>=C2=A0 =C2=A0 "The values of the floating o=
perands and the results of floating expressions may be represented in great=
er precision and range than that required by the type; the types are not ch=
anged thereby."<br><br>So in the code above, the expression i / 3. and=
the expression 1 / 3. may be evaluated at different precision (likely i / =
3. in an extended register and 1 / 3. as a precomputed constant value) and =
therefore the equality test fails.=C2=A0 But that's not because floatin=
g-point arithmetic has round-off errors, it's because the designers of =
C++ followed C in favoring speed over correctness using knowledge of then e=
xtant floating-point hardware - with this permission granted, the compiler =
does not have to convert the extended register to a float value before doin=
g the comparison.=C2=A0 As it happens, with SSE the compiler can just gener=
ate a "compare as float" instruction so the problem goes away.</d=
iv><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>Btw how you want made this code portable if two machines have different fl=
oating point units? You example show this exactly because `<font face=3D"ar=
ial, helvetica, sans-serif">-mno-sse</font>` is completely different machin=
e than with sse.<br>Who will pay penalty for not matching expected float ac=
curacy?</div></div></blockquote><div><br></div></span><div>I want this code=
to be portable by having the language specify what floating-point operatio=
ns do.=C2=A0 It is unconscionable that evaluating the same floating-point e=
xpression multiple times can give different results.=C2=A0 A programming la=
nguage that decided that 2 + 2 should occasionally yield 5 would not get ve=
ry far.=C2=A0 But too many people have the notion that floating-point arith=
metic isn't accurate anyway, and has round-off errors, so what the heck=
, no one cares anyway, let's be wrong but fast.</div></div></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" 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@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/CAHSYqdZmPCNT8O1Z%2BGOV2JvWmc9bO%3Dh_=
6%3D6PfPJxYXgpe_uHYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdZmPCNT8O1Z%2BGOV2JvWmc9bO%3Dh_6%3D6PfPJxYXgpe_uHYQ%40mail=
..gmail.com</a>.<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" 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/CAMD6iD-Q5BRYLF7GQf6YP-58au%3DFaQwsKg=
GFC4jAPfkNQFBQJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-Q5BRYLF=
7GQf6YP-58au%3DFaQwsKgGFC4jAPfkNQFBQJQ%40mail.gmail.com</a>.<br />
--001a113f3d02fa71cf0537b10f02--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 14:40:01 -0400
Raw View
--001a11c017d45f4e340537b0f219
Content-Type: text/plain; charset=UTF-8
Incorrect. I will state, with absolute confidence, against your assertions.
I regularly attempt to make my code order (side effects and all!) have as
many opportunities to be optimized, including deliberately unspecifying the
order. I do this through a notion I call "partial purity": as long as each
subexpression works on completely different variables, they are pure "to
each other". This can lead to a lot of speed ups while continuing to be
safe, as I do not care which order they are evaluated in, as they cannot
possibly conflict.
You say, with probability 1, that no one cares. I care, because it leads to
better and faster code. The compiler doesn't (yet) take advantage of this
optimization when no inlining can occur, but it certainly does when
inlining occurs (for example, during expression templates when the
abstractions of "function calls" go away and leads to nice neat assembly).
Stop asserting things with absolutely no evidence.
On Fri, Jul 15, 2016 at 9:40 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 7:48 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> Okay? But that is clearly an opportunity, not a problem. It is only a
>> problem when programmers poorly use their tools; it is an opportunity
>> always to the compiler. What you see it as doesn't matter; it is clearly,
>> mathematically, an opportunity.
>>
>
> Blaming users is how designers always try to deflect blame from their own
> errors.
> "A user interface is like a joke. If you have to explain it, it's not
> very good."
>
> In this case, one piece of language design has sent thousands of
> programmers down the garden path. That is bad design. The "opportunity"
> that compilers are taking advantage of is illusory - it leads them to
> create translated programs that do not do what the authors of the original
> programs want them to do. When the problem is discovered, the original
> programs need to be rewritten so that the "opportunity" goes away.
>
> --
> 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/CAHSYqdY1z1z%2B1XCecqY-kaJObm4n7er6m0FrtnF9YHgzXCFXSA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY1z1z%2B1XCecqY-kaJObm4n7er6m0FrtnF9YHgzXCFXSA%40mail.gmail.com?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/CAMD6iD-3A1asMCOso%2BVisK-tRWaKgDtiS%3DxbwZLEU2vZwY%3DKYQ%40mail.gmail.com.
--001a11c017d45f4e340537b0f219
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Incorrect. I will state, with absolute confidence, against=
your assertions. I regularly attempt to make my code order (side effects a=
nd all!) =C2=A0have as many opportunities to be optimized, including delibe=
rately unspecifying the order. I do this through a notion I call "part=
ial purity": as long as each subexpression works on completely differe=
nt variables, they are pure "to each other". This can lead to a l=
ot of speed ups while continuing to be safe, as I do not care which order t=
hey are evaluated in, as they cannot possibly conflict.<div><br></div><div>=
You say, with probability 1, that no one cares. I care, because it leads to=
better and faster code. The compiler doesn't (yet) take advantage of t=
his optimization when no inlining can occur, but it certainly does when inl=
ining occurs (for example, during expression templates when the abstraction=
s of "function calls" go away and leads to nice neat assembly).</=
div><div><br></div><div>Stop asserting things with absolutely no evidence.<=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri=
, Jul 15, 2016 at 9:40 AM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mai=
lto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 14=
, 2016 at 7:48 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto:r=
enindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Okay? But t=
hat is clearly an opportunity, not a problem. It is only a problem when pro=
grammers poorly use their tools; it is an opportunity always to the compile=
r. What you see it as doesn't matter; it is clearly, mathematically, an=
opportunity.</div></blockquote><div><br></div></span><div>Blaming users is=
how designers always try to deflect blame from their own errors.<br>"=
A user interface is like a joke.=C2=A0 If you have to explain it, it's =
not very good."<br><br>In this case, one piece of language design has =
sent thousands of programmers down the garden path.=C2=A0 That is bad desig=
n.=C2=A0 The "opportunity" that compilers are taking advantage of=
is illusory - it leads them to create translated programs that do not do w=
hat the authors of the original programs want them to do.=C2=A0 When the pr=
oblem is discovered, the original programs need to be rewritten so that the=
"opportunity" goes away.</div></div></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" 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@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/CAHSYqdY1z1z%2B1XCecqY-kaJObm4n7er6m0=
FrtnF9YHgzXCFXSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdY1z1z%2B1XCecqY-kaJObm4n7er6m0FrtnF9YHgzXCFXSA%40mail.gmail.c=
om</a>.<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" 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/CAMD6iD-3A1asMCOso%2BVisK-tRWaKgDtiS%=
3DxbwZLEU2vZwY%3DKYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-3A1=
asMCOso%2BVisK-tRWaKgDtiS%3DxbwZLEU2vZwY%3DKYQ%40mail.gmail.com</a>.<br />
--001a11c017d45f4e340537b0f219--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 14:40:44 -0400
Raw View
--001a11c02fbcebd09d0537b0f4b0
Content-Type: text/plain; charset=UTF-8
Unspecified behavior is an opportunity. So is undefined behavior. They are
not bad; they are necessary evils for performance.
On Fri, Jul 15, 2016 at 10:31 AM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 9:42 PM, FrankHB1989 <frankhb1989@gmail.com>
> wrote:
>>
>> First, you *have* got a way to fix evaluation long ago. Even without
>> statements, with some monadic tricks, f1(f2(f3(...))) *can *enforce the
>> order, just with a weird syntax in traditional ALGOL/C guys' view.
>>
>
> No. My goal is not to find a way to express fixed order of evaluation.
> My goal is to have all expressions have fixed order of evaluation, because
> we know from experience that having unspecified order leads to latent
> errors. I want that fixed order to be strict left-to-right because that is
> the easiest order to learn and remember, and matches the order in which
> code is written and read.
>
>
>> So actually you are disappointing with another problem. You want to
>> forbid others to use unsequenced evaluation (at least, by default) but they
>> don't agree with you. And why?
>>
>
> The only "other" who wants to express unsequenced evaluation in C++
> appears to be you. Can you, for example, point to a C++ textbook which
> explains to its readers how to deliberately express such a thing, as
> opposed to warning them on how to avoid it? It should not be the case that
> the language design privileges an obscure ability used by no programmers
> (with probability 1) when it leads to many programmers introducing latent
> errors into their code. That's why.
>
>
>> Second, as said, to choose the order solely by compiler is often very
>> difficult, if not impossible. The compiler is forced to prove the
>> equivalence between the program semantics before and after transformation
>> without explicit unsequenced evaluation guarantee. In practice, this has
>> almost the same effect to forbid such optimization.
>>
>
> No one (with probability 1) cares. I understand you feel that specifying
> unsequenced behavior is important. I am trying to tell you, over and over
> again, that it isn't important to anyone else (with probability 1). No
> programmer (with probability 1) sits down and thinks "how do I tell the
> compiler to evaluate these subexpressions in arbitrary order".
>
> If you still think this don't make sense, consider similar cases:
>>
>> - Why bother to specify the special cases cannot handled by the as-if
>> rules (e.g. copy elision and merging operator new calls)?
>>
>> Merging operator new calls is a bad idea too. Requiring copy elision
> helps when returning objects that use custom allocators.
>
>>
>> - Why not just use GC everywhere and believe compiler will insert
>> destructor/finalizer calls appropriately?
>>
>> GC is one aspect of resource handling; the RAII paradigm unifies all
> resource handling. What does "compiler will insert calls appropriately"
> mean, and why is that a bad thing? The compiler currently expends a great
> deal of effort to insert appropriate destructor calls for stack unwinding
> during exception handling, for example. Experience shows as well that GC
> does not relieve programmers from the problem of resource control over
> memory. See Java References: From Strong to Soft to Weak to Phantom
> <https://www.rallydev.com/blog/engineering/java-references-strong-soft-weak-phantom>, for
> example.
>
>>
>> - Why allow undefined behavior?
>>
>> Indeed. Undefined behavior is a curse on the language and should be
> eliminated wherever possible.
>
>
>> Most code relying on an explicit order without is already broken before
>> the rules are settled.
>>
>
> That's the point. That's why the language needs explicit order. It's
> because code is broken silently. It appears to work because the platform
> on which it is built matches the programmer's expectation, and will break
> when built on another platform
>
>
>> If you want to have multiple side effects, you *should *care the
>> evaluation order related to side effects.
>>
>
> Yes. And that means that there should be such an order.
>
>
>> Hymans is wrong because he assumes this order is always the same with
>> lexical order, which is not true in general - the language or the machine
>> just does not work in that way without fixed order rules enforced
>> artificially.
>>
>
> I do not "assume" that this is the order, I *want* this to be the order.
> And "artificially"? I wasn't aware that programming languages are in any
> way natural. Programming languages are intelligently (sometimes) designed
> artifacts. Whether or not they define evaluation order is a choice made by
> the designer. Neither choice is "natural". Some choices are merely
> longstanding.
>
> And since the rules were not there, you should not depend on those rules
>> in analysis the necessity of the fixed order, otherwise it is somehow
>> circular justification. Without such rules, the expressions are confusing.
>> So they are already broken.
>>
>
> Again: the necessity for fixed order is that programmers accidentally
> write code that depends on a fixed order without realizing that they have
> done so, and their code works because their platform's order of evaluation
> matches what they want. But since that order is not required, this is a
> latent error that may manifest years later when the program is built on a
> different platform.
>
> As of safety and security, I think you ignored an important fact. If a
>> program *behaves *normally, it is not naturally guaranteed to behave
>> normally forever. To make it safe and secure, you should take actions *before
>> it runs*. Think twice: why people are scared by undefined behavior? As
>> I've said, fixing the order is not safe and secure. It evens make the
>> effort less effective: it may hide bugs which cannot easily be checked by
>> machines (i.e. most people may be lazy and ignore them until there is
>> strange behavior), cause more unsafe and insecure code in nature.
>>
>
> This is backwards and wrong. When the language has unspecified and
> undefined behavior, this means that translated programs can work in a
> variety of ways, some of which may be contrary to the intentions of the
> programmer who did not realize that such behavior was allowed. When a
> programmer is dealing only with specified and defined behavior, then the
> program will indeed work normally forever; a change in platform cannot
> change the behavior of the program.
>
> Undefined behavior is bad. Unspecified behavior is bad.
>
> --
> 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/CAHSYqdaavPVwvbJH4o%2BpfLUcmRtuaAGC5S_G%3D%3DsoqjRGQtu2Jw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaavPVwvbJH4o%2BpfLUcmRtuaAGC5S_G%3D%3DsoqjRGQtu2Jw%40mail.gmail.com?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/CAMD6iD9POvTg%2B%2BNkFNCs2utmGbHdkxXf35LOHiLOqG%3DyWCehpA%40mail.gmail.com.
--001a11c02fbcebd09d0537b0f4b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Unspecified behavior is an opportunity. So is undefined be=
havior. They are not bad; they are necessary evils for performance.</div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 15, 201=
6 at 10:31 AM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hyman.ro=
sen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span class=3D"">On Thu, Jul 14, 2016 at 9:=
42 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"mailto:frankhb1989@gmai=
l.com" target=3D"_blank">frankhb1989@gmail.com</a>></span> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div>First, you <i>have</i> got a way to fix eva=
luation long ago. Even without statements, with some monadic tricks, f1(f2(=
f3(...))) <i>can </i>enforce the order, just with a weird syntax in traditi=
onal ALGOL/C guys' view.<br></div></div></blockquote><div><br></div></s=
pan><div>No.=C2=A0 My goal is not to find a way to express fixed order of e=
valuation.=C2=A0 My goal is to have all expressions have fixed order of eva=
luation, because we know from experience that having unspecified order lead=
s to latent errors.=C2=A0 I want that fixed order to be strict left-to-righ=
t because that is the easiest order to learn and remember, and matches the =
order in which code is written and read.</div><span class=3D""><div>=C2=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>So actually you are disappo=
inting with another problem. You want to forbid others to use unsequenced e=
valuation (at least, by default) but they don't agree with you. And why=
?<br></div></div></blockquote><div><br></div></span><div>The only "oth=
er" who wants to express unsequenced evaluation in C++ appears to be y=
ou.=C2=A0 Can you, for example, point to a C++ textbook which explains to i=
ts readers how to deliberately express such a thing, as opposed to warning =
them on how to avoid it?=C2=A0 It should not be the case that the language =
design privileges an obscure ability used by no programmers (with probabili=
ty 1) when it leads to many programmers introducing latent errors into thei=
r code.=C2=A0 That's why.</div><span class=3D""><div>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>Second, as said, to choose the order s=
olely by compiler is often very difficult, if not impossible. The compiler =
is forced to prove the equivalence between the program semantics before and=
after transformation without explicit unsequenced evaluation guarantee. In=
practice, this has almost the same effect to forbid such optimization.</di=
v></div></blockquote><div><br></div></span><div>No one (with probability 1)=
cares.=C2=A0 I understand you feel that specifying unsequenced behavior is=
important.=C2=A0 I am trying to tell you, over and over again, that it isn=
't important to anyone else (with probability 1).=C2=A0 No programmer (=
with probability 1) sits down and thinks "how do I tell the compiler t=
o evaluate these subexpressions in arbitrary order".</div><span class=
=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> If you still t=
hink this don't make sense, consider similar cases:<br><ul><li>Why both=
er to specify the special cases cannot handled by the as-if rules (e.g. cop=
y elision and merging operator new calls)?<br></li></ul></div></div></block=
quote></span><div>Merging operator new calls is a bad idea too.=C2=A0 Requi=
ring copy elision helps when returning objects that use custom allocators.<=
/div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Why no=
t just use GC everywhere and believe compiler will insert destructor/finali=
zer calls appropriately?</li></ul></div></div></blockquote></span><div>GC i=
s one aspect of resource handling; the RAII paradigm unifies all resource h=
andling.=C2=A0 What does "compiler will insert calls appropriately&quo=
t; mean, and why is that a bad thing?=C2=A0 The compiler currently expends =
a great deal of effort to insert appropriate destructor calls for stack unw=
inding during exception handling, for example.=C2=A0 Experience shows as we=
ll that GC does not relieve programmers from the problem of resource contro=
l over memory.=C2=A0 See=C2=A0<a href=3D"https://www.rallydev.com/blog/engi=
neering/java-references-strong-soft-weak-phantom" target=3D"_blank">Java Re=
ferences: From Strong to Soft to Weak to Phantom</a>,=C2=A0for example.<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Why allow undefined be=
havior?</li></ul></div></div></blockquote><div>Indeed.=C2=A0 Undefined beha=
vior is a curse on the language and should be eliminated wherever possible.=
<br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bor=
der-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Mos=
t code relying on an explicit order without is already broken before the ru=
les are settled.</div></div></blockquote><div><br></div></span><div>That=
9;s the point.=C2=A0 That's why the language needs explicit order.=C2=
=A0 It's because code is broken silently.=C2=A0 It appears to work beca=
use the platform on which it is built matches the programmer's expectat=
ion, and will break when built on another platform</div><span class=3D""><d=
iv>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> If you want to h=
ave multiple side effects, you <i>should </i>care the evaluation order rela=
ted to side effects.</div></div></blockquote><div><br></div></span><div>Yes=
..=C2=A0 And that means that there should be such an order.</div><span class=
=3D""><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> Hymans i=
s wrong because he assumes this order is always the same with lexical order=
, which is not true in general - the language or the machine just does not =
work in that way without fixed order rules enforced artificially.</div></di=
v></blockquote><div><br></div></span><div>I do not "assume" that =
this is the order, I *want* this to be the order.=C2=A0 And "artificia=
lly"?=C2=A0 I wasn't aware that programming languages are in any w=
ay natural.=C2=A0 Programming languages are intelligently (sometimes) desig=
ned artifacts.=C2=A0 Whether or not they define evaluation order is a choic=
e made by the designer.=C2=A0 Neither choice is "natural".=C2=A0 =
Some choices are merely longstanding.</div><span class=3D""><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div> And since the rules were not there,=
you should not depend on those rules in analysis the necessity of the fixe=
d order, otherwise it is somehow circular justification. Without such rules=
, the expressions are confusing. So they are already broken.<br></div></div=
></blockquote><div><br></div></span><div>Again: the necessity for fixed ord=
er is that programmers accidentally write code that depends on a fixed orde=
r without realizing that they have done so, and their code works because th=
eir platform's order of evaluation matches what they want.=C2=A0 But si=
nce that order is not required, this is a latent error that may manifest ye=
ars later when the program is built on a different platform.</div><span cla=
ss=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>As of safety =
and security, I think you ignored an important fact. If a program <i>behave=
s </i>normally, it is not naturally guaranteed to behave normally forever. =
To make it safe and secure, you should take actions <i>before it runs</i>. =
Think twice: why people are scared by undefined behavior? As I've said,=
fixing the order is not safe and secure. It evens make the effort less eff=
ective: it may hide bugs which cannot easily be checked by machines (i.e. m=
ost people may be lazy and ignore them until there is strange behavior), ca=
use more unsafe and insecure code in nature.</div></div></blockquote><div><=
br></div></span><div>This is backwards and wrong.=C2=A0 When the language h=
as unspecified and undefined behavior, this means that translated programs =
can work in a variety of ways, some of which may be contrary to the intenti=
ons of the programmer who did not realize that such behavior was allowed.=
=C2=A0 When a programmer is dealing only with specified and defined behavio=
r, then the program will indeed work normally forever; a change in platform=
cannot change the behavior of the program.</div><div><br></div><div>Undefi=
ned behavior is bad.=C2=A0 Unspecified behavior is bad.</div></div></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" 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@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/CAHSYqdaavPVwvbJH4o%2BpfLUcmRtuaAGC5S=
_G%3D%3DsoqjRGQtu2Jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdaavPVwvbJH4o%2BpfLUcmRtuaAGC5S_G%3D%3DsoqjRGQtu2Jw%40mail=
..gmail.com</a>.<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" 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/CAMD6iD9POvTg%2B%2BNkFNCs2utmGbHdkxXf=
35LOHiLOqG%3DyWCehpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9POv=
Tg%2B%2BNkFNCs2utmGbHdkxXf35LOHiLOqG%3DyWCehpA%40mail.gmail.com</a>.<br />
--001a11c02fbcebd09d0537b0f4b0--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 14:45:42 -0400
Raw View
--001a11490e3a9bf5c80537b106f3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It IS of practical benefits. It leads to expressiveness that allow the
compiler to increase the speed of execution. To disagree with this is
intellectually dishonest, as you have constantly been by asserting
something fundamentally against the very specification of C++: That it is
defined in terms of practical computers, not abstract machines.
Stop being intellectually dishonest, and face the fact that people do not
agree with you for obvious and not necessarily wrong reasons.
On Fri, Jul 15, 2016 at 12:30 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote=
:
> On Fri, Jul 15, 2016 at 7:08 AM, FrankHB1989 <frankhb1989@gmail.com>
> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=883:43:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> If programming languages do not exist to direct the operations of a
>>> computer, and their domain is computer science, then constant factors a=
re
>>> irrelevant. Computer science does not care if algorithms run twice as
>>> fast, it only cares about running speed as asymptotic to a function of
>>> problem size.
>>>
>> This is not I heard. Computer architecture study *is *concerned about
>> the constant factor.
>>
>
> Computer architecture is not computer science. The concerns of computer
> architecture are not the concerns of computer programming languages. The
> famous attempt to associate the two, the Intel 432 "Ada on a chip", was a
> disaster.
>
>
>> You are asking exposing implementation details into interface
>> constraints, *unconditionally*.
>>
>
> I am doing nothing of the sort. I am talking about fixing errors in the
> design of the programming language C++. The notions of interface and
> implementation are high-level concepts that can be programmed in C++, but
> they are not C++ itself.
>
>
>> To increase the number of possible legal programs is not the goal of a
>> practical language. Why bother a language worrying about too few program=
s
>> are legal?
>>
>
> In this case, because the illegal programs are not detected by the
> programming environments that translate them. Therefore it is correct to
> make them legal and give them defined behavior.
>
>
>> Because adding new syntax so that people can choose not to use it and
>>> continue to write potentially broken code is silly, when the change to =
the
>>> language would not affect the legality or behavior of currently legal
>>> programs.
>>>
>> You still have no evidence beyond your personal value judgement. That
>> seems to be ignorance and prejudice.
>>
>
> My thesis is simple - unspecified behavior leads to latent errors and is
> of no practical benefit, and left-to-right evaluation is the best
> specification to use. My goal is to make sure that silence is not taken
> for approval. The C++ Committee has been wrong many times before, and th=
ey
> are wrong again. If I cannot change the outcome, I can at least say "I
> told you so."
>
> --
> 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/CAHSYqdYqrp%=
2BoKDvAXMKGb7Ujka-LUg6KdQ7u5TiKGFuYxhEYaA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqrp=
%2BoKDvAXMKGb7Ujka-LUg6KdQ7u5TiKGFuYxhEYaA%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=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/CAMD6iD9L9ecxC8PuCudZwG6gS%2BLtGOy_tjU3V0rwDUbgJ=
WuX2w%40mail.gmail.com.
--001a11490e3a9bf5c80537b106f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It IS of practical benefits. It leads to expressiveness th=
at allow the compiler to increase the speed of execution. To disagree with =
this is intellectually dishonest, as you have constantly been by asserting =
something fundamentally against the very specification of C++: That it is d=
efined in terms of practical computers, not abstract machines.<div><br></di=
v><div>Stop being intellectually dishonest, and face the fact that people d=
o not agree with you for obvious and not necessarily wrong reasons.</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 1=
5, 2016 at 12:30 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:hy=
man.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Jul 15, 2016=
at 7:08 AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"mailto:frankhb198=
9@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>></span> wrote:<=
/span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"">=E5=9C=A8 2016=E5=
=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=
=883:43:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A</span><span><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If progra=
mming languages do not exist to direct the operations of a computer, and th=
eir domain is computer science, then constant factors are irrelevant.=C2=A0=
Computer science does not care if algorithms run twice as fast, it only ca=
res about running speed as asymptotic to a function of problem size.<br></d=
iv></div></div></div></blockquote></span><span class=3D""><div>This is not =
I heard. Computer architecture study <i>is </i>concerned about the constant=
factor.<br></div></span></div></blockquote><div><br></div><div>Computer ar=
chitecture is not computer science.=C2=A0 The concerns of computer architec=
ture are not the concerns of computer programming languages.=C2=A0 The famo=
us attempt to associate the two, the Intel 432 "Ada on a chip", w=
as a disaster.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div=
dir=3D"ltr"><div>You are asking exposing implementation details into inter=
face constraints, <i>unconditionally</i>.<br></div></div></blockquote><div>=
<br></div></span><div>I am doing nothing of the sort.=C2=A0 I am talking ab=
out fixing errors in the design of the programming language C++.=C2=A0 The =
notions of interface and implementation are high-level concepts that can be=
programmed in C++, but they are not C++ itself.</div><span class=3D""><div=
>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>To increase the n=
umber of possible legal programs is not the goal of a practical language. W=
hy bother a language worrying about too few programs are legal?<br></div></=
div></blockquote><div><br></div></span><div>In this case, because the illeg=
al programs are not detected by the programming environments that translate=
them.=C2=A0 Therefore it is correct to make them legal and give them defin=
ed behavior.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div>Because adding new syntax so that people can choose not to use=
it and continue to write potentially broken code is silly, when the change=
to the language would not affect the legality or behavior of currently leg=
al programs.</div></div></div></div></blockquote></span><div>You still have=
no evidence beyond your personal value judgement. That seems to be ignoran=
ce and prejudice.</div></div></blockquote><div><br></div></span><div>My the=
sis is simple - unspecified behavior leads to latent errors and is of no pr=
actical benefit, and left-to-right evaluation is the best specification to =
use.=C2=A0 My goal is to make sure that silence is not taken for approval.=
=C2=A0 The C++ Committee has been wrong many times before, and they are wro=
ng again.=C2=A0 If I cannot change the outcome, I can at least say "I =
told you so."</div></div></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" 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@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/CAHSYqdYqrp%2BoKDvAXMKGb7Ujka-LUg6KdQ=
7u5TiKGFuYxhEYaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdYqrp%2BoKDvAXMKGb7Ujka-LUg6KdQ7u5TiKGFuYxhEYaA%40mail.gmail.c=
om</a>.<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" 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/CAMD6iD9L9ecxC8PuCudZwG6gS%2BLtGOy_tj=
U3V0rwDUbgJWuX2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9L9ecxC8=
PuCudZwG6gS%2BLtGOy_tjU3V0rwDUbgJWuX2w%40mail.gmail.com</a>.<br />
--001a11490e3a9bf5c80537b106f3--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 14:46:59 -0400
Raw View
--001a114a72de3a50470537b10b7e
Content-Type: text/plain; charset=UTF-8
That does not constitute proof; it may be evidence towards your point, but
without, you know, data, there's no way to compare the possible speed ups
with the possible cost. Strict aliasing, for example, lead to a lot of
speed ups, and also broke a lot of interesting code. Was it worth it? We'd
need a lot more data than you've provided to know.
On Fri, Jul 15, 2016 at 12:45 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Fri, Jul 15, 2016 at 10:37 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>>
>> The point is that one benchmark is enough to prove that the performance
>> impact
>> or gain can happen. It's not a theoretical exercise, it's real: swapping
>> the
>> order of evaluation of a given program HAS BEEN PROVEN to either improve
>> or
>> worsen a particular task.
>
>
> And the point is that decades of experience with C++ have proven that
> unspecified order of evaluation causes latent errors, and so unspecified
> order of evaluation HAS BEEN PROVEN to worsen the cost of programming in
> C++. In my opinion, the cost demonstrated by the benchmark is
> insignificant for practical use of C++ while the cost of latent errors is
> large, and therefore the C++ Committee has incorrectly weighed those costs
> in deciding what to do.
>
> And mixing l-to-r, r-to-l, and unspecified behavior requirements into one
> expression is ridiculous. The one good thing coming from Oulu with respect
> to evaluation order is that at least function argument evaluation must be
> sequenced in *some* order.
>
> --
> 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/CAHSYqdZcE%2BZm-C44fz8jnyUQcjZmtRbD%2BnqGXsVC_vEjAf5F1w%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZcE%2BZm-C44fz8jnyUQcjZmtRbD%2BnqGXsVC_vEjAf5F1w%40mail.gmail.com?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/CAMD6iD8V%2B9P%3DB3Wa56N5KgweqazFeqYMJds_pMQ_Qg4qLfGyzw%40mail.gmail.com.
--001a114a72de3a50470537b10b7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That does not constitute proof; it may be evidence towards=
your point, but without, you know, data, there's no way to compare the=
possible speed ups with the possible cost. Strict aliasing, for example, l=
ead to a lot of speed ups, and also broke a lot of interesting code. Was it=
worth it? We'd need a lot more data than you've provided to know.<=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul =
15, 2016 at 12:45 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:h=
yman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Jul 15, 201=
6 at 10:37 AM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thia=
go@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex">The point is that one benchmark is enough to prove that t=
he performance impact<br>
or gain can happen. It's not a theoretical exercise, it's real: swa=
pping the<br>
order of evaluation of a given program HAS BEEN PROVEN to either improve or=
<br>
worsen a particular task.</blockquote><div><br></div></span><div>And the po=
int is that decades of experience with C++ have proven that unspecified ord=
er of evaluation causes latent errors, and so unspecified order of evaluati=
on HAS BEEN PROVEN to worsen the cost of programming in C++.=C2=A0 In my op=
inion, the cost demonstrated by the benchmark is insignificant for practica=
l use of C++ while the cost of latent errors is large, and therefore the C+=
+ Committee has incorrectly weighed those costs in deciding what to do.<br>=
<br>And mixing l-to-r, r-to-l, and unspecified behavior requirements into o=
ne expression is ridiculous.=C2=A0 The one good thing coming from Oulu with=
respect to evaluation order is that at least function argument evaluation =
must be sequenced in *some* order.</div></div></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" 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@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/CAHSYqdZcE%2BZm-C44fz8jnyUQcjZmtRbD%2=
BnqGXsVC_vEjAf5F1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdZcE%2BZm-C44fz8jnyUQcjZmtRbD%2BnqGXsVC_vEjAf5F1w%40mail.gma=
il.com</a>.<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" 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/CAMD6iD8V%2B9P%3DB3Wa56N5KgweqazFeqYM=
Jds_pMQ_Qg4qLfGyzw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8V%2B9=
P%3DB3Wa56N5KgweqazFeqYMJds_pMQ_Qg4qLfGyzw%40mail.gmail.com</a>.<br />
--001a114a72de3a50470537b10b7e--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 16:01:49 -0400
Raw View
--001a11c017d4caea630537b216a9
Content-Type: text/plain; charset=UTF-8
I'm not wrong; these are absolute facts, used by compilers currently. I've
run afoul of them, and I've benefited from them.
You cannot simply state something is wrong with no evidence; provide
evidence disproving the facts (which are widely evident in GCC, which can
use undefined behavior to optimize code), or qualify your statement.
On Fri, Jul 15, 2016 at 4:00 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Fri, Jul 15, 2016 at 2:40 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>
>> Unspecified behavior is an opportunity. So is undefined behavior. They
>> are not bad; they are necessary evils for performance
>>
>
> I understand that you believe that. But you are wrong. It is important
> to me that your wrong beliefs are not the only voice heard, so I make sure
> to speak up to contradict them. (I do that in other circumstances too. It
> annoys my wife no end.) This way, when a wrong decision is made on the
> basis of false beliefs, after the decision makers have realized their
> mistake they cannot say that everyone agreed with their decision and that
> they were not warned.
>
> --
> 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/CAHSYqdZu7dWz3UD7cJcujCFwj1LhFppTGp0kt_4HC86UQ88D9A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZu7dWz3UD7cJcujCFwj1LhFppTGp0kt_4HC86UQ88D9A%40mail.gmail.com?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/CAMD6iD9JzJk6oq2%2BRhD5ZcG_6snbx-ZvZNAHcJsEjh8WyRgv1A%40mail.gmail.com.
--001a11c017d4caea630537b216a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm not wrong; these are absolute facts, used by compi=
lers currently. I've run afoul of them, and I've benefited from the=
m.<div>You cannot simply state something is wrong with no evidence; provide=
evidence disproving the facts (which are widely evident in GCC, which can =
use undefined behavior to optimize code), or qualify your statement.</div><=
div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Fri, Jul 15, 2016 at 4:00 PM, Hyman Rosen <span dir=3D=
"ltr"><<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.=
rosen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri,=
Jul 15, 2016 at 2:40 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"m=
ailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a=
>></span> wrote:<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">Unsp=
ecified behavior is an opportunity. So is undefined behavior. They are not =
bad; they are necessary evils for performance</div></blockquote><div><br></=
div><div>I understand that you believe that.=C2=A0 But you are wrong.=C2=A0=
It is important to me that your wrong beliefs are not the only voice heard=
, so I make sure to speak up to contradict them. =C2=A0(I do that in other =
circumstances too.=C2=A0 It annoys my wife no end.) =C2=A0This way, when a =
wrong decision is made on the basis of false beliefs, after the decision ma=
kers have realized their mistake they cannot say that everyone agreed with =
their decision and that they were not warned.</div></div></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" 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@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/CAHSYqdZu7dWz3UD7cJcujCFwj1LhFppTGp0k=
t_4HC86UQ88D9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAHSYqdZu7dWz3UD7cJcujCFwj1LhFppTGp0kt_4HC86UQ88D9A%40mail.gmail.com</=
a>.<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" 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/CAMD6iD9JzJk6oq2%2BRhD5ZcG_6snbx-ZvZN=
AHcJsEjh8WyRgv1A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9JzJk6oq=
2%2BRhD5ZcG_6snbx-ZvZNAHcJsEjh8WyRgv1A%40mail.gmail.com</a>.<br />
--001a11c017d4caea630537b216a9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 15 Jul 2016 15:03:31 -0700
Raw View
On sexta-feira, 15 de julho de 2016 12:45:33 PDT Hyman Rosen wrote:
> On Fri, Jul 15, 2016 at 10:37 AM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > The point is that one benchmark is enough to prove that the performance
> > impact
> > or gain can happen. It's not a theoretical exercise, it's real: swapping
> > the
> > order of evaluation of a given program HAS BEEN PROVEN to either improve
> > or
> > worsen a particular task.
>
> And the point is that decades of experience with C++ have proven that
> unspecified order of evaluation causes latent errors, and so unspecified
> order of evaluation HAS BEEN PROVEN to worsen the cost of programming in
> C++.
Agreed, that is a fact.
> In my opinion, the cost demonstrated by the benchmark is
> insignificant for practical use of C++ while the cost of latent errors is
> large, and therefore the C++ Committee has incorrectly weighed those costs
> in deciding what to do.
And that's an opinion, one that is not shared by everyone.
> And mixing l-to-r, r-to-l, and unspecified behavior requirements into one
> expression is ridiculous. The one good thing coming from Oulu with respect
> to evaluation order is that at least function argument evaluation must be
> sequenced in *some* order.
And this is *also* an opinion, though you stated it as a fact.
--
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/1595251.LGEta9TDLf%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 15 Jul 2016 14:59:50 -0700
Raw View
On sexta-feira, 15 de julho de 2016 16:06:21 PDT Hyman Rosen wrote:
> On Fri, Jul 15, 2016 at 2:40 PM, Ren Industries <renindustries@gmail.com>
>
> wrote:
> > You say, with probability 1, that no one cares. I care
>
> I'm using "with probability 1" in this sense
> <https://en.wikipedia.org/wiki/Almost_surely> as a joke, to imply that you
> are the only one who cares.
Where "you" here is almost everyone in this mailing list except you yourself,
plus the members of the C++ committee who analysed the issue.
--
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/1926920.30990Agc2e%40tjmaciei-mobl1.
.
Author: "T. C." <rs2740@gmail.com>
Date: Fri, 15 Jul 2016 15:07:53 -0700 (PDT)
Raw View
------=_Part_2129_399129758.1468620473820
Content-Type: multipart/alternative;
boundary="----=_Part_2130_1051455517.1468620473820"
------=_Part_2130_1051455517.1468620473820
Content-Type: text/plain; charset=UTF-8
On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>
>
> In C and C++98/03, for some initialized and distinct scalar objects x and
> y, x ^= y ^= x ^= y will cause undefined behavior, but C++11 assignment
> allows it for non-volatile scalars, because the C++11 rules makes it
> effectively ordered (in such cases), with *right-to-left* order.
>
>
Nope, that's still undefined. It's essentially the same as i += ++i + 1;
discussed
in http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-undefined-behavior
i = ++i + 1 is fine in C++11. i += ++i + 1 is not.
--
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/3f5e5f2d-d173-408d-aef1-1c119271103a%40isocpp.org.
------=_Part_2130_1051455517.1468620473820
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, F=
rankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>In C and C++98/03, for some initialized and distinct scalar ob=
jects x and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C+=
+11 assignment allows it for non-volatile scalars, because the C++11 rules =
makes it effectively ordered (in such cases), with <i>right-to-left</i> ord=
er.<br><br></div></div></blockquote><div><br></div><div>Nope, that's st=
ill undefined. It's essentially the same as i +=3D ++i + 1; discussed i=
n=C2=A0http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibi=
t-undefined-behavior</div><div><br></div><div>i =3D ++i + 1 is fine in C++1=
1. i +=3D ++i + 1 is not.=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" 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/3f5e5f2d-d173-408d-aef1-1c119271103a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f5e5f2d-d173-408d-aef1-1c119271103a=
%40isocpp.org</a>.<br />
------=_Part_2130_1051455517.1468620473820--
------=_Part_2129_399129758.1468620473820--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 16:00:14 -0400
Raw View
--001a114a84984ceed50537b212cd
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 2:40 PM, Ren Industries <renindustries@gmail.com>
wrote:
> Unspecified behavior is an opportunity. So is undefined behavior. They are
> not bad; they are necessary evils for performance
>
I understand that you believe that. But you are wrong. It is important to
me that your wrong beliefs are not the only voice heard, so I make sure to
speak up to contradict them. (I do that in other circumstances too. It
annoys my wife no end.) This way, when a wrong decision is made on the
basis of false beliefs, after the decision makers have realized their
mistake they cannot say that everyone agreed with their decision and that
they were not warned.
--
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/CAHSYqdZu7dWz3UD7cJcujCFwj1LhFppTGp0kt_4HC86UQ88D9A%40mail.gmail.com.
--001a114a84984ceed50537b212cd
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, Jul 15, 2016 at 2:40 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Unspecified behavior is an opportunity. So is undefined behavior. They are=
not bad; they are necessary evils for performance</div></blockquote><div><=
br></div><div>I understand that you believe that.=C2=A0 But you are wrong.=
=C2=A0 It is important to me that your wrong beliefs are not the only voice=
heard, so I make sure to speak up to contradict them. =C2=A0(I do that in =
other circumstances too.=C2=A0 It annoys my wife no end.) =C2=A0This way, w=
hen a wrong decision is made on the basis of false beliefs, after the decis=
ion makers have realized their mistake they cannot say that everyone agreed=
with their decision and that they were not warned.</div></div></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/CAHSYqdZu7dWz3UD7cJcujCFwj1LhFppTGp0k=
t_4HC86UQ88D9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZu7dWz3UD7=
cJcujCFwj1LhFppTGp0kt_4HC86UQ88D9A%40mail.gmail.com</a>.<br />
--001a114a84984ceed50537b212cd--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 17:17:58 -0400
Raw View
--001a114ab99c3e679a0537b32807
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 4:20 PM, <inkwizytoryankes@gmail.com> wrote:
>
> First of all floating point are only approximation of real numbers.
>
Machine floating-point consists of a finite set of rational numbers (and a
handful of singular values) with exactly-defined arithmetic.
You will never have 1 / 3 in it.
>
This is true.
Equal compare only bit patterns that are useless because what we need are
> values that not exists in floating points.
>
Floating-point numbers are equal when they're equal. If you need
floating-point values that cannot exist as floating-point values, whatever
that even means, I'm not sure what to say to help you.
> Both `i / 3` and `1.0f / 3` are bit patterns that could represents 1 / 3.
> Because both bit patterns are different we have rounding errors (rounding
> to float point precision).
>
The problem is that both of those expressions have type float, but the
language permits them to have "secret" extended type, so that even though
they are the results of identical calculations in the source code, they do
not have to have the same value. As with the old near and far pointers,
this is Intel architecture (this time the x87 extended registers) reaching
into the language, this time to sacrifice well-defined semantics in
exchange for speed. And with SSE2 instructions, it is no longer a
problem. Intel taketh away and Intel giveth.
How do you want represent 1 / 3, E or Pi in it?
>
That depends on what you need to do with them. For some applications,
using the closest binary floating-point value to the number you want is
fine. For some applications, using the closest decimal floating-point
value to the number you want is fine. For some applications, you may want
to use a rational number package, possibly built on top of an
arbitrary-length integer package. And finally, for some applications you
may need a full symbolic algebra system.
> And if 2 + 2 some times give 5 is not problem if I excepts number of
> amplitude of 100000000. I'm only interested if overall errors are growing
> or shrinking in consequential calculations. This is basic of computation in
> mathematic from 17th centaury.
>
Sometimes people need to know
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.9012&rep=rep1&type=pdf>
exactly
what their arithmetic is doing.
--
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/CAHSYqdbiJOHBqjCKpN6WxdRFG0S9V2E7GmHP5tuUpueERiGajA%40mail.gmail.com.
--001a114ab99c3e679a0537b32807
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, Jul 15, 2016 at 4:20 PM, <span dir=3D"ltr"><<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>>=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>First of all floating =
point are only approximation of real numbers.</div></div></blockquote><div>=
<br>Machine floating-point consists of a finite set of rational numbers (an=
d a handful of singular values) with exactly-defined arithmetic.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div> You will never have 1 / 3 in it.=
</div></div></blockquote><div><br>This is true.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div> Equal compare only bit patterns that are useless =
because what we need are values that not exists in floating points.<br></di=
v></div></blockquote><div><br></div><div>Floating-point numbers are equal w=
hen they're equal.=C2=A0 If you need floating-point values that cannot =
exist as floating-point values, whatever that even means, I'm not sure =
what to say to help you.</div><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div>Both `i / 3` and `1.0f / 3` are bit patterns that could repr=
esents 1 / 3. Because both bit patterns are different we have rounding erro=
rs (rounding to float point precision).<br></div></div></blockquote><div><b=
r></div><div>The problem is that both of those expressions have type <font =
face=3D"monospace, monospace">float</font>, but the language permits them t=
o have "secret" extended type, so that even though they are the r=
esults of identical calculations in the source code, they do not have to ha=
ve the same value.=C2=A0 As with the old <font face=3D"monospace, monospace=
">near</font> and <font face=3D"monospace, monospace">far</font> pointers, =
this is Intel architecture (this time the x87 extended registers) reaching =
into the language, this time to sacrifice well-defined semantics in exchang=
e for speed.=C2=A0 And with SSE2 instructions, it is no longer a problem.=
=C2=A0 Intel taketh away and Intel giveth.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>How do you want represent 1 / 3, E or Pi in it?<=
/div></div></blockquote><div><br>That depends on what you need to do with t=
hem.=C2=A0 For some applications, using the closest binary floating-point v=
alue to the number you want is fine.=C2=A0 For some applications, using the=
closest decimal floating-point value to the number you want is fine.=C2=A0=
For some applications, you may want to use a rational number package, poss=
ibly built on top of an arbitrary-length integer package.=C2=A0 And finally=
, for some applications you may need a full symbolic algebra system.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>And if 2 + 2 some ti=
mes give 5 is not problem if I excepts number of amplitude of 100000000. I&=
#39;m only interested if overall errors are growing or shrinking in consequ=
ential calculations. This is basic of computation in mathematic from 17th c=
entaury.</div></div></blockquote><div><br>Sometimes people <a href=3D"http:=
//citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.123.9012&rep=3Dre=
p1&type=3Dpdf">need to know</a>=C2=A0exactly what their arithmetic is d=
oing.=C2=A0</div></div></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/CAHSYqdbiJOHBqjCKpN6WxdRFG0S9V2E7GmHP=
5tuUpueERiGajA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbiJOHBqjCK=
pN6WxdRFG0S9V2E7GmHP5tuUpueERiGajA%40mail.gmail.com</a>.<br />
--001a114ab99c3e679a0537b32807--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Fri, 15 Jul 2016 16:10:59 -0400
Raw View
--001a11c02fbc997ec60537b23720
Content-Type: text/plain; charset=UTF-8
Yes, but you said it to someone else. We're now two strong!
On Fri, Jul 15, 2016 at 4:06 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Fri, Jul 15, 2016 at 2:40 PM, Ren Industries <renindustries@gmail.com>
> wrote:
>>
>> You say, with probability 1, that no one cares. I care
>>
>
> I'm using "with probability 1" in this sense
> <https://en.wikipedia.org/wiki/Almost_surely> as a joke, to imply that
> you are the only one who cares.
>
> --
> 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/CAHSYqdYOCm%2BdV3zy6noJ9eLabvmhburbH9%3DGbpbTBt54z%3DD6jw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYOCm%2BdV3zy6noJ9eLabvmhburbH9%3DGbpbTBt54z%3DD6jw%40mail.gmail.com?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/CAMD6iD_JY1Ac9pnkkjjdmrJ3ppDcbarZSw7oxRcM2QGonMiGQA%40mail.gmail.com.
--001a11c02fbc997ec60537b23720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, but you said it to someone else. We're now two st=
rong!</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri=
, Jul 15, 2016 at 4:06 PM, Hyman Rosen <span dir=3D"ltr"><<a href=3D"mai=
lto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Jul 15=
, 2016 at 2:40 PM, Ren Industries <span dir=3D"ltr"><<a href=3D"mailto:r=
enindustries@gmail.com" target=3D"_blank">renindustries@gmail.com</a>></=
span> wrote:</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>You=
say, with probability 1, that no one cares. I care</div></div></blockquote=
><div><br></div><div>I'm using "with probability 1" in this <=
a href=3D"https://en.wikipedia.org/wiki/Almost_surely" target=3D"_blank">se=
nse</a>=C2=A0as a joke, to imply that you are the only one who cares.</div>=
</div></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" 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@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/CAHSYqdYOCm%2BdV3zy6noJ9eLabvmhburbH9=
%3DGbpbTBt54z%3DD6jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHSYqdYOCm%2BdV3zy6noJ9eLabvmhburbH9%3DGbpbTBt54z%3DD6jw%40mail=
..gmail.com</a>.<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" 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/CAMD6iD_JY1Ac9pnkkjjdmrJ3ppDcbarZSw7o=
xRcM2QGonMiGQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_JY1Ac9pnk=
kjjdmrJ3ppDcbarZSw7oxRcM2QGonMiGQA%40mail.gmail.com</a>.<br />
--001a11c02fbc997ec60537b23720--
.
Author: inkwizytoryankes@gmail.com
Date: Fri, 15 Jul 2016 17:31:12 -0700 (PDT)
Raw View
------=_Part_2407_327107162.1468629072952
Content-Type: multipart/alternative;
boundary="----=_Part_2408_215697648.1468629072953"
------=_Part_2408_215697648.1468629072953
Content-Type: text/plain; charset=UTF-8
On Friday, July 15, 2016 at 11:18:19 PM UTC+2, Hyman Rosen wrote:
>
> On Fri, Jul 15, 2016 at 4:20 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>>
>> First of all floating point are only approximation of real numbers.
>>
>
> Machine floating-point consists of a finite set of rational numbers (and a
> handful of singular values) with exactly-defined arithmetic.
>
> You will never have 1 / 3 in it.
>>
>
> This is true.
>
> Equal compare only bit patterns that are useless because what we need are
>> values that not exists in floating points.
>>
>
> Floating-point numbers are equal when they're equal. If you need
> floating-point values that cannot exist as floating-point values, whatever
> that even means, I'm not sure what to say to help you.
>
>
I need 1 / 3, can you provide me one if it can't exists? I need choose one
that always will have rounding error.
And now I would like to have 1 / 9. I can choose again but what happens
with equality 1 / 9 * 3 == 1 / 3? It can't be true for bit pattern equality.
EVERY floating point operation have build in rounding errors. Even add can
give "correct" results only when you add numbers of equal exponent.
> Both `i / 3` and `1.0f / 3` are bit patterns that could represents 1 / 3.
>> Because both bit patterns are different we have rounding errors (rounding
>> to float point precision).
>>
>
> The problem is that both of those expressions have type float, but the
> language permits them to have "secret" extended type, so that even though
> they are the results of identical calculations in the source code, they do
> not have to have the same value. As with the old near and far pointers,
> this is Intel architecture (this time the x87 extended registers) reaching
> into the language, this time to sacrifice well-defined semantics in
> exchange for speed. And with SSE2 instructions, it is no longer a
> problem. Intel taketh away and Intel giveth.
>
>
But whole point of this is to have better accuracy than otherwise possible.
Your "error" is value that is closer to real number value that you suppose
to get. You can't store it but you can continue calculating based on it.
>
>
How do you want represent 1 / 3, E or Pi in it?
>>
>
> That depends on what you need to do with them. For some applications,
> using the closest binary floating-point value to the number you want is
> fine. For some applications, using the closest decimal floating-point
> value to the number you want is fine. For some applications, you may want
> to use a rational number package, possibly built on top of an
> arbitrary-length integer package. And finally, for some applications you
> may need a full symbolic algebra system.
>
>
>> And if 2 + 2 some times give 5 is not problem if I excepts number of
>> amplitude of 100000000. I'm only interested if overall errors are growing
>> or shrinking in consequential calculations. This is basic of computation in
>> mathematic from 17th centaury.
>>
>
> Sometimes people need to know
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.9012&rep=rep1&type=pdf> exactly
> what their arithmetic is doing.
>
No, they only need to know amplitude of error. And if someone give them
tool with greater accuracy ("secret" extended type) they will be more than
pleased. All equalities that they use still holds for for it.
But there is catch, they do not use bit equal. Even funnier FMA is used to
recreate calculation in in greater accuracy that is equal if compiler is
allowed to use greater accuracy than storage type have.
This mean you get result of this paper in C++ for free.
And going back to main topic (order of evaluation), you assume its wrong
even if other prove that benefits outweighs costs.
C/C++ simply represents common part of multiple different machines and
systems, and undefined/unspecified behavior play major role in that.
This is worth more than cost of bugs from people who abuse it.
--
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/7a530b3d-8c1e-4748-9bca-3d4e73da0c24%40isocpp.org.
------=_Part_2408_215697648.1468629072953
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, July 15, 2016 at 11:18:19 PM UTC+2, Hym=
an Rosen 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 class=3D"gmail_quote">On Fri, Jul 15, 2016 at 4:20 PM, <span d=
ir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"PihR5MStCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">inkwizyt...@gmail.com</a>></span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>First of all floating point are only approximation of real=
numbers.</div></div></blockquote><div><br>Machine floating-point consists =
of a finite set of rational numbers (and a handful of singular values) with=
exactly-defined arithmetic.<br><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div> You will never have 1 / 3 in it.</div></div></blockquote><div><br>Th=
is is true.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> Equal comp=
are only bit patterns that are useless because what we need are values that=
not exists in floating points.<br></div></div></blockquote><div><br></div>=
<div>Floating-point numbers are equal when they're equal.=C2=A0 If you =
need floating-point values that cannot exist as floating-point values, what=
ever that even means, I'm not sure what to say to help you.</div><div>=
=C2=A0<br></div></div></div></div></blockquote><div><br>I need 1 / 3, can y=
ou provide me one if it can't exists? I need choose one that always wil=
l have rounding error.<br>And now I would like to have 1 / 9. I can choose =
again but what happens with equality 1 / 9 * 3 =3D=3D 1 / 3? It can't b=
e true for bit pattern equality.<br>EVERY floating point operation have bui=
ld in rounding errors. Even=20
add can give "correct" results only when you add numbers of equal=
=20
exponent.<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div>Both `i / 3` and `1.0f / 3` are bit patterns that co=
uld represents 1 / 3. Because both bit patterns are different we have round=
ing errors (rounding to float point precision).<br></div></div></blockquote=
><div><br></div><div>The problem is that both of those expressions have typ=
e <font face=3D"monospace, monospace">float</font>, but the language permit=
s them to have "secret" extended type, so that even though they a=
re the results of identical calculations in the source code, they do not ha=
ve to have the same value.=C2=A0 As with the old <font face=3D"monospace, m=
onospace">near</font> and <font face=3D"monospace, monospace">far</font> po=
inters, this is Intel architecture (this time the x87 extended registers) r=
eaching into the language, this time to sacrifice well-defined semantics in=
exchange for speed.=C2=A0 And with SSE2 instructions, it is no longer a pr=
oblem.=C2=A0 Intel taketh away and Intel giveth.</div><div><br></div></div>=
</div></div></blockquote><div><br>But whole point of this is to have better=
accuracy than otherwise possible. Your "error" is value that is =
closer to real number value that you suppose to get. You can't store it=
but you can continue calculating based on it.<br>=C2=A0</div><blockquote c=
lass=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 class=3D"gmail_q=
uote"><div>=C2=A0</div></div></div></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><d=
iv></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>How do you want represent 1=
/ 3, E or Pi in it?</div></div></blockquote><div><br>That depends on what =
you need to do with them.=C2=A0 For some applications, using the closest bi=
nary floating-point value to the number you want is fine.=C2=A0 For some ap=
plications, using the closest decimal floating-point value to the number yo=
u want is fine.=C2=A0 For some applications, you may want to use a rational=
number package, possibly built on top of an arbitrary-length integer packa=
ge.=C2=A0 And finally, for some applications you may need a full symbolic a=
lgebra system.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>And if 2 + 2 some times give 5 is not problem if I excepts number of ampli=
tude of 100000000. I'm only interested if overall errors are growing or=
shrinking in consequential calculations. This is basic of computation in m=
athematic from 17th centaury.</div></div></blockquote><div><br>Sometimes pe=
ople <a href=3D"http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.=
123.9012&rep=3Drep1&type=3Dpdf" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2=
Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.123.9012%26rep%3=
Drep1%26type%3Dpdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJUdF15GsBIuAe3o=
xiNbWceQFmCg';return true;" onclick=3D"this.href=3D'http://www.goog=
le.com/url?q\x3dhttp%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fd=
oi%3D10.1.1.123.9012%26rep%3Drep1%26type%3Dpdf\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNEJUdF15GsBIuAe3oxiNbWceQFmCg';return true;">need to know</a=
>=C2=A0exactly what their arithmetic is doing.=C2=A0</div></div></div></div=
></blockquote><div>=C2=A0<br>No, they only need to know amplitude of error.=
And if someone give them tool with greater accuracy ("secret" ex=
tended type) they will be more than pleased. All equalities that they use s=
till holds for for it.<br>But there is catch, they do not use bit equal. Ev=
en funnier FMA is used to recreate calculation in in greater accuracy that =
is equal if compiler is allowed to use greater accuracy than storage type h=
ave.<br>This mean you get result of this paper in C++ for free.<br><br><br>=
And going back to main topic (order of evaluation), you assume its wrong ev=
en if other prove that benefits outweighs costs.<br>C/C++ simply represents=
common part of multiple different machines and systems, and undefined/unsp=
ecified behavior play major role in that.<br>This is worth more than cost o=
f bugs from people who abuse it.<br></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/7a530b3d-8c1e-4748-9bca-3d4e73da0c24%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a530b3d-8c1e-4748-9bca-3d4e73da0c24=
%40isocpp.org</a>.<br />
------=_Part_2408_215697648.1468629072953--
------=_Part_2407_327107162.1468629072952--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 15 Jul 2016 23:55:02 +0100
Raw View
--001a1147578649afaa0537b482bd
Content-Type: text/plain; charset=UTF-8
On 15 Jul 2016 9:38 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
> Programming languages are designed to control computers.
How could that be possible, when a computer program can be run on a
computer that did not exist and had not been designed at the time the
program was written or compiled?
--
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/CAJnLdOYux-3bPCw-cmoFz17ZEc7pAVNQ26frgf0Gds2fh7dCEQ%40mail.gmail.com.
--001a1147578649afaa0537b482bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 15 Jul 2016 9:38 p.m., "Hyman Rosen" <<a hre=
f=3D"mailto:hyman.rosen@gmail.com">hyman.rosen@gmail.com</a>> wrote:<br>
> Programming languages are designed to control computers.=C2=A0 </p>
<p dir=3D"ltr">How could that be possible, when a computer program can be r=
un on a computer that did not exist and had not been designed at the time t=
he program was written or compiled? <br>
</p>
<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/CAJnLdOYux-3bPCw-cmoFz17ZEc7pAVNQ26fr=
gf0Gds2fh7dCEQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYux-3bPCw-=
cmoFz17ZEc7pAVNQ26frgf0Gds2fh7dCEQ%40mail.gmail.com</a>.<br />
--001a1147578649afaa0537b482bd--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 16:06:21 -0400
Raw View
--001a114084682a5a4b0537b2288c
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 2:40 PM, Ren Industries <renindustries@gmail.com>
wrote:
>
> You say, with probability 1, that no one cares. I care
>
I'm using "with probability 1" in this sense
<https://en.wikipedia.org/wiki/Almost_surely> as a joke, to imply that you
are the only one who cares.
--
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/CAHSYqdYOCm%2BdV3zy6noJ9eLabvmhburbH9%3DGbpbTBt54z%3DD6jw%40mail.gmail.com.
--001a114084682a5a4b0537b2288c
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, Jul 15, 2016 at 2:40 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>You say, with probability 1, that no one cares. I care</div></div></block=
quote><div><br></div><div>I'm using "with probability 1" in t=
his <a href=3D"https://en.wikipedia.org/wiki/Almost_surely">sense</a>=C2=A0=
as a joke, to imply that you are the only one who cares.</div></div></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/CAHSYqdYOCm%2BdV3zy6noJ9eLabvmhburbH9=
%3DGbpbTBt54z%3DD6jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYOCm=
%2BdV3zy6noJ9eLabvmhburbH9%3DGbpbTBt54z%3DD6jw%40mail.gmail.com</a>.<br />
--001a114084682a5a4b0537b2288c--
.
Author: inkwizytoryankes@gmail.com
Date: Fri, 15 Jul 2016 13:20:34 -0700 (PDT)
Raw View
------=_Part_2264_37219188.1468614035060
Content-Type: multipart/alternative;
boundary="----=_Part_2265_494182933.1468614035060"
------=_Part_2265_494182933.1468614035060
Content-Type: text/plain; charset=UTF-8
On Friday, July 15, 2016 at 7:22:20 PM UTC+2, Hyman Rosen wrote:
>
> On Fri, Jul 15, 2016 at 11:28 AM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>>
>> On Wednesday, July 13, 2016 at 7:58:49 PM UTC+2, Hyman Rosen wrote:
>>>
>>> (Broken how? For example, C++ does not require that the following
>>> program succeed:
>>> #include <assert.h>
>>> int main() { volatile float i = 1.f; assert(i / 3.f == 1.f / 3.f); }
>>> On my x86 Linux box, it fails when built with -mno-sse but works when
>>> SSE instructions are used.)
>>>
>> You should never use `==` for floating points. Each operation can have
>> rounding errors that will break strick equality (`1.0 / 3.0 * 3.0 != 1.0`).
>>
>
> This is false. Floating-point numbers have exact values and may be
> compared for equality with the expected meaning. Floating-point operations
> are well-defined and do not have "rounding errors" (except for some
> higher-order functions like the trigonometric ones which are not required
> to be correct to the last bit - likely another mistake in specification,
> but this problem is hard). The results of floating-point operations are
> rounded to the nearest representable result, however.
>
> The reason this code sometimes triggers the assertion is that the C++
> Standard gives implementations permission to do bad things:
> "The values of the floating operands and the results of floating
> expressions may be represented in greater precision and range than that
> required by the type; the types are not changed thereby."
>
> So in the code above, the expression i / 3. and the expression 1 / 3. may
> be evaluated at different precision (likely i / 3. in an extended register
> and 1 / 3. as a precomputed constant value) and therefore the equality test
> fails. But that's not because floating-point arithmetic has round-off
> errors, it's because the designers of C++ followed C in favoring speed over
> correctness using knowledge of then extant floating-point hardware - with
> this permission granted, the compiler does not have to convert the extended
> register to a float value before doing the comparison. As it happens, with
> SSE the compiler can just generate a "compare as float" instruction so the
> problem goes away.
>
>
First of all floating point are only approximation of real numbers. You
will never have 1 / 3 in it. Equal compare only bit patterns that are
useless because what we need are values that not exists in floating points.
Both `i / 3` and `1.0f / 3` are bit patterns that could represents 1 / 3.
Because both bit patterns are different we have rounding errors (rounding
to float point precision).
> Btw how you want made this code portable if two machines have different
>> floating point units? You example show this exactly because `-mno-sse`
>> is completely different machine than with sse.
>> Who will pay penalty for not matching expected float accuracy?
>>
>
> I want this code to be portable by having the language specify what
> floating-point operations do. It is unconscionable that evaluating the
> same floating-point expression multiple times can give different results.
> A programming language that decided that 2 + 2 should occasionally yield 5
> would not get very far. But too many people have the notion that
> floating-point arithmetic isn't accurate anyway, and has round-off errors,
> so what the heck, no one cares anyway, let's be wrong but fast.
>
How do you want represent 1 / 3, E or Pi in it? You have limiter memory and
number of all possible real numbers are infinite with infinite precision.
You could avoid some problems with symbolic calculation but it too have
same limitation.
And if 2 + 2 some times give 5 is not problem if I excepts number of
amplitude of 100000000. I'm only interested if overall errors are growing
or shrinking in consequential calculations. This is basic of computation in
mathematic from 17th centaury.
--
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/90b62265-1f9c-4aab-a036-745dd87d4c89%40isocpp.org.
------=_Part_2265_494182933.1468614035060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, July 15, 2016 at 7:22:20 PM UTC+2, Hyma=
n Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 11:28 AM, <span d=
ir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"iMrgTOSgCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">inkwizyt...@gmail.com</a>></span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">On Wednesday, July 13, 2016 at 7:58:49 PM UTC+2, Hyman Rosen wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
(Broken how?=C2=A0 For example, C++ does not require that the following pro=
gram succeed:<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=A0#in=
clude <assert.h></font></div><div><font face=3D"monospace, monospace"=
>=C2=A0 =C2=A0=C2=A0int main() { volatile float i =3D 1.f; assert(i / 3.f =
=3D=3D 1.f / 3.f); }</font><br><font face=3D"arial, helvetica, sans-serif">=
On my x86 Linux box, it fails when built with -mno-sse but works when SSE i=
nstructions are used.)</font></div></div></div></div></blockquote><div>You =
should never use `=3D=3D` for floating points. Each operation can have roun=
ding errors that will break strick equality (`1.0 / 3.0 * 3.0 !=3D 1.0`).<b=
r></div></div></blockquote><div><br></div><div>This is false.=C2=A0 Floatin=
g-point numbers have exact values and may be compared for equality with the=
expected meaning.=C2=A0 Floating-point operations are well-defined and do =
not have "rounding errors" (except for some higher-order function=
s like the trigonometric ones which are not required to be correct to the l=
ast bit - likely another mistake in specification, but this problem is hard=
).=C2=A0 The results of floating-point operations are rounded to the neares=
t representable result, however.<br><br>The reason this code sometimes trig=
gers the assertion is that the C++ Standard gives implementations permissio=
n to do bad things:<br>=C2=A0 =C2=A0 "The values of the floating opera=
nds and the results of floating expressions may be represented in greater p=
recision and range than that required by the type; the types are not change=
d thereby."<br><br>So in the code above, the expression i / 3. and the=
expression 1 / 3. may be evaluated at different precision (likely i / 3. i=
n an extended register and 1 / 3. as a precomputed constant value) and ther=
efore the equality test fails.=C2=A0 But that's not because floating-po=
int arithmetic has round-off errors, it's because the designers of C++ =
followed C in favoring speed over correctness using knowledge of then extan=
t floating-point hardware - with this permission granted, the compiler does=
not have to convert the extended register to a float value before doing th=
e comparison.=C2=A0 As it happens, with SSE the compiler can just generate =
a "compare as float" instruction so the problem goes away.</div><=
div>=C2=A0</div></div></div></div></blockquote><div><br>First of all floati=
ng point are only approximation of real numbers. You will never have 1 / 3 =
in it. Equal compare only bit patterns that are useless because what we nee=
d are values that not exists in floating points.<br>Both `i / 3` and `1.0f =
/ 3` are bit patterns that could represents 1 / 3. Because both bit pattern=
s are different we have rounding errors (rounding to float point precision)=
..<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
Btw how you want made this code portable if two machines have different flo=
ating point units? You example show this exactly because `<font face=3D"ari=
al, helvetica, sans-serif">-mno-sse</font>` is completely different machine=
than with sse.<br>Who will pay penalty for not matching expected float acc=
uracy?</div></div></blockquote><div><br></div><div>I want this code to be p=
ortable by having the language specify what floating-point operations do.=
=C2=A0 It is unconscionable that evaluating the same floating-point express=
ion multiple times can give different results.=C2=A0 A programming language=
that decided that 2 + 2 should occasionally yield 5 would not get very far=
..=C2=A0 But too many people have the notion that floating-point arithmetic =
isn't accurate anyway, and has round-off errors, so what the heck, no o=
ne cares anyway, let's be wrong but fast.</div></div></div></div></bloc=
kquote><div><br>How do you want represent 1 / 3, E or Pi in it? You have li=
miter memory and number of all possible real numbers are infinite with infi=
nite precision. You could avoid some problems with symbolic calculation but=
it too have same limitation.<br>And if 2 + 2 some times give 5 is not prob=
lem if I excepts number of amplitude of 100000000. I'm only interested =
if overall errors are growing or shrinking in consequential calculations. T=
his is basic of computation in mathematic from 17th centaury.<br></div></di=
v>
<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/90b62265-1f9c-4aab-a036-745dd87d4c89%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90b62265-1f9c-4aab-a036-745dd87d4c89=
%40isocpp.org</a>.<br />
------=_Part_2265_494182933.1468614035060--
------=_Part_2264_37219188.1468614035060--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 15 Jul 2016 15:01:51 -0700
Raw View
On sexta-feira, 15 de julho de 2016 12:38:02 PDT Hyman Rosen wrote:
> Unspecified behavior is a problem when programmers can easily write
> programs that have unspecified behavior without realizing it.
I think we can safely say we all agree with this statement.
> When unspecified behavior has no practical benefit and the behavior of the
> constructs involved can be easily specified, it is an error in the
> programming language design not to specify that behavior.
And this one.
But note that this second sentence has a conditional, "when unspecified
behaviour has no practical benefit". There is a practical benefit for this case,
brought up over and over again.
So it's not a question of having no benefit.
The question is whether the benefit outweighs the risk of programmers
unwittingly depending on unspecified behaviour.
--
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/2543210.mGdaBTiKGl%40tjmaciei-mobl1.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 15 Jul 2016 16:38:14 -0400
Raw View
--001a114a8498268df60537b29aac
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 2:45 PM, Ren Industries <renindustries@gmail.com>
wrote:
> It IS of practical benefits. It leads to expressiveness that allow the
> compiler to increase the speed of execution. To disagree with this is
> intellectually dishonest, as you have constantly been by asserting
> something fundamentally against the very specification of C++: That it is
> defined in terms of practical computers, not abstract machines.
>
But in fact, the benchmark suite that was run against a left-to-right
compiler did not show that the compiler was doing this. It just happened
that the effects of l-to-r on one benchmark were slightly negative.
Programming languages are designed to control computers. When a
programming language does not define the behavior of its constructs and the
programming environment does not inform the programmer that the program is
ambiguous and the program does not control the computer in the way the
programmer intended because the programming language environment chose a
permitted but different meaning, then the programming language definition
is bad.
--
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/CAHSYqdaY5MgFo0bfHe8Y0k7grgq794fVFKh1qUd%2BGQp6aubsLw%40mail.gmail.com.
--001a114a8498268df60537b29aac
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, Jul 15, 2016 at 2:45 PM, Ren Industries <span dir=3D"ltr"><<a href=
=3D"mailto:renindustries@gmail.com" target=3D"_blank">renindustries@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>It IS of practical benefits. It leads to expressiveness that allow the com=
piler to increase the speed of execution. To disagree with this is intellec=
tually dishonest, as you have constantly been by asserting something fundam=
entally against the very specification of C++: That it is defined in terms =
of practical computers, not abstract machines.</div></blockquote><div><br>B=
ut in fact, the benchmark suite that was run against a left-to-right compil=
er did not show that the compiler was doing this.=C2=A0 It just happened th=
at the effects of l-to-r on one benchmark were slightly negative.</div><div=
><br></div><div>Programming languages are designed to control computers.=C2=
=A0 When a programming language does not define the behavior of its constru=
cts and the programming environment does not inform the programmer that the=
program is ambiguous and the program does not control the computer in the =
way the programmer intended because the programming language environment ch=
ose a permitted but different meaning, then the programming language defini=
tion is bad.</div></div></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/CAHSYqdaY5MgFo0bfHe8Y0k7grgq794fVFKh1=
qUd%2BGQp6aubsLw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaY5MgFo0=
bfHe8Y0k7grgq794fVFKh1qUd%2BGQp6aubsLw%40mail.gmail.com</a>.<br />
--001a114a8498268df60537b29aac--
.
Author: wileversmod@gmail.com
Date: Fri, 15 Jul 2016 22:53:24 -0700 (PDT)
Raw View
------=_Part_2503_716113056.1468648405026
Content-Type: multipart/alternative;
boundary="----=_Part_2504_1039244510.1468648405026"
------=_Part_2504_1039244510.1468648405026
Content-Type: text/plain; charset=UTF-8
On Friday, July 15, 2016 at 8:48:21 PM UTC+2, Ren Industries wrote:
>
> This is ridiculous; Java has strict IEEE 754 semantics, and it *costs
> them dearly in terms of performance.* C++ allows for closer to metal
> semantics, as this leads to better performance. If you wish to remove the
> reason people use C++ (performance), then why use C++ at all?
>
Performance is not the only reason people prefer C++ over Java. It should
not be the only consideration when shaping the language's future.
--
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/bdc87557-9f7a-4bd1-a211-4b0fe613d94d%40isocpp.org.
------=_Part_2504_1039244510.1468648405026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, July 15, 2016 at 8:48:21 PM UTC+2, Ren =
Industries wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>This is =
ridiculous; Java has strict IEEE 754 semantics, and it <i>costs them dearly=
in terms of performance.</i>=C2=A0C++ allows for closer to metal semantics=
, as this leads to better performance. If you wish to remove the reason peo=
ple use C++ (performance), then why use C++ at all?</div></blockquote><div>=
<br>Performance is not the only reason people prefer C++ over Java. It shou=
ld not be the only consideration when shaping the language's future. <b=
r></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/bdc87557-9f7a-4bd1-a211-4b0fe613d94d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bdc87557-9f7a-4bd1-a211-4b0fe613d94d=
%40isocpp.org</a>.<br />
------=_Part_2504_1039244510.1468648405026--
------=_Part_2503_716113056.1468648405026--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 18:23:45 -0700 (PDT)
Raw View
------=_Part_1368_1332399106.1468805026059
Content-Type: multipart/alternative;
boundary="----=_Part_1369_1475436346.1468805026060"
------=_Part_1369_1475436346.1468805026060
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=889:25:32=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 7:35 PM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>>
>> Since you have to know something, how is knowing "the order is=20
>> unspecified"
>> different from knowing "the order is specified as XYZ" ?
>>
>
> When the order is specified, you don't have to know it. If you write cod=
e=20
> with an order dependency, the order will always be the same. So either i=
t=20
> immediately doesn't work and you fix it, or it does work and then it will=
=20
> work forever. When the order is unspecified and you write code with an=
=20
> order dependency and it works, that latent error may manifest years later=
.. =20
> And that last is true even when you know that the order is unspecified,=
=20
> because it's easy to make a mistake and not notice.
>
> How can one trust the order is right (read: intended) without even knowin=
g=20
it?
Who can guarantee the *behavior *can be observed immediately? And who can=
=20
guarantee at once the behavior is expected, the program will behave=20
expected at any cases? I don't see it in the standard or documentation of=
=20
any implementation. Why "then it will work forever"?
=20
Specify literally if it is too not obvious to prevent a mistake.=20
>
> As many have pointed out, LTR is not as intuitive as it might seem to you=
..
>
>
> It's not that it's intuitive, it's that it's trivially easy to learn. Th=
e=20
> first time you need to know the order (presumably because you wrote=20
> order-dependent code that went the wrong way), you learn the rule, which=
=20
> can be expressed in one sentence, and it's so sharp and clear that you=20
> never forget it. Instead we have the hash that C, C++, and now C++17 hav=
e=20
> made of things.
>
It is actually harder to learn when not all C and C++ dialects does not=20
synchronized yet. It's even more trivially easy (and more universal) to=20
learn that you should not touch what you does not depend on and keep away=
=20
bad styles.
=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/d4d64882-ea3d-4f41-af8e-a348bc06f06d%40isocpp.or=
g.
------=_Part_1369_1475436346.1468805026060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=889:25:32=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 7:35 PM,=
Thiago Macieira <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"HXoRQ_iTCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">thi...@macieira.org</a>></span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Since you have to know something, how is k=
nowing "the order is unspecified"<br>
different from knowing "the order is specified as XYZ" ?<br></blo=
ckquote><div><br>When the order is specified, you don't have to know it=
..=C2=A0 If you write code with an order dependency, the order will always b=
e the same.=C2=A0 So either it immediately doesn't work and you fix it,=
or it does work and then it will work forever.=C2=A0 When the order is uns=
pecified and you write code with an order dependency and it works, that lat=
ent error may manifest years later.=C2=A0 And that last is true even when y=
ou know that the order is unspecified, because it's easy to make a mist=
ake and not notice.<br><br></div></div></div></div></blockquote><div>How ca=
n one trust the order is right (read: intended) without even knowing it?<br=
>Who can guarantee the <i>behavior </i>can be observed immediately? And who=
can guarantee at once the behavior is expected, the program will behave ex=
pected at any cases? I don't see it in the standard or documentation of=
any implementation. Why "then it will work forever"?<br>=C2=A0<b=
r>Specify literally if it is too not obvious to prevent a mistake. <br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As many have pointed out, LTR is not as intuitive as it might seem to you.<=
/blockquote><div><br></div><div>It's not that it's intuitive, it=
9;s that it's trivially easy to learn.=C2=A0 The first time you need to=
know the order (presumably because you wrote order-dependent code that wen=
t the wrong way), you learn the rule, which can be expressed in one sentenc=
e, and it's so sharp and clear that you never forget it.=C2=A0 Instead =
we have the hash that C, C++, and now C++17 have made of things.</div></div=
></div></div></blockquote><div>It is actually harder to learn when not all =
C and C++ dialects does not synchronized yet. It's even more trivially =
easy (and more universal) to learn that you should not touch what you does =
not depend on and keep away bad styles.<br>=C2=A0<br></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/d4d64882-ea3d-4f41-af8e-a348bc06f06d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d4d64882-ea3d-4f41-af8e-a348bc06f06d=
%40isocpp.org</a>.<br />
------=_Part_1369_1475436346.1468805026060--
------=_Part_1368_1332399106.1468805026059--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 18:26:46 -0700 (PDT)
Raw View
------=_Part_1408_1753821232.1468805206708
Content-Type: multipart/alternative;
boundary="----=_Part_1409_2062454587.1468805206708"
------=_Part_1409_2062454587.1468805206708
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=889:31:59=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 7:44 PM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>>
>> Yes. You changed the argument, though, by putting the parentheses.
>>
>
> How does that change the argument?
>
> I would have personally preferred depth-first, associativity, based on
>> precedence order, so
>>
>> a =3D b =3D c =3D d;
>>
>> should be equivalent to:
>> c =3D d;
>> b =3D c;
>> a =3D b;
>>
>> and
>> a + b * c
>> would be
>> decltype(auto) x =3D b * c;
>> a + x;
>> which implies an evaluation order of b, c, a.
>
>
> That's even worse than the mess we have now. I don't know whether to=20
> congratulate you or cry.
> Following your suggestion, a + b * c evaluates in the order b, c, a while=
=20
> a * x + b * c evaluates in the order a, x, b, c?
> Do you see why this is not a good idea?=20
>
I see it is more difficult when users have to remember more than one order.
Though actually I don't care it much because in most cases no order should=
=20
be depend on without explicit notes.
--=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/5c88217f-619c-4a9d-a0bf-1fc2c7f86b69%40isocpp.or=
g.
------=_Part_1409_2062454587.1468805206708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=889:31:59=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 7:44 PM,=
Thiago Macieira <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"WbCHWVKUCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">thi...@macieira.org</a>></span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Yes. You changed the argument, though, by =
putting the parentheses.<br></blockquote><div><br></div><div>How does that =
change the argument?<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would =
have personally preferred depth-first, associativity, based on<br>
precedence order, so<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D b =3D c =3D d;<br>
<br>
should be equivalent to:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c =3D d;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b =3D c;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D b;<br>
<br>
and<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a + b * c<br>
would be<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 decltype(auto) x =3D b * c;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a + x;<br>
which implies an evaluation order of b, c, a.</blockquote><div><br></div><d=
iv>That's even worse than the mess we have now.=C2=A0 I don't know =
whether to congratulate you or cry.<br>Following your suggestion, a + b * c=
evaluates in the order b, c, a while a * x + b * c evaluates in the order =
a, x, b, c?<br>Do you see why this is not a good idea?=C2=A0</div></div></d=
iv></div></blockquote><div>I see it is more difficult when users have to re=
member more than one order.<br>Though actually I don't care it much bec=
ause in most cases no order should be depend on without explicit notes.<br>=
<br></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/5c88217f-619c-4a9d-a0bf-1fc2c7f86b69%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c88217f-619c-4a9d-a0bf-1fc2c7f86b69=
%40isocpp.org</a>.<br />
------=_Part_1409_2062454587.1468805206708--
------=_Part_1408_1753821232.1468805206708--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 18:34:19 -0700 (PDT)
Raw View
------=_Part_1285_1561329855.1468805659308
Content-Type: multipart/alternative;
boundary="----=_Part_1286_385082487.1468805659308"
------=_Part_1286_385082487.1468805659308
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 7:48 PM, Ren Industries <renind...@gmail.com=20
> <javascript:>> wrote:
>
>> Okay? But that is clearly an opportunity, not a problem. It is only a=20
>> problem when programmers poorly use their tools; it is an opportunity=20
>> always to the compiler. What you see it as doesn't matter; it is clearly=
,=20
>> mathematically, an opportunity.
>>
>
> Blaming users is how designers always try to deflect blame from their own=
=20
> errors.
> "A user interface is like a joke. If you have to explain it, it's not=20
> very good."
>
> Do you mean every command line shell should not be explained or no shells=
=20
can be a good UI? That's totally nonsense.
Even GUI may need professional training to use. Are CAD or Photoshop jokes?
Moreover, not everything to be designed is UI (esp. for end-users), for=20
example, a mathematical definition or an API.
You are definitely not talking about the UI properly.
In this case, one piece of language design has sent thousands of=20
> programmers down the garden path. That is bad design. The "opportunity"=
=20
> that compilers are taking advantage of is illusory - it leads them to=20
> create translated programs that do not do what the authors of the origina=
l=20
> programs want them to do. When the problem is discovered, the original=
=20
> programs need to be rewritten so that the "opportunity" goes away.
>
Those programmers are not expected to be users. You show no evidence on=20
"bad" again.
=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/7401863f-3eb2-46ef-bfac-778eb5e954c9%40isocpp.or=
g.
------=_Part_1286_385082487.1468805659308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=
=86=99=E9=81=93=EF=BC=9A<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 Thu, Jul 14, 2016 at 7:48 PM,=
Ren Industries <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"j556kM-UCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">renind...@gmail.com</a>></span> wrote:<=
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">Okay? But that is clearl=
y an opportunity, not a problem. It is only a problem when programmers poor=
ly use their tools; it is an opportunity always to the compiler. What you s=
ee it as doesn't matter; it is clearly, mathematically, an opportunity.=
</div></blockquote><div><br></div><div>Blaming users is how designers alway=
s try to deflect blame from their own errors.<br>"A user interface is =
like a joke.=C2=A0 If you have to explain it, it's not very good."=
<br><br></div></div></div></div></blockquote><div>Do you mean every command=
line shell should not be explained or no shells can be a good UI? That'=
;s totally nonsense.<br>Even GUI may need professional training to use. Are=
CAD or Photoshop jokes?<br></div><div>Moreover, not everything to be desig=
ned is UI (esp. for end-users), for example, a mathematical definition or a=
n API.<br>You are definitely not talking about the UI properly.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>In this case, one piece of language design has se=
nt thousands of programmers down the garden path.=C2=A0 That is bad design.=
=C2=A0 The "opportunity" that compilers are taking advantage of i=
s illusory - it leads them to create translated programs that do not do wha=
t the authors of the original programs want them to do.=C2=A0 When the prob=
lem is discovered, the original programs need to be rewritten so that the &=
quot;opportunity" goes away.</div></div></div></div></blockquote><div>=
Those programmers are not expected to be users. You show no evidence on &qu=
ot;bad" again.<br>=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" 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/7401863f-3eb2-46ef-bfac-778eb5e954c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7401863f-3eb2-46ef-bfac-778eb5e954c9=
%40isocpp.org</a>.<br />
------=_Part_1286_385082487.1468805659308--
------=_Part_1285_1561329855.1468805659308--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 19:10:11 -0700 (PDT)
Raw View
------=_Part_1364_859435523.1468807811669
Content-Type: multipart/alternative;
boundary="----=_Part_1365_133985053.1468807811669"
------=_Part_1365_133985053.1468807811669
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8810:32:20=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 9:42 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> First, you *have* got a way to fix evaluation long ago. Even without=20
>> statements, with some monadic tricks, f1(f2(f3(...))) *can *enforce the=
=20
>> order, just with a weird syntax in traditional ALGOL/C guys' view.
>>
>
> No. My goal is not to find a way to express fixed order of evaluation. =
=20
> My goal is to have all expressions have fixed order of evaluation, becaus=
e=20
> we know from experience that having unspecified order leads to latent=20
> errors. I want that fixed order to be strict left-to-right because that =
is=20
> the easiest order to learn and remember, and matches the order in which=
=20
> code is written and read.
> =20
>
That's a wrong way because in general a programming language should support=
=20
users to do what they want to express, but not to forbid or limit what they=
=20
clearly to do without giving sufficient general features. Even providing=20
guarantees about fixed order evaluation *is *an aspect of expressiveness.=
=20
(Here, unsequenced evaluation is strictly more universal than sequenced=20
ones.) But you have a bad design that it conflicts to normal cases when=20
users does not care that assumption.
=20
> So actually you are disappointing with another problem. You want to forbi=
d=20
>> others to use unsequenced evaluation (at least, by default) but they don=
't=20
>> agree with you. And why?
>>
>
> The only "other" who wants to express unsequenced evaluation in C++=20
> appears to be you. Can you, for example, point to a C++ textbook which=
=20
> explains to its readers how to deliberately express such a thing, as=20
> opposed to warning them on how to avoid it? It should not be the case th=
at=20
> the language design privileges an obscure ability used by no programmers=
=20
> (with probability 1) when it leads to many programmers introducing latent=
=20
> errors into their code. That's why.
> =20
>
No. First, everyone *are *expressing unsequenced evaluation when they don't=
=20
depend on the specific order. Only you here are distorting the intents.=20
Second, who wants sequenced evaluation *should *use the provided language=
=20
features properly. I don't think a textbook not explaining how to uses=20
"statements" and "function arguments" are needed to be talked about here.=
=20
Why you need to warn a person who even does not know how to express the=20
order? They are not expected to use the language.
Second, as said, to choose the order solely by compiler is often very=20
>> difficult, if not impossible. The compiler is forced to prove the=20
>> equivalence between the program semantics before and after transformatio=
n=20
>> without explicit unsequenced evaluation guarantee. In practice, this has=
=20
>> almost the same effect to forbid such optimization.
>>
>
> No one (with probability 1) cares. I understand you feel that specifying=
=20
> unsequenced behavior is important. I am trying to tell you, over and ove=
r=20
> again, that it isn't important to anyone else (with probability 1). No=
=20
> programmer (with probability 1) sits down and thinks "how do I tell the=
=20
> compiler to evaluate these subexpressions in arbitrary order".
>
> I am trying to tell you, over and over again, more than one people here=
=20
*do* care, even not all of them claim there should be an new explicit=20
syntax to support it.
=20
> If you still think this don't make sense, consider similar cases:
>>
>> - Why bother to specify the special cases cannot handled by the as-if=
=20
>> rules (e.g. copy elision and merging operator new calls)?
>> =20
>> Merging operator new calls is a bad idea too. Requiring copy elision=20
> helps when returning objects that use custom allocators.
>
Why your idea diverges here? Copy elision has nothing to do with using=20
custom allocators and it is still unspecified behavior before new mandating=
=20
proposal is approved.=20
>
>> - Why not just use GC everywhere and believe compiler will insert=20
>> destructor/finalizer calls appropriately?
>>
>> GC is one aspect of resource handling; the RAII paradigm unifies all=20
> resource handling. What does "compiler will insert calls appropriately"=
=20
> mean, and why is that a bad thing? The compiler currently expends a grea=
t=20
> deal of effort to insert appropriate destructor calls for stack unwinding=
=20
> during exception handling, for example. Experience shows as well that GC=
=20
> does not relieve programmers from the problem of resource control over=20
> memory. See Java References: From Strong to Soft to Weak to Phantom=20
> <https://www.rallydev.com/blog/engineering/java-references-strong-soft-we=
ak-phantom>, for=20
> example.
>
It is true that GC is not just the easy way to manage the resources in=20
general, but many people still seem to believe it should be the default=20
fallback and treat lacking of GC a proof of bad design of the language.=20
Actually GC is a special case of object pool and it can only handle very=20
specific kinds of resources in very specific cases well (mostly just=20
because it does not "relieve programmers from the problem of resource=20
control" when the programmer know better than a GC about how to manage the=
=20
resources), so it should be not mandated in the default configuration of a=
=20
general-purposed language, otherwise it will harm the availability in many=
=20
cases significantly.
Yes, C++ compiler do insert destructor calls when needed, in a *determinist=
ic=20
*way. You can predict where the insertions are, as long as you have the=20
source code. You can make the calls as no-op by making the definition=20
trivial. But some people think inserting destructor calls by compilers are=
=20
bad but nondeterministic finalizer calls are acceptable, and I don't know=
=20
their reasons.
=20
>
>> - Why allow undefined behavior?
>>
>> Indeed. Undefined behavior is a curse on the language and should be=20
> eliminated wherever possible.
> =20
>
>> Most code relying on an explicit order without is already broken before=
=20
>> the rules are settled.
>>
>
> That's the point. That's why the language needs explicit order. It's=20
> because code is broken silently. It appears to work because the platform=
=20
> on which it is built matches the programmer's expectation, and will break=
=20
> when built on another platform
> =20
>
>> If you want to have multiple side effects, you *should *care the=20
>> evaluation order related to side effects.
>>
>
> Yes. And that means that there should be such an order.
> =20
>
>> Hymans is wrong because he assumes this order is always the same with=20
>> lexical order, which is not true in general - the language or the machin=
e=20
>> just does not work in that way without fixed order rules enforced=20
>> artificially.
>>
>
> I do not "assume" that this is the order, I *want* this to be the order. =
=20
> And "artificially"? I wasn't aware that programming languages are in any=
=20
> way natural. Programming languages are intelligently (sometimes) designe=
d=20
> artifacts. Whether or not they define evaluation order is a choice made =
by=20
> the designer. Neither choice is "natural". Some choices are merely=20
> longstanding.
>
> And since the rules were not there, you should not depend on those rules=
=20
>> in analysis the necessity of the fixed order, otherwise it is somehow=20
>> circular justification. Without such rules, the expressions are confusin=
g.=20
>> So they are already broken.
>>
>
> Again: the necessity for fixed order is that programmers accidentally=20
> write code that depends on a fixed order without realizing that they have=
=20
> done so, and their code works because their platform's order of evaluatio=
n=20
> matches what they want. But since that order is not required, this is a=
=20
> latent error that may manifest years later when the program is built on a=
=20
> different platform.
>
> As of safety and security, I think you ignored an important fact. If a=20
>> program *behaves *normally, it is not naturally guaranteed to behave=20
>> normally forever. To make it safe and secure, you should take actions *b=
efore=20
>> it runs*. Think twice: why people are scared by undefined behavior? As=
=20
>> I've said, fixing the order is not safe and secure. It evens make the=20
>> effort less effective: it may hide bugs which cannot easily be checked b=
y=20
>> machines (i.e. most people may be lazy and ignore them until there is=20
>> strange behavior), cause more unsafe and insecure code in nature.
>>
>
> This is backwards and wrong. When the language has unspecified and=20
> undefined behavior, this means that translated programs can work in a=20
> variety of ways, some of which may be contrary to the intentions of the=
=20
> programmer who did not realize that such behavior was allowed. When a=20
> programmer is dealing only with specified and defined behavior, then the=
=20
> program will indeed work normally forever; a change in platform cannot=20
> change the behavior of the program.
>
> Undefined behavior is bad. Unspecified behavior is bad.
>
--=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/6e3de4d9-b617-49a6-aaa2-2819a4b0bd5e%40isocpp.or=
g.
------=_Part_1365_133985053.1468807811669
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8810:32:20=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 9:42 =
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"H5zyX52XCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>First, you <i>have</i> got a way to fi=
x evaluation long ago. Even without statements, with some monadic tricks, f=
1(f2(f3(...))) <i>can </i>enforce the order, just with a weird syntax in tr=
aditional ALGOL/C guys' view.<br></div></div></blockquote><div><br></di=
v><div>No.=C2=A0 My goal is not to find a way to express fixed order of eva=
luation.=C2=A0 My goal is to have all expressions have fixed order of evalu=
ation, because we know from experience that having unspecified order leads =
to latent errors.=C2=A0 I want that fixed order to be strict left-to-right =
because that is the easiest order to learn and remember, and matches the or=
der in which code is written and read.</div><div>=C2=A0<br></div></div></di=
v></div></blockquote><div>That's a wrong way because in general a progr=
amming language should support users to do what they want to express, but n=
ot to forbid or limit what they clearly to do without giving sufficient gen=
eral features. Even providing guarantees about fixed order evaluation <i>is=
</i>an aspect of expressiveness. (Here, unsequenced evaluation is strictly=
more universal than sequenced ones.) But you have a bad design that it con=
flicts to normal cases when users does not care that assumption.<br>=C2=A0<=
br></div><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 class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>So actually you are disappointing with another problem. You want to forb=
id others to use unsequenced evaluation (at least, by default) but they don=
't agree with you. And why?<br></div></div></blockquote><div><br></div>=
<div>The only "other" who wants to express unsequenced evaluation=
in C++ appears to be you.=C2=A0 Can you, for example, point to a C++ textb=
ook which explains to its readers how to deliberately express such a thing,=
as opposed to warning them on how to avoid it?=C2=A0 It should not be the =
case that the language design privileges an obscure ability used by no prog=
rammers (with probability 1) when it leads to many programmers introducing =
latent errors into their code.=C2=A0 That's why.</div><div>=C2=A0<br></=
div></div></div></div></blockquote><div>No. First, everyone <i>are </i>expr=
essing unsequenced evaluation when they don't depend on the specific or=
der. Only you here are distorting the intents. Second, who wants sequenced =
evaluation <i>should </i>use the provided language features properly. I don=
't think a textbook not explaining how to uses "statements" a=
nd "function arguments" are needed to be talked about here. Why y=
ou need to warn a person who even does not know how to express the order? T=
hey are not expected to use the language.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div>Second, as said, to choose=
the order solely by compiler is often very difficult, if not impossible. T=
he compiler is forced to prove the equivalence between the program semantic=
s before and after transformation without explicit unsequenced evaluation g=
uarantee. In practice, this has almost the same effect to forbid such optim=
ization.</div></div></blockquote><div><br></div><div>No one (with probabili=
ty 1) cares.=C2=A0 I understand you feel that specifying unsequenced behavi=
or is important.=C2=A0 I am trying to tell you, over and over again, that i=
t isn't important to anyone else (with probability 1).=C2=A0 No program=
mer (with probability 1) sits down and thinks "how do I tell the compi=
ler to evaluate these subexpressions in arbitrary order".</div><div><b=
r></div></div></div></div></blockquote><div>I am trying to tell you, over a=
nd over again, more than one people here <i>do</i> care, even not all of th=
em claim there should be an new explicit syntax to support it.<br>=C2=A0<br=
></div><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 class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
> If you still think this don't make sense, consider similar cases:<br>=
<ul><li>Why bother to specify the special cases cannot handled by the as-if=
rules (e.g. copy elision and merging operator new calls)?<br></li></ul></d=
iv></div></blockquote><div>Merging operator new calls is a bad idea too.=C2=
=A0 Requiring copy elision helps when returning objects that use custom all=
ocators.</div></div></div></div></blockquote><div>Why your idea diverges he=
re? Copy elision has nothing to do with using custom allocators and it is s=
till unspecified behavior before new mandating proposal is approved. <br></=
div><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=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Why n=
ot just use GC everywhere and believe compiler will insert destructor/final=
izer calls appropriately?</li></ul></div></div></blockquote><div>GC is one =
aspect of resource handling; the RAII paradigm unifies all resource handlin=
g.=C2=A0 What does "compiler will insert calls appropriately" mea=
n, and why is that a bad thing?=C2=A0 The compiler currently expends a grea=
t deal of effort to insert appropriate destructor calls for stack unwinding=
during exception handling, for example.=C2=A0 Experience shows as well tha=
t GC does not relieve programmers from the problem of resource control over=
memory.=C2=A0 See=C2=A0<a href=3D"https://www.rallydev.com/blog/engineerin=
g/java-references-strong-soft-weak-phantom" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3=
A%2F%2Fwww.rallydev.com%2Fblog%2Fengineering%2Fjava-references-strong-soft-=
weak-phantom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFIIBL4qwN4n68X4WUp7Zb=
NjIiyw';return true;" onclick=3D"this.href=3D'https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fwww.rallydev.com%2Fblog%2Fengineering%2Fjava-refer=
ences-strong-soft-weak-phantom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFII=
BL4qwN4n68X4WUp7ZbNjIiyw';return true;">Java References: From Strong to=
Soft to Weak to Phantom</a>,=C2=A0for example.<br></div></div></div></div>=
</blockquote><div>It is true that GC is not just the easy way to manage the=
resources in general, but many people still seem to believe it should be t=
he default fallback and treat lacking of GC a proof of bad design of the la=
nguage. Actually GC is a special case of object pool and it can only handle=
very specific kinds of resources in very specific cases well (mostly just =
because it does not "relieve programmers from the problem of resource =
control" when the programmer know better than a GC about how to manage=
the resources), so it should be not mandated in the default configuration =
of a general-purposed language, otherwise it will harm the availability in =
many cases significantly.<br>Yes, C++ compiler do insert destructor calls w=
hen needed, in a <i>deterministic </i>way. You can predict where the insert=
ions are, as long as you have the source code. You can make the calls as no=
-op by making the definition trivial. But some people think inserting destr=
uctor calls by compilers are bad but nondeterministic finalizer calls are a=
cceptable, and I don't know their reasons.<br><br>=C2=A0<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Why=
allow undefined behavior?</li></ul></div></div></blockquote><div>Indeed.=
=C2=A0 Undefined behavior is a curse on the language and should be eliminat=
ed wherever possible.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>Most code relying on an explicit order without is already broken before th=
e rules are settled.</div></div></blockquote><div><br></div><div>That's=
the point.=C2=A0 That's why the language needs explicit order.=C2=A0 I=
t's because code is broken silently.=C2=A0 It appears to work because t=
he platform on which it is built matches the programmer's expectation, =
and will break when built on another platform</div><div>=C2=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div> If you want to have multiple side effe=
cts, you <i>should </i>care the evaluation order related to side effects.</=
div></div></blockquote><div><br></div><div>Yes.=C2=A0 And that means that t=
here should be such an order.</div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div> Hymans is wrong because he assumes this order is alw=
ays the same with lexical order, which is not true in general - the languag=
e or the machine just does not work in that way without fixed order rules e=
nforced artificially.</div></div></blockquote><div><br></div><div>I do not =
"assume" that this is the order, I *want* this to be the order.=
=C2=A0 And "artificially"?=C2=A0 I wasn't aware that programm=
ing languages are in any way natural.=C2=A0 Programming languages are intel=
ligently (sometimes) designed artifacts.=C2=A0 Whether or not they define e=
valuation order is a choice made by the designer.=C2=A0 Neither choice is &=
quot;natural".=C2=A0 Some choices are merely longstanding.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div> And since the rules were n=
ot there, you should not depend on those rules in analysis the necessity of=
the fixed order, otherwise it is somehow circular justification. Without s=
uch rules, the expressions are confusing. So they are already broken.<br></=
div></div></blockquote><div><br></div><div>Again: the necessity for fixed o=
rder is that programmers accidentally write code that depends on a fixed or=
der without realizing that they have done so, and their code works because =
their platform's order of evaluation matches what they want.=C2=A0 But =
since that order is not required, this is a latent error that may manifest =
years later when the program is built on a different platform.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>As of safety and security, I=
think you ignored an important fact. If a program <i>behaves </i>normally,=
it is not naturally guaranteed to behave normally forever. To make it safe=
and secure, you should take actions <i>before it runs</i>. Think twice: wh=
y people are scared by undefined behavior? As I've said, fixing the ord=
er is not safe and secure. It evens make the effort less effective: it may =
hide bugs which cannot easily be checked by machines (i.e. most people may =
be lazy and ignore them until there is strange behavior), cause more unsafe=
and insecure code in nature.</div></div></blockquote><div><br></div><div>T=
his is backwards and wrong.=C2=A0 When the language has unspecified and und=
efined behavior, this means that translated programs can work in a variety =
of ways, some of which may be contrary to the intentions of the programmer =
who did not realize that such behavior was allowed.=C2=A0 When a programmer=
is dealing only with specified and defined behavior, then the program will=
indeed work normally forever; a change in platform cannot change the behav=
ior of the program.</div><div><br></div><div>Undefined behavior is bad.=C2=
=A0 Unspecified behavior is bad.</div></div></div></div>
</blockquote></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/6e3de4d9-b617-49a6-aaa2-2819a4b0bd5e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6e3de4d9-b617-49a6-aaa2-2819a4b0bd5e=
%40isocpp.org</a>.<br />
------=_Part_1365_133985053.1468807811669--
------=_Part_1364_859435523.1468807811669--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 19:45:48 -0700 (PDT)
Raw View
------=_Part_1282_1312139698.1468809948962
Content-Type: multipart/alternative;
boundary="----=_Part_1283_1343019637.1468809948963"
------=_Part_1283_1343019637.1468809948963
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8810:32:20=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 9:42 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> First, you *have* got a way to fix evaluation long ago. Even without=20
>> statements, with some monadic tricks, f1(f2(f3(...))) *can *enforce the=
=20
>> order, just with a weird syntax in traditional ALGOL/C guys' view.
>>
>
> No. My goal is not to find a way to express fixed order of evaluation. =
=20
> My goal is to have all expressions have fixed order of evaluation, becaus=
e=20
> we know from experience that having unspecified order leads to latent=20
> errors. I want that fixed order to be strict left-to-right because that =
is=20
> the easiest order to learn and remember, and matches the order in which=
=20
> code is written and read.
> =20
>
>> So actually you are disappointing with another problem. You want to=20
>> forbid others to use unsequenced evaluation (at least, by default) but t=
hey=20
>> don't agree with you. And why?
>>
>
> The only "other" who wants to express unsequenced evaluation in C++=20
> appears to be you. Can you, for example, point to a C++ textbook which=
=20
> explains to its readers how to deliberately express such a thing, as=20
> opposed to warning them on how to avoid it? It should not be the case th=
at=20
> the language design privileges an obscure ability used by no programmers=
=20
> (with probability 1) when it leads to many programmers introducing latent=
=20
> errors into their code. That's why.
> =20
>
>> Second, as said, to choose the order solely by compiler is often very=20
>> difficult, if not impossible. The compiler is forced to prove the=20
>> equivalence between the program semantics before and after transformatio=
n=20
>> without explicit unsequenced evaluation guarantee. In practice, this has=
=20
>> almost the same effect to forbid such optimization.
>>
>
> No one (with probability 1) cares. I understand you feel that specifying=
=20
> unsequenced behavior is important. I am trying to tell you, over and ove=
r=20
> again, that it isn't important to anyone else (with probability 1). No=
=20
> programmer (with probability 1) sits down and thinks "how do I tell the=
=20
> compiler to evaluate these subexpressions in arbitrary order".
>
> If you still think this don't make sense, consider similar cases:
>>
>> - Why bother to specify the special cases cannot handled by the as-if=
=20
>> rules (e.g. copy elision and merging operator new calls)?
>> =20
>> Merging operator new calls is a bad idea too. Requiring copy elision=20
> helps when returning objects that use custom allocators.
>
>>
>> - Why not just use GC everywhere and believe compiler will insert=20
>> destructor/finalizer calls appropriately?
>>
>> GC is one aspect of resource handling; the RAII paradigm unifies all=20
> resource handling. What does "compiler will insert calls appropriately"=
=20
> mean, and why is that a bad thing? The compiler currently expends a grea=
t=20
> deal of effort to insert appropriate destructor calls for stack unwinding=
=20
> during exception handling, for example. Experience shows as well that GC=
=20
> does not relieve programmers from the problem of resource control over=20
> memory. See Java References: From Strong to Soft to Weak to Phantom=20
> <https://www.rallydev.com/blog/engineering/java-references-strong-soft-we=
ak-phantom>, for=20
> example.
>
>>
>> - Why allow undefined behavior?
>>
>> Indeed. Undefined behavior is a curse on the language and should be=20
> eliminated wherever possible.
> =20
>
No. They can't be avoid in such a language. Undefined behavior is a way to=
=20
keep balance between portability and extensiblility with almost lowest cost=
..
It should be noted that even now there is a SG to reduce undefined=20
behavior, not all undefined behavior is to be eliminate.
=20
> Most code relying on an explicit order without is already broken before=
=20
>> the rules are settled.
>>
>
> That's the point. That's why the language needs explicit order. It's=20
> because code is broken silently. It appears to work because the platform=
=20
> on which it is built matches the programmer's expectation, and will break=
=20
> when built on another platform
> =20
>
But this does not require the rules in the language specification. A=20
powerful implementation extension (e.g. ubsan) is sufficient to detect such=
=20
misuses. It can be expected to be easier and cheaper than to observe what=
=20
behavior is extended.
=20
> If you want to have multiple side effects, you *should *care the=20
>> evaluation order related to side effects.
>>
>
> Yes. And that means that there should be such an order.
>
No, it means that the author of the code should know what order he/she=20
needs, not necessarily left-to-right. Unsequenced evaluation is also a=20
choice.=20
> =20
>
>> Hymans is wrong because he assumes this order is always the same with=20
>> lexical order, which is not true in general - the language or the machin=
e=20
>> just does not work in that way without fixed order rules enforced=20
>> artificially.
>>
>
> I do not "assume" that this is the order, I *want* this to be the order. =
=20
> And "artificially"? I wasn't aware that programming languages are in any=
=20
> way natural. Programming languages are intelligently (sometimes) designe=
d=20
> artifacts. Whether or not they define evaluation order is a choice made =
by=20
> the designer. Neither choice is "natural". Some choices are merely=20
> longstanding.
>
You want this to be the order because you think there should be only that=
=20
order. This is the assumption.
It is true that programming language are artificial. But not all rules of=
=20
the languages are artificially introduced by accidental design choices.=20
There often exist the need behind the design and in many cases you have=20
only one choice that can be most "natural". Omitting rules may be not=20
natural at all. However, in an artificial system, defining *sufficient but=
=20
less rules* is more natural in general.
In view of system complexity, one aspect to measure "sufficient" is=20
dependencies out of the design, or *assumptions*. The less assumptions are=
=20
depended on, the easier the system is. This may not lead to a total order,=
=20
but it can have some results to compare which design is better locally=20
based on partial order. In the case here, the left-to-right rule is not=20
indisputably one of the necessary rules. Without introducing some more=20
assumption not existed in the original design, neither left-to-right or=20
right-to-left is more natural than other, but unsequenced evaluation is=20
more natural than both of them just because it consumes no more assumptions=
..
Also note natural languages are not naturally designed either, because the=
=20
mostly has no design at all.
=20
>
> And since the rules were not there, you should not depend on those rules=
=20
>> in analysis the necessity of the fixed order, otherwise it is somehow=20
>> circular justification. Without such rules, the expressions are confusin=
g.=20
>> So they are already broken.
>>
>
> Again: the necessity for fixed order is that programmers accidentally=20
> write code that depends on a fixed order without realizing that they have=
=20
> done so, and their code works because their platform's order of evaluatio=
n=20
> matches what they want. But since that order is not required, this is a=
=20
> latent error that may manifest years later when the program is built on a=
=20
> different platform.
>
> Again: this need no change on the language specification.=20
> As of safety and security, I think you ignored an important fact. If a=20
>> program *behaves *normally, it is not naturally guaranteed to behave=20
>> normally forever. To make it safe and secure, you should take actions *b=
efore=20
>> it runs*. Think twice: why people are scared by undefined behavior? As=
=20
>> I've said, fixing the order is not safe and secure. It evens make the=20
>> effort less effective: it may hide bugs which cannot easily be checked b=
y=20
>> machines (i.e. most people may be lazy and ignore them until there is=20
>> strange behavior), cause more unsafe and insecure code in nature.
>>
>
> This is backwards and wrong. When the language has unspecified and=20
> undefined behavior, this means that translated programs can work in a=20
> variety of ways, some of which may be contrary to the intentions of the=
=20
> programmer who did not realize that such behavior was allowed. When a=20
> programmer is dealing only with specified and defined behavior, then the=
=20
> program will indeed work normally forever; a change in platform cannot=20
> change the behavior of the program.
>
> Again: you are not required to only depend on the language specification.=
=20
More importantly, there is no practical implementation can have totally=20
defined behavior unless you give the whole formal description of the=20
system, make every exceptional condition defined and then prove them in a=
=20
strict formal method. This is impossible because you can't reverse engineer=
=20
any current implementation (including hardware) successfully.
=20
> Undefined behavior is bad. Unspecified behavior is bad.
>
The latter seems to contradict to your attitude to copy elision (which will=
=20
determine when to eliminate the copy in a "unspecified" way) and allowing=
=20
mandated GC (which will collecting the resource at "unspecified" point).
=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/063160cd-0371-412f-a845-14647154b673%40isocpp.or=
g.
------=_Part_1283_1343019637.1468809948963
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8810:32:20=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 9:42 =
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"H5zyX52XCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>First, you <i>have</i> got a way to fi=
x evaluation long ago. Even without statements, with some monadic tricks, f=
1(f2(f3(...))) <i>can </i>enforce the order, just with a weird syntax in tr=
aditional ALGOL/C guys' view.<br></div></div></blockquote><div><br></di=
v><div>No.=C2=A0 My goal is not to find a way to express fixed order of eva=
luation.=C2=A0 My goal is to have all expressions have fixed order of evalu=
ation, because we know from experience that having unspecified order leads =
to latent errors.=C2=A0 I want that fixed order to be strict left-to-right =
because that is the easiest order to learn and remember, and matches the or=
der in which code is written and read.</div><div>=C2=A0<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div>So actually you are disappointing with another=
problem. You want to forbid others to use unsequenced evaluation (at least=
, by default) but they don't agree with you. And why?<br></div></div></=
blockquote><div><br></div><div>The only "other" who wants to expr=
ess unsequenced evaluation in C++ appears to be you.=C2=A0 Can you, for exa=
mple, point to a C++ textbook which explains to its readers how to delibera=
tely express such a thing, as opposed to warning them on how to avoid it?=
=C2=A0 It should not be the case that the language design privileges an obs=
cure ability used by no programmers (with probability 1) when it leads to m=
any programmers introducing latent errors into their code.=C2=A0 That's=
why.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Seco=
nd, as said, to choose the order solely by compiler is often very difficult=
, if not impossible. The compiler is forced to prove the equivalence betwee=
n the program semantics before and after transformation without explicit un=
sequenced evaluation guarantee. In practice, this has almost the same effec=
t to forbid such optimization.</div></div></blockquote><div><br></div><div>=
No one (with probability 1) cares.=C2=A0 I understand you feel that specify=
ing unsequenced behavior is important.=C2=A0 I am trying to tell you, over =
and over again, that it isn't important to anyone else (with probabilit=
y 1).=C2=A0 No programmer (with probability 1) sits down and thinks "h=
ow do I tell the compiler to evaluate these subexpressions in arbitrary ord=
er".</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border=
-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> If yo=
u still think this don't make sense, consider similar cases:<br><ul><li=
>Why bother to specify the special cases cannot handled by the as-if rules =
(e.g. copy elision and merging operator new calls)?<br></li></ul></div></di=
v></blockquote><div>Merging operator new calls is a bad idea too.=C2=A0 Req=
uiring copy elision helps when returning objects that use custom allocators=
..</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Why not just use GC e=
verywhere and believe compiler will insert destructor/finalizer calls appro=
priately?</li></ul></div></div></blockquote><div>GC is one aspect of resour=
ce handling; the RAII paradigm unifies all resource handling.=C2=A0 What do=
es "compiler will insert calls appropriately" mean, and why is th=
at a bad thing?=C2=A0 The compiler currently expends a great deal of effort=
to insert appropriate destructor calls for stack unwinding during exceptio=
n handling, for example.=C2=A0 Experience shows as well that GC does not re=
lieve programmers from the problem of resource control over memory.=C2=A0 S=
ee=C2=A0<a href=3D"https://www.rallydev.com/blog/engineering/java-reference=
s-strong-soft-weak-phantom" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.rall=
ydev.com%2Fblog%2Fengineering%2Fjava-references-strong-soft-weak-phantom\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFIIBL4qwN4n68X4WUp7ZbNjIiyw';ret=
urn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttp=
s%3A%2F%2Fwww.rallydev.com%2Fblog%2Fengineering%2Fjava-references-strong-so=
ft-weak-phantom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFIIBL4qwN4n68X4WUp=
7ZbNjIiyw';return true;">Java References: From Strong to Soft to Weak t=
o Phantom</a>,=C2=A0for example.<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div><ul><li>Why allow undefined behavior?</li></ul></div></div></blockquo=
te><div>Indeed.=C2=A0 Undefined behavior is a curse on the language and sho=
uld be eliminated wherever possible.<br>=C2=A0</div></div></div></div></blo=
ckquote><div>No. They can't be avoid in such a language. Undefined beha=
vior is a way to keep balance between portability and extensiblility with a=
lmost lowest cost.<br><br>It should be noted that even now there is a SG to=
reduce undefined behavior, not all undefined behavior is to be eliminate.<=
br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>Most code relying on an explicit order without is already broken before t=
he rules are settled.</div></div></blockquote><div><br></div><div>That'=
s the point.=C2=A0 That's why the language needs explicit order.=C2=A0 =
It's because code is broken silently.=C2=A0 It appears to work because =
the platform on which it is built matches the programmer's expectation,=
and will break when built on another platform</div><div>=C2=A0<br></div></=
div></div></div></blockquote><div>But this does not require the rules in th=
e language specification. A powerful implementation extension (e.g. ubsan) =
is sufficient to detect such misuses. It can be expected to be easier and c=
heaper than to observe what behavior is extended.<br>=C2=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> If you want=
to have multiple side effects, you <i>should </i>care the evaluation order=
related to side effects.</div></div></blockquote><div><br></div><div>Yes.=
=C2=A0 And that means that there should be such an order.</div></div></div>=
</div></blockquote><div>No, it means that the author of the code should kno=
w what order he/she needs, not necessarily left-to-right. Unsequenced evalu=
ation is also a choice. <br></div><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 class=3D"gmail_quote"><div>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div> Hymans is wrong because he assumes=
this order is always the same with lexical order, which is not true in gen=
eral - the language or the machine just does not work in that way without f=
ixed order rules enforced artificially.</div></div></blockquote><div><br></=
div><div>I do not "assume" that this is the order, I *want* this =
to be the order.=C2=A0 And "artificially"?=C2=A0 I wasn't awa=
re that programming languages are in any way natural.=C2=A0 Programming lan=
guages are intelligently (sometimes) designed artifacts.=C2=A0 Whether or n=
ot they define evaluation order is a choice made by the designer.=C2=A0 Nei=
ther choice is "natural".=C2=A0 Some choices are merely longstand=
ing.</div></div></div></div></blockquote><div>You want this to be the order=
because you think there should be only that order. This is the assumption.=
<br>It is true that programming language are artificial. But not all rules =
of the languages are artificially introduced by accidental design choices. =
There often exist the need behind the design and in many cases you have onl=
y one choice that can be most "natural". Omitting rules may be no=
t natural at all. However, in an artificial system, defining <i>sufficient =
but less rules</i> is more natural in general.<br>In view of system complex=
ity, one aspect to measure "sufficient" is dependencies out of th=
e design, or <i>assumptions</i>. The less assumptions are depended on, the =
easier the system is. This may not lead to a total order, but it can have s=
ome results to compare which design is better locally based on partial orde=
r. In the case here, the left-to-right rule is not indisputably one of the =
necessary rules. Without introducing some more assumption not existed in th=
e original design, neither left-to-right or right-to-left is more natural t=
han other, but unsequenced evaluation is more natural than both of them jus=
t because it consumes no more assumptions.<br>Also note natural languages a=
re not naturally designed either, because the mostly has no design at all.<=
br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div> And since the rules were not there, you should not depend=
on those rules in analysis the necessity of the fixed order, otherwise it =
is somehow circular justification. Without such rules, the expressions are =
confusing. So they are already broken.<br></div></div></blockquote><div><br=
></div><div>Again: the necessity for fixed order is that programmers accide=
ntally write code that depends on a fixed order without realizing that they=
have done so, and their code works because their platform's order of e=
valuation matches what they want.=C2=A0 But since that order is not require=
d, this is a latent error that may manifest years later when the program is=
built on a different platform.</div><div><br></div></div></div></div></blo=
ckquote><div>Again: this need no change on the language specification. <br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
As of safety and security, I think you ignored an important fact. If a prog=
ram <i>behaves </i>normally, it is not naturally guaranteed to behave norma=
lly forever. To make it safe and secure, you should take actions <i>before =
it runs</i>. Think twice: why people are scared by undefined behavior? As I=
've said, fixing the order is not safe and secure. It evens make the ef=
fort less effective: it may hide bugs which cannot easily be checked by mac=
hines (i.e. most people may be lazy and ignore them until there is strange =
behavior), cause more unsafe and insecure code in nature.</div></div></bloc=
kquote><div><br></div><div>This is backwards and wrong.=C2=A0 When the lang=
uage has unspecified and undefined behavior, this means that translated pro=
grams can work in a variety of ways, some of which may be contrary to the i=
ntentions of the programmer who did not realize that such behavior was allo=
wed.=C2=A0 When a programmer is dealing only with specified and defined beh=
avior, then the program will indeed work normally forever; a change in plat=
form cannot change the behavior of the program.</div><div><br></div></div><=
/div></div></blockquote><div>Again: you are not required to only depend on =
the language specification. More importantly, there is no practical impleme=
ntation can have totally defined behavior unless you give the whole formal =
description of the system, make every exceptional condition defined and the=
n prove them in a strict formal method. This is impossible because you can&=
#39;t reverse engineer any current implementation (including hardware) succ=
essfully.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>Undefined b=
ehavior is bad.=C2=A0 Unspecified behavior is bad.</div></div></div></div><=
/blockquote><div>The latter seems to contradict to your attitude to copy el=
ision (which will determine when to eliminate the copy in a "unspecifi=
ed" way) and allowing mandated GC (which will collecting the resource =
at "unspecified" point).<br>=C2=A0<br></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/063160cd-0371-412f-a845-14647154b673%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/063160cd-0371-412f-a845-14647154b673=
%40isocpp.org</a>.<br />
------=_Part_1283_1343019637.1468809948963--
------=_Part_1282_1312139698.1468809948962--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 20:03:02 -0700 (PDT)
Raw View
------=_Part_797_1804899027.1468810982215
Content-Type: multipart/alternative;
boundary="----=_Part_798_119077515.1468810982216"
------=_Part_798_119077515.1468810982216
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8810:53:41=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jul 14, 2016 at 10:22 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> There are difficulties to make "left-to-right" clear in C++. You can see=
=20
>> P0145R2 has *many *words to be inserted to the draft.
>>
>
> Nonsense. The canonical insert is like the one for the shift operator - =
a=20
> single sentence, "The expression E1 is sequenced before the expression E2=
.."=20
> Since this should be true for all binary operators, it could potentially=
=20
> be lifted into the beginning of chapter 5.
>
> A don't see how it is canonical. Citation needed.
Anyway, this is the problem of this proposal. And your idea is not fit to=
=20
the authors of this proposal.
=20
> Some of the excess verbiage is because the decisions made in P0145R2 are=
=20
> wrong. It should not need to say that the order of evaluation of operand=
s=20
> to a binary operator implemented as an overloaded function matches the=20
> order for the native operator, because the correct order is left-to-right=
=20
> for both. The error of making assignment right-to-left and leaving=20
> argument evaluation order unspecified leads to the necessity for this=20
> wording.
>
> On the contrary, I think *everyone* *should *think about it, whether=20
>> deciding to actually embedded it in the code or not. Side effects, in=20
>> traditional view of theoretical computer science, are monsters. Careless=
=20
>> use of side effects (including ignorant of which order is really needed)=
=20
>> are essential bugs (which are difficult to be checked by machines), even=
it=20
>> does not produce a program with unexpected behavior occasionally. To mak=
e=20
>> (esp. uneducated noob) programmers too easy to forget their danger is no=
t a=20
>> good thing sounds to me. As an end-user, I don't want to rely on program=
s=20
>> with such potential risks as possible. So I believe that it is wrong to=
=20
>> make it as the default cases, at least of a serious general-purposed=20
>> language (rather than some configurable DSL).
>>
>> So that is pure value judgment conflict. I think we are already clear=20
>> about it.
>>
>
> Again, the problem is that programmers accidentally rely on order of side=
=20
> effects without realizing they have done so, and do not realize their err=
or=20
> because their platform matches their expectations. It is useless to exho=
rt=20
> people to think about it. It is a fact of human attention that no one is=
=20
> hyper vigilant all the time. (Just think about the sheer number of=20
> incidents where young children die in hot cars because a parent simply=20
> forgets that the child is there.) A language design that requires such=
=20
> hyper vigilance in order to avoid errors is a poor and broken design.
>
Again, this need no change in the language specification practical. And=20
this is not the root reason. Moreover, assuming "left-to-right is only the=
=20
correct order" will make it worse because users have more excuses to avoid=
=20
thinking about the problem. There is no evident to support your idea on=20
human attention. On the contrary, in my experience, for a normal user, to=
=20
remember *not *relying on something should be not that hard, especially it=
=20
should be generally simpler than to trust that relying on something is=20
really intended. Otherwise that should not be served as a normal user, as=
=20
you can't expect a blind person will be safer than a children from the cars=
=20
without extraordinary aids.
=20
>
> Then, once the language has a defined order, depending on that order is=
=20
> not an error, any more than depending on the order of a(); b(); is an=20
> error. Thinking otherwise is a remnant of decades of programming in poor=
ly=20
> specified languages.
>
To depend on that order can still be an error when the order is not needed=
=20
and the code is required to be somehow optimum, like some -Werror options=
=20
of GCC/Clang.
=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/3e0ebd3e-0043-4778-987f-d8de4148d4c0%40isocpp.or=
g.
------=_Part_798_119077515.1468810982216
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8810:53:41=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 10:22=
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"LoKbnseYCwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">frank...@gmail.com</a>></span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>There are difficulties to make &quo=
t;left-to-right" clear in C++. You can see P0145R2 has <i>many </i>wor=
ds to be inserted to the draft.</div></div></blockquote><div><br></div><div=
>Nonsense.=C2=A0 The canonical insert is like the one for the shift operato=
r - a single sentence, "The expression E1 is sequenced before the expr=
ession E2." =C2=A0Since this should be true for all binary operators, =
it could potentially be lifted into the beginning of chapter 5.</div><div><=
br></div></div></div></div></blockquote><div>A don't see how it is cano=
nical. Citation needed.<br>Anyway, this is the problem of this proposal. An=
d your idea is not fit to the authors of this proposal.<br>=C2=A0<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><div></div><div>Some of the excess verbiage is because t=
he decisions made in P0145R2 are wrong.=C2=A0 It should not need to say tha=
t the order of evaluation of operands to a binary operator implemented as a=
n overloaded function matches the order for the native operator, because th=
e correct order is left-to-right for both.=C2=A0 The error of making assign=
ment right-to-left and leaving argument evaluation order unspecified leads =
to the necessity for this wording.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div>On the contrary, I think <i>everyone</i> <i>should </i>t=
hink about it, whether deciding to actually embedded it in the code or not.=
Side effects, in traditional view of theoretical computer science, are mon=
sters. Careless use of side effects (including ignorant of which order is r=
eally needed) are essential bugs (which are difficult to be checked by mach=
ines), even it does not produce a program with unexpected behavior occasion=
ally. To make (esp. uneducated noob) programmers too easy to forget their d=
anger is not a good thing sounds to me. As an end-user, I don't want to=
rely on programs with such potential risks as possible. So I believe that =
it is wrong to make it as the default cases, at least of a serious general-=
purposed language (rather than some configurable DSL).<br><br>So that is pu=
re value judgment conflict. I think we are already clear about it.</div></d=
iv></blockquote><div><br></div><div>Again, the problem is that programmers =
accidentally rely on order of side effects without realizing they have done=
so, and do not realize their error because their platform matches their ex=
pectations.=C2=A0 It is useless to exhort people to think about it.=C2=A0 I=
t is a fact of human attention that no one is hyper vigilant all the time. =
=C2=A0(Just think about the sheer number of incidents where young children =
die in hot cars because a parent simply forgets that the child is there.) =
=C2=A0A language design that requires such hyper vigilance in order to avoi=
d errors is a poor and broken design.<br></div></div></div></div></blockquo=
te><div>Again, this need no change in the language specification practical.=
And this is not the root reason. Moreover, assuming "left-to-right is=
only the correct order" will make it worse because users have more ex=
cuses to avoid thinking about the problem. There is no evident to support y=
our idea on human attention. On the contrary, in my experience, for a norma=
l user, to remember <i>not </i>relying on something should be not that hard=
, especially it should be generally simpler than to trust that relying on s=
omething is really intended. Otherwise that should not be served as a norma=
l user, as you can't expect a blind person will be safer than a childre=
n from the cars without extraordinary aids.<br>=C2=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div><br>Then, once the language has a defined order, depending on t=
hat order is not an error, any more than depending on the order of <font fa=
ce=3D"monospace, monospace">a(); b();</font> is an error.=C2=A0 Thinking ot=
herwise is a remnant of decades of programming in poorly specified language=
s.</div></div></div></div></blockquote><div>To depend on that order can sti=
ll be an error when the order is not needed and the code is required to be =
somehow <span class=3D"op_dict3_font24 op_dict3_marginRight">optimum</span>=
, like some -Werror options of GCC/Clang.<br>=C2=A0<br></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/3e0ebd3e-0043-4778-987f-d8de4148d4c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3e0ebd3e-0043-4778-987f-d8de4148d4c0=
%40isocpp.org</a>.<br />
------=_Part_798_119077515.1468810982216--
------=_Part_797_1804899027.1468810982215--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 20:20:24 -0700 (PDT)
Raw View
------=_Part_17_243969970.1468812024716
Content-Type: multipart/alternative;
boundary="----=_Part_18_865036092.1468812024717"
------=_Part_18_865036092.1468812024717
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:12:23=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 2:31 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=8812:01:28=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> C++ is a programming language, used to direct the actions of a=20
>>> computer. It is meaningless to say that a programming language contain=
s=20
>>> constructs that can be "used at one's own risk". That is Stockholm=20
>>> Syndrome and misplaced nerd hubris. If such constructs exist in the=20
>>> language, it means that the language has been poorly specified, so that=
it=20
>>> is easy for programmers to use the constructs incorrectly. The solutio=
n is=20
>>> not to warn the programmers but to fix the language.
>>>
>>> Be practical. You use the language by writing and reading code, if you=
=20
>> does not also write specification to extend the language. There are risk=
s=20
>> of buggy implementations. There are risks of misunderstanding the langua=
ge=20
>> rules. There are risks of typos. Some of them are your responsibilities.=
=20
>> Some of them are others' responsibilities. Everything may be risky, more=
or=20
>> less. Do they all meaningless? How can a user avoid them totally? Or do =
you=20
>> mean every language is poorly specified?
>>
>
> A programming language is a user interface. It is the responsibility of=
=20
> the language designer to make the affordances of the language as clear an=
d=20
> distinct as possible, so that when people are using the language it is ea=
sy=20
> for them to communicate their intentions, and such that it is difficult f=
or=20
> people to accidentally say one thing when they meant another. For exampl=
e,=20
> this is why Fortran's implicitly typed (by their first letter) variables=
=20
> are wrong; by not requiring declarations, a programmer can make a=20
> typographical error and silently access a different variable. This is wh=
y,=20
> in Ada, comparisons are not associative; it is rare that someone who writ=
es a=20
> <=3D b <=3D c in C++ wants the result that is actually computed.
>
> No, if you are talking about end-users of software industrial products an=
d=20
perhaps yes in other cases. But if you are in the latter place, the users=
=20
should not include every end-users. Namely, there are users should not be=
=20
considered as the interface serves to. Once it is clear, the scope of=20
responsibility is limited. I don't think a general purposed language should=
=20
care about persons who can't remember what he/she should not depend on,=20
esp. to care them will potentially reduce others' freedom.
=20
> As Rabbi Tarfon said in Pirkei Avot 2:16=20
> <http://www.chabad.org/library/article_cdo/aid/682513/jewish/English-Text=
..htm>,=20
> "You are not required to complete the work, but neither are you free to=
=20
> desist from it." Or as we also say, "The perfect is the enemy of the=20
> good." Just because language design cannot fix everything is not an excu=
se=20
> to avoid fixing what it can.
>
You still have not proven that is a "fix" convincingly. I have sufficient=
=20
reasons to treat it as pessimation of the design.
=20
>
> Your belief is conflicts to the fact again. There are more than one peopl=
e=20
>> needing expressiveness or opportunity of optimization only can be=20
>> effectively allowed by unsequenced evaluation just in this topic. I beli=
eve=20
>> there are committee members who think the same.
>>
>
> There are people who want to leave order unspecified on the grounds that=
=20
> the compiler can take advantage of that for optimization. I have not see=
n=20
> anyone but you saying that programmers want to visibly express a request=
=20
> for unspecified order in their C++ code.
>
The optimization can be implemented with a relatively small cost because=20
the unspecified order can be expressed, either explicitly or implicitly. If=
=20
the default case is unseqneced, I can easily make a macro to tag sequenced=
=20
evaluated expressions easily as I currently do. Allowing explicitly tagging=
=20
code that being unsequenced evaluated is also a compromise to who thinks it=
=20
is too error-prone as the default case.
--=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/afd3a608-4751-4d54-8cce-946a1cc79354%40isocpp.or=
g.
------=_Part_18_865036092.1468812024717
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:12:23=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:31 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"OWYBBM2ZCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=
=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:01:28=EF=BC=8CHyma=
n Rosen=E5=86=99=E9=81=93=EF=BC=9A<span><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><div>C++ is a programming language, used to =
direct the actions of a computer.=C2=A0 It is meaningless to say that a pro=
gramming language contains constructs that can be "used at one's o=
wn risk".=C2=A0 That is Stockholm Syndrome and misplaced nerd hubris.=
=C2=A0 If such constructs exist in the language, it means that the language=
has been poorly specified, so that it is easy for programmers to use the c=
onstructs incorrectly.=C2=A0 The solution is not to warn the programmers bu=
t to fix the language.<br><br></div></div></div></div></blockquote></span><=
div>Be practical. You use the language by writing and reading code, if you =
does not also write specification to extend the language. There are risks o=
f buggy implementations. There are risks of misunderstanding the language r=
ules. There are risks of typos. Some of them are your responsibilities. Som=
e of them are others' responsibilities. Everything may be risky, more o=
r less. Do they all meaningless? How can a user avoid them totally? Or do y=
ou mean every language is poorly specified?<br></div></div></blockquote><di=
v><br></div><div>A programming language is a user interface.=C2=A0 It is th=
e responsibility of the language designer to make the affordances of the la=
nguage as clear and distinct as possible, so that when people are using the=
language it is easy for them to communicate their intentions, and such tha=
t it is difficult for people to accidentally say one thing when they meant =
another.=C2=A0 For example, this is why Fortran's implicitly typed (by =
their first letter) variables are wrong; by not requiring declarations, a p=
rogrammer can make a typographical error and silently access a different va=
riable.=C2=A0 This is why, in Ada, comparisons are not associative; it is r=
are that someone who writes <font face=3D"monospace, monospace">a <=3D b=
<=3D c</font> in C++ wants the result that is actually computed.</div><=
div><br></div></div></div></div></blockquote><div>No, if you are talking ab=
out end-users of software industrial products and perhaps yes in other case=
s. But if you are in the latter place, the users should not include every e=
nd-users. Namely, there are users should not be considered as the interface=
serves to. Once it is clear, the scope of responsibility is limited. I don=
't think a general purposed language should care about persons who can&=
#39;t remember what he/she should not depend on, esp. to care them will pot=
entially reduce others' freedom.<br><br>=C2=A0<br></div><blockquote cla=
ss=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 class=3D"gmail_quo=
te"><div></div><div>As Rabbi Tarfon said in <a href=3D"http://www.chabad.or=
g/library/article_cdo/aid/682513/jewish/English-Text.htm" target=3D"_blank"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fwww.chabad.org%2Flibrary%2Farticle_cdo%2Faid%2F682513%2F=
jewish%2FEnglish-Text.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHcYF009XJ=
xPePF6e0Z45B3nwfg_A';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fwww.chabad.org%2Flibrary%2Farticle_cdo%=
2Faid%2F682513%2Fjewish%2FEnglish-Text.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHcYF009XJxPePF6e0Z45B3nwfg_A';return true;">Pirkei Avot 2:16</a=
>, "You are not required to complete the work, but neither are you fre=
e to desist from it." =C2=A0Or as we also say, "The perfect is th=
e enemy of the good." =C2=A0Just because language design cannot fix ev=
erything is not an excuse to avoid fixing what it can.<br></div></div></div=
></div></blockquote><div>You still have not proven that is a "fix"=
; convincingly. I have sufficient reasons to treat it as pessimation of the=
design.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>Your belief is conflicts to the fact again. There=
are more than one people needing expressiveness or opportunity of optimiza=
tion only can be effectively allowed by unsequenced evaluation just in this=
topic. I believe there are committee members who think the same.</div></di=
v></blockquote><div><br></div><div>There are people who want to leave order=
unspecified on the grounds that the compiler can take advantage of that fo=
r optimization.=C2=A0 I have not seen anyone but you saying that programmer=
s want to visibly express a request for unspecified order in their C++ code=
..</div></div></div></div></blockquote><div>The optimization can be implemen=
ted with a relatively small cost because the unspecified order can be expre=
ssed, either explicitly or implicitly. If the default case is unseqneced, I=
can easily make a macro to tag sequenced evaluated expressions easily as I=
currently do. Allowing explicitly tagging code that being unsequenced eval=
uated is also a compromise to who thinks it is too error-prone as the defau=
lt case.<br><br><br><br></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/afd3a608-4751-4d54-8cce-946a1cc79354%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/afd3a608-4751-4d54-8cce-946a1cc79354=
%40isocpp.org</a>.<br />
------=_Part_18_865036092.1468812024717--
------=_Part_17_243969970.1468812024716--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 20:36:35 -0700 (PDT)
Raw View
------=_Part_157_85213888.1468812995586
Content-Type: multipart/alternative;
boundary="----=_Part_158_1853019080.1468812995587"
------=_Part_158_1853019080.1468812995587
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:20:42=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 2:42 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> You can write ';' to express specific evaluation order between=20
>> expressions (though currently it can't be used in single full expression=
).=20
>> When you write ',', there there is no such guarantee currently, unless t=
he=20
>> ',' is a builtin operator. You want to change the rule to make ',' behav=
es=20
>> like ';' about semantics about order. Extension like __unsequenced(x, y)=
=20
>> can be provided to override your rules of ',', but you seem to dislike t=
hem=20
>> just because you think doing that is wrong.
>>
>
> Yes, I want comma in the context of function call sequence the evaluation=
=20
> of arguments from left to right. I do not dislike an __unsequenced(x, y)=
=20
> construct; in fact, I wholeheartedly approve of it, because it places the=
=20
> locus of expressiveness in exactly the right place - the rare case where =
a=20
> programmer consciously wants to tell the compiler that order doesn't matt=
er.
>
Strictly speaking, this is a solution still needed currently to avoid the=
=20
operator comma to disturb the comprehension, as the pure macro solution has=
=20
difficulties on void expressions without the aid of extension. But it is=20
still not cleaner than to just to uniform the rules about commas.
I have also suggested here to allow semicolon as a replacement where a=20
non-operator comma can be. I think this is cleaner in user site but it need=
=20
more effort to get it right in the standard.
=20
>
> Why do you think that is the burden of their habits? They seem to have=20
>> reasons to warn people about the order rules and treat such rules are=20
>> merely compromise.
>>
>
> We don't warn people about a(); b(); Why should we warn people about f(a=
(),=20
> b())? It's because the people doing the warning have internalized that=
=20
> the latter is a problem because they have for so long used languages wher=
e=20
> in fact it was a problem. But you can still warn people that having=20
> multiple side effects can confuse understanding of what code is doing,=20
> simply because it increases the cognitive load - what the programmer has =
to=20
> keep in mind while reading the code.
>
I don't think change the meaning of ',' is the neat way, even it has=20
occurred in internalizer lists. I am actually not against to any particular=
=20
order itself, but I don't want to see the messier semantics on punctuators,=
=20
particularly to change the default case. I prefer introducing a new=20
notation to handle the different intents, e.g. both `f(a(); b())` and=20
`f(a(), b())` well-formed, with different semantics.
=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/a425631c-8252-48fa-9d1f-c619a922a171%40isocpp.or=
g.
------=_Part_158_1853019080.1468812995587
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:20:42=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:42 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"wtEZAUGaCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>You can write ';' to express s=
pecific evaluation order between expressions (though currently it can't=
be used in single full expression). When you write ',', there ther=
e is no such guarantee currently, unless the ',' is a builtin opera=
tor. You want to change the rule to make ',' behaves like ';=
9; about semantics about order. Extension like __unsequenced(x, y) can be p=
rovided to override your rules of ',', but you seem to dislike them=
just because you think doing that is wrong.<br></div></div></blockquote><d=
iv><br>Yes, I want comma in the context of function call sequence the evalu=
ation of arguments from left to right.=C2=A0 I do not dislike an=C2=A0<font=
face=3D"monospace, monospace">__unsequenced(x, y)</font> construct; in fac=
t, I wholeheartedly approve of it, because it places the locus of expressiv=
eness in exactly the right place - the rare case where a programmer conscio=
usly wants to tell the compiler that order doesn't matter.<br></div></d=
iv></div></div></blockquote><div>Strictly speaking, this is a solution stil=
l needed currently to avoid the operator comma to disturb the comprehension=
, as the pure macro solution has difficulties on void expressions without t=
he aid of extension. But it is still not cleaner than to just to uniform th=
e rules about commas.<br>I have also suggested here to allow semicolon as a=
replacement where a non-operator comma can be. I think this is cleaner in =
user site but it need more effort to get it right in the standard.<br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-s=
tyle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div>Why do you think that is the burden of their habits? They seem t=
o have reasons to warn people about the order rules and treat such rules ar=
e merely compromise.<br></div></div></blockquote><div><br></div><div>We don=
't warn people about <font face=3D"monospace, monospace">a(); b();</fon=
t> =C2=A0Why should we warn people about <font face=3D"monospace, monospace=
">f(a(), b())</font>?=C2=A0 It's because the people doing the warning h=
ave internalized that the latter is a problem because they have for so long=
used languages where in fact it was a problem.=C2=A0 But you can still war=
n people that having multiple side effects can confuse understanding of wha=
t code is doing, simply because it increases the cognitive load - what the =
programmer has to keep in mind while reading the code.</div></div></div></d=
iv></blockquote><div>I don't think change the meaning of ',' is=
the neat way, even it has occurred in internalizer lists. I am actually no=
t against to any particular order itself, but I don't want to see the m=
essier semantics on punctuators, particularly to change the default case. I=
prefer introducing a new notation to handle the different intents, e.g. bo=
th `f(a(); b())` and `f(a(), b())` well-formed, with different semantics.<b=
r>=C2=A0 <br></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/a425631c-8252-48fa-9d1f-c619a922a171%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a425631c-8252-48fa-9d1f-c619a922a171=
%40isocpp.org</a>.<br />
------=_Part_158_1853019080.1468812995587--
------=_Part_157_85213888.1468812995586--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 21:13:39 -0700 (PDT)
Raw View
------=_Part_1313_461052008.1468815219856
Content-Type: multipart/alternative;
boundary="----=_Part_1314_383228584.1468815219857"
------=_Part_1314_383228584.1468815219857
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:36:00=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 2:54 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> No. First, a programming language is not guaranteed to direct the=20
>> operations of a computer.
>>
>
> WIth probability 1, no programmer writes computer programs that are not=
=20
> intended to direct the operations of a computer. The fact that various=
=20
> operations are needed in order to get some program to direct the operatio=
ns=20
> of some computer is only relevant when those operations warp the program =
so=20
> that the computer does not operate in the way the programmer intended.
>
> No.
First, programming is not equal to "targetting code to machines". Actually,=
=20
this is the work of a language implementation and most humans are not good=
=20
at it. For people who are good at it, they have more reason to not do so. I=
=20
have seen people who may write C++ code not to make it operated on any=20
concrete computer, e.g. to debug/test a compiler frontend.
Second, you can't effectively assume people who writes code in arbitrary=20
languages (e.g. some XML dialects or Markdown) to "direct the operations of=
=20
some computer". Such code can be checked by human even before it is=20
interpreted by a computer. C++ actually has enough features to be used as=
=20
such a domain specific language. I also wrap some DSL code in C++ literals=
=20
to replace some declarative scripts (e.g. code in XAML) in my projects,=20
which is still meaningful even without being compiled.
Third, "targetting code to machines" is not equal to "imperatively=20
interpreting the code". The "left-to-right" property, as mentioned by=20
others, is dominated by the imperative paradigm which you stick to. But=20
there are more. (Please also note C++'s attitude to paradigms.) The=20
opposite is the declarative code. When being compiled, with defined=20
left-to-right order, even with overloaded literal operators, evaluation of=
=20
such code (which may be not side-effect-free but still be referential=20
transparent) is almost always pessimized.
To be aware of the last point here is actually very important to an=20
interface designer. In short, it's like interpreters of interface with=20
builtin sequenced boundary (like traditional ISA of CPU) vs full-featured=
=20
abstract interpreters (software-based interpreters/compilers/compiler=20
transformers/partial evaluators/supercompilers, etc.). Neither one can=20
replace another without excessive cost.
=20
> Second, the reason of defined constructs to force people does not write=
=20
>> so-called "ambiguous" directions is absurd. It's up to the users, and yo=
u=20
>> are not able to speak for all of them.
>>
>
> Because, with probability 1, programmers write programs intended to direc=
t=20
> the operations of a computer, it is seldom likely that the programmer wan=
ts=20
> to express lack of concern about the order in which things happen. The=
=20
> programmer may be writing a concurrent program in which events are expect=
ed=20
> to happen simultaneously, or the programmer may in fact not care about th=
e=20
> order of two things. But with probability 1, no programmer wants to=20
> express in the C++ code that two operations should be done in arbitrary=
=20
> order. What does happen with probability greater than 0 is that a=20
> programmer writes code in which things must happen in some order, but=20
> expresses it in a way that the language does not require happen in that=
=20
> order, while the underlying platform happens to produce the desired order=
.. =20
> This introduces a latent error into the code, which can manifest years=20
> later when the program is built on a platform that produces a different=
=20
> order.
> =20
>
See the use cases above.
Third, even if you have disciplined every user to obey your rules=20
>> successfully, users can invent something they want. When they call it a=
=20
>> "language", you claims disable again.
>>
>
> When the language design is good, users do not need to be "disciplined"=
=20
> into "obeying" rules.=20
>
It's *you *are disciplining users, by forcing them to only treat specific=
=20
sets of rules as "good" as you think.
=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/631c28b2-271d-4711-928e-367aa188222e%40isocpp.or=
g.
------=_Part_1314_383228584.1468815219857
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:36:00=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:54 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"z0Q95habCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>No. First, a programming language is n=
ot guaranteed to direct the operations of a computer.</div></div></blockquo=
te><div><br></div><div>WIth probability 1, no programmer writes computer pr=
ograms that are not intended to direct the operations of a computer.=C2=A0 =
The fact that various operations are needed in order to get some program to=
direct the operations of some computer is only relevant when those operati=
ons warp the program so that the computer does not operate in the way the p=
rogrammer intended.</div><div><br></div></div></div></div></blockquote><div=
>No.<br><br>First, programming is not equal to "targetting code to mac=
hines". Actually, this is the work of a language implementation and mo=
st humans are not good at it. For people who are good at it, they have more=
reason to not do so. I have seen people who may write C++ code not to make=
it operated on any concrete computer, e.g. to debug/test a compiler fronte=
nd.<br><br>Second, you can't effectively assume people who writes code =
in arbitrary languages (e.g. some XML dialects or Markdown) to "direct=
the operations of some computer". Such code can be checked by human e=
ven before it is interpreted by a computer. C++ actually has enough feature=
s to be used as such a domain specific language. I also wrap some DSL code =
in C++ literals to replace some declarative scripts (e.g. code in XAML) in =
my projects, which is still meaningful even without being compiled.<br><br>=
Third, "targetting code to machines" is not equal to "impera=
tively interpreting the code". The "left-to-right" property,=
as mentioned by others, is dominated by the imperative paradigm which you =
stick to. But there are more. (Please also note C++'s attitude to parad=
igms.) The opposite is the declarative code. When being compiled, with defi=
ned left-to-right order, even with overloaded literal operators, evaluation=
of such code (which may be not side-effect-free but still be referential t=
ransparent) is almost always pessimized.<br><br>To be aware of the last poi=
nt here is actually very important to an interface designer. In short, it&#=
39;s like interpreters of interface with builtin sequenced boundary (like t=
raditional ISA of CPU) vs full-featured abstract interpreters (software-bas=
ed interpreters/compilers/compiler transformers/partial evaluators/supercom=
pilers, etc.). Neither one can replace another without excessive cost.<br>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div>Second, the reason of defined constructs to force people does not=
write so-called "ambiguous" directions is absurd. It's up to=
the users, and you are not able to speak for all of them.<br></div></div><=
/blockquote><div><br></div><div>Because, with probability 1, programmers wr=
ite programs intended to direct the operations of a computer, it is seldom =
likely that the programmer wants to express lack of concern about the order=
in which things happen.=C2=A0 The programmer may be writing a concurrent p=
rogram in which events are expected to happen simultaneously, or the progra=
mmer may in fact not care about the order of two things.=C2=A0 But with pro=
bability 1, no programmer wants to express in the C++ code that two operati=
ons should be done in arbitrary order.=C2=A0 What does happen with probabil=
ity greater than 0 is that a programmer writes code in which things must ha=
ppen in some order, but expresses it in a way that the language does not re=
quire happen in that order, while the underlying platform happens to produc=
e the desired order.=C2=A0 This introduces a latent error into the code, wh=
ich can manifest years later when the program is built on a platform that p=
roduces a different order.</div><div>=C2=A0</div></div></div></div></blockq=
uote><div>See the use cases above.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-l=
eft:1ex"><div dir=3D"ltr"><div>Third, even if you have <span>disciplined ev=
ery user to obey your rules successfully, users can invent something they w=
ant. When they call it a "language", you claims disable again.</s=
pan></div></div></blockquote><div><br></div><div>When the language design i=
s good, users do not need to be "disciplined" into "obeying&=
quot; rules.=C2=A0</div></div></div></div></blockquote><div>It's <i>you=
</i>are disciplining users, by forcing them to only treat specific sets of=
rules as "good" as you think.<br>=C2=A0<br></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/631c28b2-271d-4711-928e-367aa188222e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/631c28b2-271d-4711-928e-367aa188222e=
%40isocpp.org</a>.<br />
------=_Part_1314_383228584.1468815219857--
------=_Part_1313_461052008.1468815219856--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 21:42:16 -0700 (PDT)
Raw View
------=_Part_1378_1218916394.1468816936646
Content-Type: multipart/alternative;
boundary="----=_Part_1379_1818417998.1468816936654"
------=_Part_1379_1818417998.1468816936654
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:42:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 2:58 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=8812:15:34=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> On Wed, Jul 13, 2016 at 11:28 PM, FrankHB1989 <frank...@gmail.com>=20
>>> wrote:
>>>>
>>>>
>>>> - Leave it unseqenced, if intended.
>>>>
>>>> The proportion of C++ code that has intentional lack of sequence is 0,=
=20
>>> to a great number of decimal places. Using this as a reason to not ado=
pt=20
>>> rules that would prevent latent errors from being expressed years after=
=20
>>> they are written is wrong.
>>>
>> If this is true, it is mostly because the author has not considered abou=
t=20
>> it yet.
>>
>
> No, this is true because it's unnecessary. The programmer is writing a=
=20
> program to direct the actions of a computer. As long as the computer=20
> behaves as the programmer wishes, it is not necessary for the programmer =
to=20
> consider every possible other way of writing the program.
> =20
>
This is not true, see above.=20
> To avoiding thinking is not worth encouraging, because it can easily caus=
e=20
>> errors with significantly higher cost.
>>
>
> The error that this sort of thinking is causing is poor design of C++.
>
That's irrelevant. These errors are consistent.
=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/ba55f4d5-99ba-4913-ad75-307c8b101b1d%40isocpp.or=
g.
------=_Part_1379_1818417998.1468816936654
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:42:24=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:58 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"1LktKXCbCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=
=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:15:3=
4=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<span><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 class=3D"gmail_quote">On Wed,=
Jul 13, 2016 at 11:28 PM, FrankHB1989 <span dir=3D"ltr"><<a rel=3D"nofo=
llow">frank...@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><ul><li>Leave it unseqenced, if intended.</li></ul>=
</div></div></blockquote><div>The proportion of C++ code that has intention=
al lack of sequence is 0, to a great number of decimal places.=C2=A0 Using =
this as a reason to not adopt rules that would prevent latent errors from b=
eing expressed years after they are written is wrong.</div></div></div></di=
v></blockquote></span><div>If this is true, it is mostly because the author=
has not considered about it yet.</div></div></blockquote><div><br></div><d=
iv>No, this is true because it's unnecessary.=C2=A0 The programmer is w=
riting a program to direct the actions of a computer.=C2=A0 As long as the =
computer behaves as the programmer wishes, it is not necessary for the prog=
rammer to consider every possible other way of writing the program.</div><d=
iv>=C2=A0<br></div></div></div></div></blockquote><div>This is not true, se=
e above. <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div> To avoiding thinking is not worth encouraging, =
because it can easily cause errors with significantly higher cost.</div></d=
iv></blockquote><div><br></div><div>The error that this sort of thinking is=
causing is poor design of C++.</div></div></div></div></blockquote><div>Th=
at's irrelevant. These errors are consistent.<br>=C2=A0<br></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/ba55f4d5-99ba-4913-ad75-307c8b101b1d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba55f4d5-99ba-4913-ad75-307c8b101b1d=
%40isocpp.org</a>.<br />
------=_Part_1379_1818417998.1468816936654--
------=_Part_1378_1218916394.1468816936646--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 21:44:26 -0700 (PDT)
Raw View
------=_Part_1064_1976854478.1468817067015
Content-Type: multipart/alternative;
boundary="----=_Part_1065_416284487.1468817067015"
------=_Part_1065_416284487.1468817067015
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:44:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 3:02 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> That's ashamed for attitude of some users, rather the language design.
>>
>
> Poor interface designers deflect blame by blaming users.
>
Poor usage of language has always higher precedence to be blamed in=20
practice because it will cost more various of problems. Fixing a language=
=20
specification is rather simpler.=20
> =20
>
>> It was 2009. Why you allow raw 'new' occurred here in such way?
>>
>
> Poor interface designers deflect blame by blaming users.
>
Not all of the use should be blamed. So the users to misused it should be=
=20
blamed at first.
=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/6f872054-ac85-4ba7-a7cf-7874babee1dc%40isocpp.or=
g.
------=_Part_1065_416284487.1468817067015
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:44:24=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 3:02 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"Naj2IYybCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>That's ashamed for attitude of som=
e users, rather the language design.<br></div></div></blockquote><div><br><=
/div><div>Poor interface designers deflect blame by blaming users.</div></d=
iv></div></div></blockquote><div>Poor usage of language has always higher p=
recedence to be blamed in practice because it will cost more various of pro=
blems. Fixing a language specification is rather simpler. <br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-=
left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It was =
2009. Why you allow raw 'new' occurred here in such way?</div></div=
></blockquote><div><br></div><div>Poor interface designers deflect blame by=
blaming users.</div></div></div></div></blockquote><div>Not all of the use=
should be blamed. So the users to misused it should be blamed at first.<br=
>=C2=A0<br></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/6f872054-ac85-4ba7-a7cf-7874babee1dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6f872054-ac85-4ba7-a7cf-7874babee1dc=
%40isocpp.org</a>.<br />
------=_Part_1065_416284487.1468817067015--
------=_Part_1064_1976854478.1468817067015--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 22:01:08 -0700 (PDT)
Raw View
------=_Part_1407_732935249.1468818068162
Content-Type: multipart/alternative;
boundary="----=_Part_1408_1543192650.1468818068162"
------=_Part_1408_1543192650.1468818068162
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=8811:53:02=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 3:11 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> That's correct. C++ evaluation order should be strictly left-to-right,=
=20
>>> and then programmers should simply be taught that this is the rule. =20
>>> Additionally, they might have to be untaught the PEMDAS rule they learn=
ed=20
>>> in school; in the expression a() + b() * c(), we do not order the calls=
=20
>>> as b(), c(), a() even though the multiplication happens before the=20
>>> addition.
>>>
>>
>> That's because poor mathematical education does not teach them enough=20
>> about why this can work.
>>
>
> No, PEMDAS is not poor mathematical education. It is correct mathematica=
l=20
> convention.
>
No, PEMDAS is bad designed syntax. The reason should just fit in your=20
flavor: it can not be parsed merely form left to right.
Seriously, all infix notations requiring precedence rules and temporary=20
states to parse fall in this category of "bad design", because it makes=20
both human users and machine frustrates, with almost no benefits.
One more example is C declarator syntax, which also poisons C++ and Java,=
=20
etc. Even with trailing-return-types, C++ can't abandon it because of=20
compatibility, and the resulted language specification are more complex,=20
the readers have to skill more to work. There are no shortcut to do it=20
correct efficiently.
The only benefits is it saves several blanket characters, which will save=
=20
paper (only beneficial for traditional mathematicians) or memory space in=
=20
the translation unit (only beneficial for early age computer users). This=
=20
seriously goes against to the "do not pay for you don't need" philosophy.
If you do not know that, I think you are a victim of bad habits caused by=
=20
historical bad design.
=20
>
>> As you, most of the victims have no notion of deduction systems.
>>
>
> What is a "deduction system"?
> =20
>
Ask your computer science teacher, or search the Web.
=20
> Only when the expressions are free from side effects, they have no need t=
o=20
>> care of the order. Once side effects are allowed, the world changes=20
>> totally. It is wrong to apply such poor knowledge here, it just does not=
=20
>> work.
>>
>
> This is what new programmers need to be taught. It is not poor knowledge=
,=20
> it is knowledge not applicable to this context. The PEMDAS rules do=20
> express the correct precedence and associativity in C++ for the operators=
=20
> they cover.
>
> No. The PEMDAS or any hard-coded precedence rules are *poisonous* because=
=20
it keep you stupid with almost nothing benefits. Any new programmers should=
=20
first learn and practice the technique of forgetting relying on bad design=
=20
(to feed the need in near future), and these rules are one of the easiest=
=20
targets.
=20
> And I should argue that PEMDAS rules are nonsense if one uses no infix=20
>> notation, and infix notation is often useless and harmful in many practi=
cal=20
>> cases out of school, but that is another story.
>>
>
> It is the essence of weird nerdiness to attempt to change notational=20
> conventions used by nearly everyone.
>
It is even more weird that almost everyone does not think it why they=20
should use it. For several milliseconds you should figure out that is=20
compatibility to old-timers, but that is not always the case.
=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/75803988-57d7-43dc-973c-8d0bc65e707e%40isocpp.or=
g.
------=_Part_1408_1543192650.1468818068162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=8811:53:02=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 3:11 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"0Zb1uQScCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>That=
's correct.=C2=A0 C++ evaluation order should be strictly left-to-right=
, and then programmers should simply be taught that this is the rule.=C2=A0=
Additionally, they might have to be untaught the PEMDAS rule they learned =
in school; in the expression <font face=3D"monospace, monospace">a() + b() =
* c()</font>, we do not order the calls as <font face=3D"monospace, monospa=
ce">b()</font>, <font face=3D"monospace, monospace">c()</font>, <font face=
=3D"monospace, monospace">a()</font> even though the multiplication happens=
before the addition.</div></div></div></div></blockquote></span><div><br>T=
hat's because poor mathematical education does not teach them enough ab=
out why this can work.</div></div></blockquote><div><br></div><div>No, PEMD=
AS is not poor mathematical education.=C2=A0 It is correct mathematical con=
vention.</div><div></div></div></div></div></blockquote><div>No, PEMDAS is =
bad designed syntax. The reason should just fit in your flavor: it can not =
be parsed merely form left to right.<br>Seriously, all infix notations requ=
iring precedence rules and temporary states to parse fall in this category =
of "bad design", because it makes both human users and machine fr=
ustrates, with almost no benefits.<br>One more example is C declarator synt=
ax, which also poisons C++ and Java, etc. Even with trailing-return-types, =
C++ can't abandon it because of compatibility, and the resulted languag=
e specification are more complex, the readers have to skill more to work. T=
here are no shortcut to do it correct efficiently.<br>The only benefits is =
it saves several blanket characters, which will save paper (only beneficial=
for traditional mathematicians) or memory space in the translation unit (o=
nly beneficial for early age computer users). This seriously goes against t=
o the "do not pay for you don't need" philosophy.<br>If you d=
o not know that, I think you are a victim of bad habits caused by historica=
l bad design.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div> As you, most of the victims h=
ave no notion of deduction systems.</div></div></blockquote><div><br></div>=
<div>What is a "deduction system"?</div><div>=C2=A0<br></div></di=
v></div></div></blockquote><div>Ask your computer science teacher, or searc=
h the Web.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div> Only when the expressions are free f=
rom side effects, they have no need to care of the order. Once side effects=
are allowed, the world changes totally. It is wrong to apply such poor kno=
wledge here, it just does not work.<br></div></div></blockquote><div><br></=
div><div>This is what new programmers need to be taught.=C2=A0 It is not po=
or knowledge, it is knowledge not applicable to this context.=C2=A0 The PEM=
DAS rules do express the correct precedence and associativity in C++ for th=
e operators they cover.</div><div><br></div></div></div></div></blockquote>=
<div>No. The PEMDAS or any hard-coded precedence rules are <i>poisonous</i>=
because it keep you stupid with almost nothing benefits. Any new programme=
rs should first learn and practice the technique of forgetting relying on b=
ad design (to feed the need in near future), and these rules are one of the=
easiest targets.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>And I should argue that PEMDAS=
rules are nonsense if one uses no infix notation, and infix notation is of=
ten useless and harmful in many practical cases out of school, but that is =
another story.</div></div></blockquote><div><br></div><div>It is the essenc=
e of weird nerdiness to attempt to change notational conventions used by ne=
arly everyone.</div></div></div></div></blockquote><div>It is even more wei=
rd that almost everyone does not think it why they should use it. For sever=
al milliseconds you should figure out that is compatibility to old-timers, =
but that is not always the case.<br><br>=C2=A0<br></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/75803988-57d7-43dc-973c-8d0bc65e707e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75803988-57d7-43dc-973c-8d0bc65e707e=
%40isocpp.org</a>.<br />
------=_Part_1408_1543192650.1468818068162--
------=_Part_1407_732935249.1468818068162--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 22:17:20 -0700 (PDT)
Raw View
------=_Part_176_1955615529.1468819040553
Content-Type: multipart/alternative;
boundary="----=_Part_177_2132045490.1468819040553"
------=_Part_177_2132045490.1468819040553
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=8812:03:29=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 3:17 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> No. Knowing too much is not beneficial. Requiring to know too much is=20
>> harmful as it is against to many goals. I doubt you are lack of knowledg=
e=20
>> about "separating interface from implementation" and "principle of least=
=20
>> privilege".
>>
>
> You would be surprised :-) I believe that information wants to be free,=
=20
> and that not infrequently, a separated interface hides aspects of an=20
> implementation that would be better served if users could see them. =20
> Information hiding inverts the hierarchy of wisdom and experience; it=20
> assumes the designers of the past have the foresight to conceal exactly t=
he=20
> correct information from the programmers of the future.
>
It depends. Whether to use an extra abstraction layer to hide information=
=20
is a design choice, which is determined by the feasibility to meet the=20
need. For example, if portability is needed, then the implementation=20
details usually cannot be exposed by the interface because there is almost=
=20
no other feasible way to keep this property. If it is effected by=20
implementation, that can only be a compromise.
To serve to possibly varying needs, the process of design should be more or=
=20
less fault-tolerating. The fault may include missing of concrete=20
information. So correct information from the programmers (of the future or=
=20
not) are not always needed. Otherwise, the resulted design fails on=20
availability. And in general, this fault is to be resolved by abstraction -=
=20
which may involved with information hiding of what you cannot determine.=20
Then it's the users' responsibility to keep the remained things work.
=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/a712e7fe-9274-4eca-86e6-9aea9a39e3ff%40isocpp.or=
g.
------=_Part_177_2132045490.1468819040553
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:03:29=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 3:17 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"KfXTxZacCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>No. Knowing too much is =
not beneficial. Requiring to know too much is harmful as it is against to m=
any goals. I doubt you are lack of knowledge about "separating interfa=
ce from implementation" and "principle of least privilege".<=
/div></div></blockquote><div><br></div><div>You would be surprised :-) =C2=
=A0I believe that information wants to be free, and that not infrequently, =
a separated interface hides aspects of an implementation that would be bett=
er served if users could see them.=C2=A0 Information hiding inverts the hie=
rarchy of wisdom and experience; it assumes the designers of the past have =
the foresight to conceal exactly the correct information from the programme=
rs of the future.</div></div></div></div></blockquote><div>It depends. Whet=
her to use an extra abstraction layer to hide information is a design choic=
e, which is determined by the feasibility to meet the need. For example, if=
portability is needed, then the implementation details usually cannot be e=
xposed by the interface because there is almost no other feasible way to ke=
ep this property. If it is effected by implementation, that can only be a c=
ompromise.<br>To serve to possibly varying needs, the process of design sho=
uld be more or less fault-tolerating. The fault may include missing of conc=
rete information. So correct information from the programmers (of the futur=
e or not) are not always needed. Otherwise, the resulted design fails on av=
ailability. And in general, this fault is to be resolved by abstraction - w=
hich may involved with information hiding of what you cannot determine. The=
n it's the users' responsibility to keep the remained things work.<=
br><br>=C2=A0<br></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/a712e7fe-9274-4eca-86e6-9aea9a39e3ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a712e7fe-9274-4eca-86e6-9aea9a39e3ff=
%40isocpp.org</a>.<br />
------=_Part_177_2132045490.1468819040553--
------=_Part_176_1955615529.1468819040553--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 22:24:50 -0700 (PDT)
Raw View
------=_Part_1321_1170758449.1468819491002
Content-Type: multipart/alternative;
boundary="----=_Part_1322_1051986577.1468819491002"
------=_Part_1322_1051986577.1468819491002
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=8812:15:00=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 7:00 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=883:04:55=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> I don't live in that utopia, "Ren Industries" does. In my world, C++ i=
s=20
>>> used to direct actions of computers, not abstract machines.
>>>
>> Then you are alien. In this world, semantics of C++ is defined by=20
>> abstract machine, which is explicit in the standard. Machines usually ru=
n=20
>> code transformed from C++, but not C++ source. The compiler frontend nee=
ds=20
>> to know nothing about machine when generating machine-independent code.
>>
>
> C++ Standard 1.9: "This International Standard places no requirement on=
=20
> the structure of conforming implementations. In particular, they need not=
=20
> copy or emulate the structure of the abstract machine. Rather, conforming=
=20
> implementations are required to emulate (only) the observable behavior of=
=20
> the abstract machine"
>
> Programmers write C++ programs in order to direct operations of=20
> computers. When the computer runs under the control of the program, the=
=20
> computer emulates the operations of the abstract machine. The operations=
=20
> needed to get the program to direct the actions of the computer are=20
> irrelevant. They only become relevant when they misinterpret the=20
> intentions of the programmer so that the computer does not operate in the=
=20
> way the programmer intended.
>
> No. Any language users can only relying on stuff provided by the language=
=20
specification, but not the implementation details. If that person also=20
relies on the implementation, he/she has a role other than the programmer=
=20
of that language. A person as you described is not a programmer, but a=20
machinist of the computer. If he/she works relying on ISA of the processor,=
=20
he/she may be a machine code or machine-specific assembly programmer. So=20
on. Any C++ programmer can only works relying on the abstraction machine or=
=20
equivalent rules. Since formal methods is so difficult for traditional=20
C-like languages, I assume he/she should always rely on the abstract=20
machine model as a C++ programmer. This is even irrelevant about whether=20
he/she know the abstraction machine or not.
=20
> To reduce all kinds of cost, try to ask turning back to Java.
>>
>
> I don't know why you believe turning back to Java would reduce all kinds=
=20
> of cost (nor is this the pace to discuss that).=20
>
For example, JLS already has specified the evaluation that you need. You=20
can save much time here.
=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/2bbb82f9-839c-4775-bf20-d70a46de6838%40isocpp.or=
g.
------=_Part_1322_1051986577.1468819491002
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:15:00=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 7:00 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"dzXcnzedCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=
=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:04:55=EF=BC=8CHyman=
Rosen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bor=
der-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><span><div>I don't live in that utopia, "R=
en Industries" does.=C2=A0 In my world, C++ is used to direct actions =
of computers, not abstract machines.<br></div></span></div></div></div></bl=
ockquote><div>Then you are alien. In this world, semantics of C++ is define=
d by abstract machine, which is explicit in the standard. Machines usually =
run code transformed from C++, but not C++ source. The compiler frontend ne=
eds to know nothing about machine when generating machine-independent code.=
<br></div></div></blockquote><div><br>C++ Standard 1.9: "This Internat=
ional Standard places no requirement on the structure of conforming impleme=
ntations. In particular, they need not copy or emulate the structure of the=
abstract machine. Rather, conforming implementations are required to emula=
te (only) the observable behavior of the abstract machine"</div><div><=
br></div><div>Programmers write C++ programs in order to direct operations =
of computers.=C2=A0 When the computer runs under the control of the program=
, the computer emulates the operations of the abstract machine.=C2=A0 The o=
perations needed to get the program to direct the actions of the computer a=
re irrelevant.=C2=A0 They only become relevant when they misinterpret the i=
ntentions of the programmer so that the computer does not operate in the wa=
y the programmer intended.</div><div><br></div></div></div></div></blockquo=
te><div>No. Any language users can only relying on stuff provided by the la=
nguage specification, but not the implementation details. If that person al=
so relies on the implementation, he/she has a role other than the programme=
r of that language. A person as you described is not a programmer, but a ma=
chinist of the computer. If he/she works relying on ISA of the processor, h=
e/she may be a machine code or machine-specific assembly programmer. So on.=
Any C++ programmer can only works relying on the abstraction machine or eq=
uivalent rules. Since formal methods is so difficult for traditional C-like=
languages, I assume he/she should always rely on the abstract machine mode=
l as a C++ programmer. This is even irrelevant about whether he/she know th=
e abstraction machine or not.<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div>To reduce all kinds of cost, try=
to ask turning back to Java.</div></div></blockquote><div><br></div><div>I=
don't know why you believe turning back to Java would reduce all kinds=
of cost (nor is this the pace to discuss that).=C2=A0</div></div></div></d=
iv></blockquote><div>For example, JLS already has specified the evaluation =
that you need. You can save much time here.<br><br>=C2=A0<br></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/2bbb82f9-839c-4775-bf20-d70a46de6838%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2bbb82f9-839c-4775-bf20-d70a46de6838=
%40isocpp.org</a>.<br />
------=_Part_1322_1051986577.1468819491002--
------=_Part_1321_1170758449.1468819491002--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 22:44:42 -0700 (PDT)
Raw View
------=_Part_1452_797426856.1468820682403
Content-Type: multipart/alternative;
boundary="----=_Part_1453_328815204.1468820682403"
------=_Part_1453_328815204.1468820682403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=8812:30:38=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 7:08 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=883:43:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> If programming languages do not exist to direct the operations of a=20
>>> computer, and their domain is computer science, then constant factors a=
re=20
>>> irrelevant. Computer science does not care if algorithms run twice as=
=20
>>> fast, it only cares about running speed as asymptotic to a function of=
=20
>>> problem size.
>>>
>> This is not I heard. Computer architecture study *is *concerned about=20
>> the constant factor.
>>
>
> Computer architecture is not computer science. The concerns of computer=
=20
> architecture are not the concerns of computer programming languages. The=
=20
> famous attempt to associate the two, the Intel 432 "Ada on a chip", was a=
=20
> disaster.
> =20
>
No. It's disputable that only a few domains like study of=20
architecture-related modelling *is *the computer science. Many other=20
branches of so-called "(theoretical) computer science" are actually=20
branches of mathematics, because computers are not essential to them. For=
=20
example, theory of computation remains valid even if there is no computer=
=20
ever invented.
=20
> You are asking exposing implementation details into interface constraints=
,=20
>> *unconditionally*.
>>
>
> I am doing nothing of the sort. I am talking about fixing errors in the=
=20
> design of the programming language C++. The notions of interface and=20
> implementation are high-level concepts that can be programmed in C++, but=
=20
> they are not C++ itself.
> =20
>
To be left-to-right is an implementation of the interface holding "I don't=
=20
care how to choose the order". To specify any specific order is an=20
implementation of the interface holding "I don't care the order."
The notions of interface and implementation are not only suited to=20
high-level concepts. It is orthogonal to the layered architecture. And the=
=20
distinction of interface and implementation is *relative*. That means,=20
interface is not guaranteed always to be the interface and so is the=20
implementation. Both of them depend on view.
=20
> To increase the number of possible legal programs is not the goal of a=20
>> practical language. Why bother a language worrying about too few program=
s=20
>> are legal?
>>
>
> In this case, because the illegal programs are not detected by the=20
> programming environments that translate them. Therefore it is correct to=
=20
> make them legal and give them defined behavior.
> =20
>
No. Only after you prove it is the only feasible way, it is not correct.
=20
> Because adding new syntax so that people can choose not to use it and=20
>>> continue to write potentially broken code is silly, when the change to =
the=20
>>> language would not affect the legality or behavior of currently legal=
=20
>>> programs.
>>>
>> You still have no evidence beyond your personal value judgement. That=20
>> seems to be ignorance and prejudice.
>>
>
> My thesis is simple - unspecified behavior leads to latent errors and is=
=20
> of no practical benefit, and left-to-right evaluation is the best=20
> specification to use. My goal is to make sure that silence is not taken=
=20
> for approval. The C++ Committee has been wrong many times before, and th=
ey=20
> are wrong again. If I cannot change the outcome, I can at least say "I=
=20
> told you so."
>
The practical benefits exist, for clearer interaction between users, the=20
authors of the specification and the authors of implementations.=20
Implementations can actual provide more flexible (read: benificial) result=
=20
because the users rely on fewer assumptions. To make it silence or not is a=
=20
problem of QoI. Besides, you have not proved "left-to-right evaluation is=
=20
the best specification to use".
=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/a5dede27-fba7-47c1-b465-198b1cd06412%40isocpp.or=
g.
------=_Part_1453_328815204.1468820682403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:30:38=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 7:08 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"b-hk9xGeCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=
=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:43:24=EF=BC=8CHyman=
Rosen=E5=86=99=E9=81=93=EF=BC=9A<span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div>If programming languages do not exist to=
direct the operations of a computer, and their domain is computer science,=
then constant factors are irrelevant.=C2=A0 Computer science does not care=
if algorithms run twice as fast, it only cares about running speed as asym=
ptotic to a function of problem size.<br></div></div></div></div></blockquo=
te></span><div>This is not I heard. Computer architecture study <i>is </i>c=
oncerned about the constant factor.<br></div></div></blockquote><div><br></=
div><div>Computer architecture is not computer science.=C2=A0 The concerns =
of computer architecture are not the concerns of computer programming langu=
ages.=C2=A0 The famous attempt to associate the two, the Intel 432 "Ad=
a on a chip", was a disaster.</div><div>=C2=A0</div></div></div></div>=
</blockquote><div>No. It's disputable that only a few domains like stud=
y of architecture-related modelling <i>is </i>the computer science. Many ot=
her branches of so-called "(theoretical) computer science" are ac=
tually branches of mathematics, because computers are not essential to them=
.. For example, theory of computation remains valid even if there is no comp=
uter ever invented.<br><br>=C2=A0<br></div><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 class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>You are asking exposing implementation details in=
to interface constraints, <i>unconditionally</i>.<br></div></div></blockquo=
te><div><br></div><div>I am doing nothing of the sort.=C2=A0 I am talking a=
bout fixing errors in the design of the programming language C++.=C2=A0 The=
notions of interface and implementation are high-level concepts that can b=
e programmed in C++, but they are not C++ itself.</div><div>=C2=A0=C2=A0</d=
iv></div></div></div></blockquote><div>To be left-to-right is an implementa=
tion of the interface holding "I don't care how to choose the orde=
r". To specify any specific order is an implementation of the interfac=
e holding "I don't care the order."<br>The notions of interfa=
ce and implementation are not only suited to high-level concepts. It is ort=
hogonal to the layered architecture. And the distinction of interface and i=
mplementation is <i>relative</i>. That means, interface is not guaranteed a=
lways to be the interface and so is the implementation. Both of them depend=
on view.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>To increase the number of possible legal programs is not the =
goal of a practical language. Why bother a language worrying about too few =
programs are legal?<br></div></div></blockquote><div><br></div><div>In this=
case, because the illegal programs are not detected by the programming env=
ironments that translate them.=C2=A0 Therefore it is correct to make them l=
egal and give them defined behavior.</div><div>=C2=A0</div></div></div></di=
v></blockquote><div>No. Only after you prove it is the only feasible way, i=
t is not correct.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div>Because adding new syntax so that people can choose not =
to use it and continue to write potentially broken code is silly, when the =
change to the language would not affect the legality or behavior of current=
ly legal programs.</div></div></div></div></blockquote></span><div>You stil=
l have no evidence beyond your personal value judgement. That seems to be i=
gnorance and prejudice.</div></div></blockquote><div><br></div><div>My thes=
is is simple - unspecified behavior leads to latent errors and is of no pra=
ctical benefit, and left-to-right evaluation is the best specification to u=
se.=C2=A0 My goal is to make sure that silence is not taken for approval.=
=C2=A0 The C++ Committee has been wrong many times before, and they are wro=
ng again.=C2=A0 If I cannot change the outcome, I can at least say "I =
told you so."</div></div></div></div></blockquote><div>The practical b=
enefits exist, for clearer interaction between users, the authors of the sp=
ecification and the authors of implementations. Implementations can actual =
provide more flexible (read: benificial) result because the users rely on f=
ewer assumptions. To make it silence or not is a problem of QoI. Besides, y=
ou have not proved "left-to-right evaluation is the best specification=
to use".<br><br>=C2=A0<br></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/a5dede27-fba7-47c1-b465-198b1cd06412%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5dede27-fba7-47c1-b465-198b1cd06412=
%40isocpp.org</a>.<br />
------=_Part_1453_328815204.1468820682403--
------=_Part_1452_797426856.1468820682403--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 22:50:32 -0700 (PDT)
Raw View
------=_Part_1077_1948355641.1468821032803
Content-Type: multipart/alternative;
boundary="----=_Part_1078_1273756404.1468821032803"
------=_Part_1078_1273756404.1468821032803
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=8812:38:24=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 7:24 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> To provide different behavior "class"es is useful to clarify the=20
>> responsibility. Existence of any undefined behavior will make you lose t=
he=20
>> guarantees of any predictable properties from the semantic rules.=20
>> Unspecified behavior exists as a way to specify what you should not rely=
on=20
>> but still allowed to be presented. Well-defined behavior is the predicta=
ble=20
>> thing you can safely rely on. These notions have nothing to do with=20
>> compilers; they are contents of the contract among designers of the=20
>> language, authors of the implementations and users of the=20
>> language/implementations (programmers). Concrete machines here are again=
=20
>> irrelevant because they are merely implementation details.
>>
>
>
> Concrete machines carry out the actions of the abstract machine. They ar=
e=20
> the most relevant part of the programming process because they are the=20
> reason the program was written. It is in the actions carried out by the=
=20
> concrete machine that the programmer can discover whether the program has=
=20
> errors - that is, whether the interpretation of its intent by the=20
> environment matches the intent of the programmer.
>
No. The intents of programmer are encoded into the code under the aid of=20
the semantics rules. Behavior is only one part of the outcome. Folding=20
behavior into the same thing of semantics is not only infeasible (for=20
difficulties on writing specialization) but also useless (no users can=20
benefit from reducing the mechanism which can only provided by the=20
specification but not any concrete implementation, e.g. reasonable=20
interface portability enabled by optional semantics properties).=20
>
> Unspecified behavior is a problem when programmers can easily write=20
> programs that have unspecified behavior without realizing it. When=20
> unspecified behavior has no practical benefit and the behavior of the=20
> constructs involved can be easily specified, it is an error in the=20
> programming language design not to specify that behavior.
>
As of ease of discovering error - I've said it can be done without touching=
=20
the language specification.=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/c6a8e093-4990-45fa-bca0-24277e80888b%40isocpp.or=
g.
------=_Part_1078_1273756404.1468821032803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=8812:38:24=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 7:24 =
AM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"SbP1kX6eCwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>To provide different beh=
avior "class"es is useful to clarify the responsibility. Existenc=
e of any undefined behavior will make you lose the guarantees of any predic=
table properties from the semantic rules. Unspecified behavior exists as a =
way to specify what you should not rely on but still allowed to be presente=
d. Well-defined behavior is the predictable thing you can safely rely on. T=
hese notions have nothing to do with compilers; they are contents of the co=
ntract among designers of the language, authors of the implementations and =
users of the language/implementations (programmers). Concrete machines here=
are again irrelevant because they are merely implementation details.</div>=
</div></blockquote><div><br></div><div><br></div><div>Concrete machines car=
ry out the actions of the abstract machine.=C2=A0 They are the most relevan=
t part of the programming process because they are the reason the program w=
as written.=C2=A0 It is in the actions carried out by the concrete machine =
that the programmer can discover whether the program has errors - that is, =
whether the interpretation of its intent by the environment matches the int=
ent of the programmer.<br></div></div></div></div></blockquote><div>No. The=
intents of programmer are encoded into the code under the aid of the seman=
tics rules. Behavior is only one part of the outcome. Folding behavior into=
the same thing of semantics is not only infeasible (for difficulties on wr=
iting specialization) but also useless (no users can benefit from reducing =
the mechanism which can only provided by the specification but not any conc=
rete implementation, e.g. reasonable interface portability enabled by optio=
nal semantics properties). <br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br>Unspecifie=
d behavior is a problem when programmers can easily write programs that hav=
e unspecified behavior without realizing it.=C2=A0 When unspecified behavio=
r has no practical benefit and the behavior of the constructs involved can =
be easily specified, it is an error in the programming language design not =
to specify that behavior.</div></div></div></div></blockquote><div><br>As o=
f ease of discovering error - I've said it can be done without touching=
the language specification. <br></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/c6a8e093-4990-45fa-bca0-24277e80888b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6a8e093-4990-45fa-bca0-24277e80888b=
%40isocpp.org</a>.<br />
------=_Part_1078_1273756404.1468821032803--
------=_Part_1077_1948355641.1468821032803--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 17 Jul 2016 23:39:01 -0700 (PDT)
Raw View
------=_Part_663_840171151.1468823941882
Content-Type: multipart/alternative;
boundary="----=_Part_664_983491013.1468823941882"
------=_Part_664_983491013.1468823941882
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>
>>
>> In C and C++98/03, for some initialized and distinct scalar objects x an=
d=20
>> y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11 assig=
nment=20
>> allows it for non-volatile scalars, because the C++11 rules makes it=20
>> effectively ordered (in such cases), with *right-to-left* order.
>>
>>
> Nope, that's still undefined. It's essentially the same as i +=3D ++i + 1=
;=20
> discussed in=20
> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-und=
efined-behavior
>
> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=20
>
Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
=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/138af14b-7eea-49cd-b5db-e913e5aa4f52%40isocpp.or=
g.
------=_Part_664_983491013.1468823941882
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=
=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 w=
rote:<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><br>In C=
and C++98/03, for some initialized and distinct scalar objects x and y, x =
^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11 assignment al=
lows it for non-volatile scalars, because the C++11 rules makes it effectiv=
ely ordered (in such cases), with <i>right-to-left</i> order.<br><br></div>=
</div></blockquote><div><br></div><div>Nope, that's still undefined. It=
's essentially the same as i +=3D ++i + 1; discussed in=C2=A0<a href=3D=
"http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-unde=
fined-behavior" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fque=
stions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F=
stackoverflow.com%2Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefi=
ned-behavior\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70=
JPyQVQ';return true;">http://stackoverflow.com/<wbr>questions/24194076/=
in-c11-<wbr>does-i-i-1-exhibit-undefined-<wbr>behavior</a></div><div><br></=
div><div>i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=C2=A0</div>=
</div></blockquote><div>Really? Please i +=3D ++i + 1 is <i>not </i>j +=3D =
++i + 1.<br>=C2=A0<br></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/138af14b-7eea-49cd-b5db-e913e5aa4f52%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/138af14b-7eea-49cd-b5db-e913e5aa4f52=
%40isocpp.org</a>.<br />
------=_Part_664_983491013.1468823941882--
------=_Part_663_840171151.1468823941882--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 18 Jul 2016 10:11:38 -0400
Raw View
On 2016-07-15 11:12, Hyman Rosen wrote:
> There are people who want to leave order unspecified on the grounds that
> the compiler can take advantage of that for optimization. I have not seen
> anyone but you saying that programmers want to visibly express a request
> for unspecified order in their C++ code.
What about people that want to leave 'unspecified order' as the default
and visibly tag order dependencies? You should count these people too.
Both are arguing that both behaviors should be available, with the less
common case being more verbose.
The ratio of such that feel that 'unspecified order' should be the rare
case is telling...
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nmio2q%246ea%241%40ger.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 18 Jul 2016 10:16:34 -0400
Raw View
On 2016-07-14 07:32, Peter Koch Larsen wrote:
> If you have an f(g(),h()) and both g and h have side-effects, there
> is already unspecified behaviour, and if they do not, the compiler is
> already free to choose whatever evaluation order it deems best.
This would be true... *if the compiler could prove it*. Right now,
that's a problem.
> For those interested in speed, it is my belief that speed can be had
> in another way. A good, pragmatic specification of pure would be one
> way forward.
Agreed, and solving that problem *first* would go a long way to making
specified order more palatable.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nmioc2%24a4r%241%40ger.gmane.org.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 18 Jul 2016 10:36:17 -0400
Raw View
--001a1141ca484537540537e9e582
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 6:55 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On 15 Jul 2016 9:38 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
> > Programming languages are designed to control computers.
>
> How could that be possible, when a computer program can be run on a
> computer that did not exist and had not been designed at the time the
> program was written or compiled?
>
Because the computers are essentially the same. When they're not
(segmented architectures, no stacks, lisp machines) it is difficult to
translate the program to model the abstract machine. Often the
architecture leaks back into the language - near/far/huge pointers,
extended-precision intermediate floating point, and undefined behavior for
reading a variable containing an invalid pointer are just a few examples.
--
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/CAHSYqdbJTA9Z2CQQ2URv07p7Lw_6WBMbR8EJmhT%2B8WsUqtT1-Q%40mail.gmail.com.
--001a1141ca484537540537e9e582
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, Jul 15, 2016 at 6:55 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"></p>
<p dir=3D"ltr">On 15 Jul 2016 9:38 p.m., "Hyman Rosen" <<a hre=
f=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com<=
/a>> wrote:<br>
> Programming languages are designed to control computers.=C2=A0 </p>
</span><p dir=3D"ltr">How could that be possible, when a computer program c=
an be run on a computer that did not exist and had not been designed at the=
time the program was written or compiled?</p></blockquote><div>Because the=
computers are essentially the same.=C2=A0 When they're not (segmented =
architectures, no stacks, lisp machines) it is difficult to translate the p=
rogram to model the abstract machine.=C2=A0 Often the architecture leaks ba=
ck into the language - near/far/huge pointers, extended-precision intermedi=
ate floating point, and undefined behavior for reading a variable containin=
g an invalid pointer are just a few examples.</div></div></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/CAHSYqdbJTA9Z2CQQ2URv07p7Lw_6WBMbR8EJ=
mhT%2B8WsUqtT1-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbJTA9Z2C=
QQ2URv07p7Lw_6WBMbR8EJmhT%2B8WsUqtT1-Q%40mail.gmail.com</a>.<br />
--001a1141ca484537540537e9e582--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 18 Jul 2016 11:17:19 -0400
Raw View
--001a114c843a0170010537ea786d
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 15, 2016 at 8:31 PM, <inkwizytoryankes@gmail.com> wrote:
>
> I need 1 / 3, can you provide me one if it can't exists?
>
Sure. Use std::ratio<1,3> if you need exactly 1/3. If your needs allow
you to use a number close to 1/3 but not equal to it, you can use 1/3. or
1/3.f.
> I need choose one that always will have rounding error.
> And now I would like to have 1 / 9. I can choose again but what happens
> with equality 1 / 9 * 3 == 1 / 3? It can't be true for bit pattern equality.
> EVERY floating point operation have build in rounding errors. Even add can
> give "correct" results only when you add numbers of equal exponent.
>
The arithmetic of floating-point always yields the nearest representable
result to the correct value. The rounding error is the difference between
those two. Sometimes the rounding error is 0, and often it is not.
But whole point of this is to have better accuracy than otherwise possible.
> Your "error" is value that is closer to real number value that you suppose
> to get. You can't store it but you can continue calculating based on it.
>
That's half the point. The other half of the point is to have
deterministic arithmetic. When the very same calculation (in both cases, I
am dividing 1 by 3) produces different results, it is difficult to reason
about what code does. It is exactly as if 2 + 2 sometimes produced 5.
When doing things like converting numbers between bases, or doing range
reduction for mathematical functions, knowing exactly what the arithmetic
will do is important. We wind up with code sprinkled with 'volatile float'
and 'volatile double' to force proper rounding.
I suppose that's OK - it makes the people who need the exactness pay for it
and lets everyone else get expression results maybe a little closer to the
exact answer than they otherwise would be, but it's messy and awkward.
Sometimes people need to know
>> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.9012&rep=rep1&type=pdf> exactly
>> what their arithmetic is doing.
>>
>
> No, they only need to know amplitude of error.
>
Why do you think you can tell people what they need?
And if someone give them tool with greater accuracy ("secret" extended
> type) they will be more than pleased. All equalities that they use still
> holds for for it.
>
That is simply false. Floating-point arithmetic involves performing
exactly defined operations on rational numbers, and that can be used in
proofs - for example, I know that an arbitrary float can be written exactly
in decimal using no more than 150 digits. That matters, because I can rely
on picking off that many digits and winding up with 0. But if I get secret
extra precision, my result might in fact not be 0, and my code could wind
up being drastically incorrect.
But there is catch, they do not use bit equal. Even funnier FMA is used to
> recreate calculation in in greater accuracy that is equal if compiler is
> allowed to use greater accuracy than storage type have.
> This mean you get result of this paper in C++ for free.
>
They analyze results based on knowing exactly what the arithmetic does.
You can't get the result for free in C++ if your language definition can't
tell you exactly what the arithmetic does.
--
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/CAHSYqdZCn-jwpLRjyg%3DgBHG%2B2mns2v6WepHsdcX7kACQmLm9fQ%40mail.gmail.com.
--001a114c843a0170010537ea786d
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, Jul 15, 2016 at 8:31 PM, <span dir=3D"ltr"><<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>>=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I need 1=
/ 3, can you provide me one if it can't exists?</div></div></blockquot=
e><div><br></div><div>Sure.=C2=A0 Use std::ratio<1,3> if you need exa=
ctly 1/3.=C2=A0 If your needs allow you to use a number close to 1/3 but no=
t equal to it, you can use <font face=3D"monospace, monospace">1/3.</font> =
or <font face=3D"monospace, monospace">1/3.f</font>.</div><div>=C2=A0<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> I need choose one=
that always will have rounding error.<br>And now I would like to have 1 / =
9. I can choose again but what happens with equality 1 / 9 * 3 =3D=3D 1 / 3=
? It can't be true for bit pattern equality.<br>EVERY floating point op=
eration have build in rounding errors. Even=20
add can give "correct" results only when you add numbers of equal=
=20
exponent.<br></div></div></blockquote><div><br></div><div>The arithmetic of=
floating-point always yields the nearest representable result to the corre=
ct value.=C2=A0 The rounding error is the difference between those two.=C2=
=A0 Sometimes the rounding error is 0, and often it is not.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>But whole point o=
f this is to have better accuracy than otherwise possible. Your "error=
" is value that is closer to real number value that you suppose to get=
.. You can't store it but you can continue calculating based on it.<br><=
/div></div></blockquote><div><br></div><div>That's half the point.=C2=
=A0 The other half of the point is to have deterministic arithmetic.=C2=A0 =
When the very same calculation (in both cases, I am dividing 1 by 3) produc=
es different results, it is difficult to reason about what code does.=C2=A0=
It is exactly as if 2 + 2 sometimes produced 5.=C2=A0 When doing things li=
ke converting numbers between bases, or doing range reduction for mathemati=
cal functions, knowing exactly what the arithmetic will do is important.=C2=
=A0 We wind up with code sprinkled with 'volatile float' and 'v=
olatile double' to force proper rounding.<br><br>I suppose that's O=
K - it makes the people who need the exactness pay for it and lets everyone=
else get expression results maybe a little closer to the exact answer than=
they otherwise would be, but it's messy and awkward.</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockq=
uote 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 class=3D"gmail_=
quote"><div>Sometimes people <a href=3D"http://citeseerx.ist.psu.edu/viewdo=
c/download?doi=3D10.1.1.123.9012&rep=3Drep1&type=3Dpdf" rel=3D"nofo=
llow" target=3D"_blank">need to know</a>=C2=A0exactly what their arithmetic=
is doing.=C2=A0</div></div></div></div></blockquote></span><div>=C2=A0<br>=
No, they only need to know amplitude of error.</div></div></blockquote><div=
><br></div><div>Why do you think you can tell people what they need?</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>And if s=
omeone give them tool with greater accuracy ("secret" extended ty=
pe) they will be more than pleased. All equalities that they use still hold=
s for for it.<br></div></div></blockquote><div><br></div><div>That is simpl=
y false.=C2=A0 Floating-point arithmetic involves performing exactly define=
d operations on rational numbers, and that can be used in proofs - for exam=
ple, I know that an arbitrary float can be written exactly in decimal using=
no more than 150 digits.=C2=A0 That matters, because I can rely on picking=
off that many digits and winding up with 0.=C2=A0 But if I get secret extr=
a precision, my result might in fact not be 0, and my code could wind up be=
ing drastically incorrect.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>But there is catch, they do not use bit equal. Eve=
n funnier FMA is used to recreate calculation in in greater accuracy that i=
s equal if compiler is allowed to use greater accuracy than storage type ha=
ve.<br>This mean you get result of this paper in C++ for free.</div></div><=
/blockquote><div><br></div><div>They analyze results based on knowing exact=
ly what the arithmetic does.=C2=A0 You can't get the result for free in=
C++ if your language definition can't tell you exactly what the arithm=
etic does.=C2=A0</div></div></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/CAHSYqdZCn-jwpLRjyg%3DgBHG%2B2mns2v6W=
epHsdcX7kACQmLm9fQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZCn-jw=
pLRjyg%3DgBHG%2B2mns2v6WepHsdcX7kACQmLm9fQ%40mail.gmail.com</a>.<br />
--001a114c843a0170010537ea786d--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 18 Jul 2016 11:29:08 -0400
Raw View
--001a1144db3e3fd2570537eaa28a
Content-Type: text/plain; charset=UTF-8
On Sun, Jul 17, 2016 at 9:23 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> How can one trust the order is right (read: intended) without even knowing
> it?
>
Because the code works.
Who can guarantee the *behavior *can be observed immediately? And who can
> guarantee at once the behavior is expected, the program will behave
> expected at any cases?
>
That is a meaningless question. It can be asked of any program at all.
> I don't see it in the standard or documentation of any implementation. Why
> "then it will work forever"?
>
You don't see what?
It is actually harder to learn when not all C and C++ dialects does not
> synchronized yet. It's even more trivially easy (and more universal) to
> learn that you should not touch what you does not depend on and keep away
> bad styles.
>
This is again a meaningless observation. Any time a language standard is
updated, programmers need to learn what the new things are, and they may
not be able to use the new things when dealing with old dialects. So this
is merely an argument for never changing the languages at all (which is
perhaps not a bad idea).
Certain things are called "bad style" only because they interact with flaws
in the language definition. When the language is fixed, they should no
longer be "bad style" but many people will have internalized the notion to
such an extent that they will not be able to get over it.
Left-to-right evaluation order is less affected by all of this, because it
would be strictly backwards-compatible. Programmers conscious of the issue
can continue to avoid order dependency if they need to use old systems.
New programmers writing for old systems can learn the hard way as they do
now. And all programmers will benefit when writing for new systems by not
having latent order-dependent errors.
--
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/CAHSYqdbfY4ZH-iy1nh3LWOb2bNZ2Q0m1emsG-rJ4Oq7CU1p_UA%40mail.gmail.com.
--001a1144db3e3fd2570537eaa28a
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 S=
un, Jul 17, 2016 at 9:23 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>How can=
one trust the order is right (read: intended) without even knowing it?<br>=
</div></div></blockquote><div><br></div><div>Because the code works.</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Who can =
guarantee the <i>behavior </i>can be observed immediately? And who can guar=
antee at once the behavior is expected, the program will behave expected at=
any cases?</div></div></blockquote><div><br></div><div>That is a meaningle=
ss question.=C2=A0 It can be asked of any program at all.</div><div>=C2=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> I don't =
see it in the standard or documentation of any implementation. Why "th=
en it will work forever"?<br></div></div></blockquote><div><br></div><=
div>You don't see what?</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>It is actually harder to learn when not all C and=
C++ dialects does not synchronized yet. It's even more trivially easy =
(and more universal) to learn that you should not touch what you does not d=
epend on and keep away bad styles.</div></div></blockquote><div><br></div><=
div>This is again a meaningless observation.=C2=A0 Any time a language stan=
dard is updated, programmers need to learn what the new things are, and the=
y may not be able to use the new things when dealing with old dialects.=C2=
=A0 So this is merely an argument for never changing the languages at all (=
which is perhaps not a bad idea).<br><br>Certain things are called "ba=
d style" only because they interact with flaws in the language definit=
ion.=C2=A0 When the language is fixed, they should no longer be "bad s=
tyle" but many people will have internalized the notion to such an ext=
ent that they will not be able to get over it.</div><div><br>Left-to-right =
evaluation order is less affected by all of this, because it would be stric=
tly backwards-compatible.=C2=A0 Programmers conscious of the issue can cont=
inue to avoid order dependency if they need to use old systems.=C2=A0 New p=
rogrammers writing for old systems can learn the hard way as they do now.=
=C2=A0 And all programmers will benefit when writing for new systems by not=
having latent order-dependent errors.</div><div><br></div><div>=C2=A0</div=
></div></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/CAHSYqdbfY4ZH-iy1nh3LWOb2bNZ2Q0m1emsG=
-rJ4Oq7CU1p_UA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbfY4ZH-iy1=
nh3LWOb2bNZ2Q0m1emsG-rJ4Oq7CU1p_UA%40mail.gmail.com</a>.<br />
--001a1144db3e3fd2570537eaa28a--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 18 Jul 2016 11:36:16 -0400
Raw View
--001a114c843ac51e9e0537eabb20
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 17, 2016 at 9:34 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> In this case, one piece of language design has sent thousands of
>> programmers down the garden path. That is bad design.
>>
> Those programmers are not expected to be users. You show no evidence on
> "bad" again.
>
Programmers are users of the language design. If there is evidence that
programmers make the same errors over and over again because they
misunderstand some aspect of the language then blaming the language is
reasonable.
--=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/CAHSYqdaHG_KyJRLttK1jANkHJk7HAwx-0Sx5yE5oMZZi8p%=
3Dzvw%40mail.gmail.com.
--001a114c843ac51e9e0537eabb20
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 S=
un, Jul 17, 2016 at 9:34 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"m=
ailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>>=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 20=
16=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=
=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<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 class=3D"gmail_quote=
"><div>In this case, one piece of language design has sent thousands of pro=
grammers down the garden path.=C2=A0 That is bad design.=C2=A0</div></div><=
/div></div></blockquote><div>Those programmers are not expected to be users=
.. You show no evidence on "bad" again.</div></div></blockquote><d=
iv><br></div><div>Programmers are users of the language design.=C2=A0 If th=
ere is evidence that programmers make the same errors over and over again b=
ecause they misunderstand some aspect of the language then blaming the lang=
uage is reasonable.</div></div></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/CAHSYqdaHG_KyJRLttK1jANkHJk7HAwx-0Sx5=
yE5oMZZi8p%3Dzvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaHG_KyJR=
LttK1jANkHJk7HAwx-0Sx5yE5oMZZi8p%3Dzvw%40mail.gmail.com</a>.<br />
--001a114c843ac51e9e0537eabb20--
.
Author: inkwizytoryankes@gmail.com
Date: Mon, 18 Jul 2016 13:29:09 -0700 (PDT)
Raw View
------=_Part_4231_171108744.1468873749551
Content-Type: multipart/alternative;
boundary="----=_Part_4232_2139893991.1468873749558"
------=_Part_4232_2139893991.1468873749558
Content-Type: text/plain; charset=UTF-8
On Monday, July 18, 2016 at 5:17:40 PM UTC+2, Hyman Rosen wrote:
>
> On Fri, Jul 15, 2016 at 8:31 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>>
>> I need 1 / 3, can you provide me one if it can't exists?
>>
>
> Sure. Use std::ratio<1,3> if you need exactly 1/3. If your needs allow
> you to use a number close to 1/3 but not equal to it, you can use 1/3. or
> 1/3.f.
>
>
Isn't this contradicting to that you say before? My whole point is that
float numbers are "close" to real number values and all result are "close"
to real result.
And now if I want compare this 1/3 to result of some float point operations
(this why I need it), then I should use "close" equal not bit equal that
you think is right thing.
> I need choose one that always will have rounding error.
>> And now I would like to have 1 / 9. I can choose again but what happens
>> with equality 1 / 9 * 3 == 1 / 3? It can't be true for bit pattern equality.
>> EVERY floating point operation have build in rounding errors. Even add
>> can give "correct" results only when you add numbers of equal exponent.
>>
>
> The arithmetic of floating-point always yields the nearest representable
> result to the correct value. The rounding error is the difference between
> those two. Sometimes the rounding error is 0, and often it is not.
>
>
No. If some floating point operation generate some difference between
correct value and representable value then final result can be wrong on any
scale you want.
Simply image adding million times value that should be zero but because of
limiting accuracy of floating points became greater than zero.
Example: http://melpon.org/wandbox/permlink/UDPx1nx78rgqZQAb
#include<iostream>
float d = 0.00323f;
float x = 15011.0f;
float y = (x * d / d);
int main()
{
std::cout << std::hexfloat << x << "\n";
std::cout << d << "\n";
std::cout << y << "\n";
std::cout << (x - y) << "\n";
return (x) == y;
}
For gcc on wandbox this return 0 and diff equal "0x1p-10". Now multiply by
1024 and you have `1.f`.
But whole point of this is to have better accuracy than otherwise possible.
>> Your "error" is value that is closer to real number value that you suppose
>> to get. You can't store it but you can continue calculating based on it.
>>
>
> That's half the point. The other half of the point is to have
> deterministic arithmetic. When the very same calculation (in both cases, I
> am dividing 1 by 3) produces different results, it is difficult to reason
> about what code does. It is exactly as if 2 + 2 sometimes produced 5.
> When doing things like converting numbers between bases, or doing range
> reduction for mathematical functions, knowing exactly what the arithmetic
> will do is important. We wind up with code sprinkled with 'volatile float'
> and 'volatile double' to force proper rounding.
>
> I suppose that's OK - it makes the people who need the exactness pay for
> it and lets everyone else get expression results maybe a little closer to
> the exact answer than they otherwise would be, but it's messy and awkward.
>
>
You only show that you use it incorrectly.
> Sometimes people need to know
>>> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.9012&rep=rep1&type=pdf> exactly
>>> what their arithmetic is doing.
>>>
>>
>> No, they only need to know amplitude of error.
>>
>
> Why do you think you can tell people what they need?
>
>
Because they define that in they paper? Didn't they?
> And if someone give them tool with greater accuracy ("secret" extended
>> type) they will be more than pleased. All equalities that they use still
>> holds for for it.
>>
>
> That is simply false. Floating-point arithmetic involves performing
> exactly defined operations on rational numbers, and that can be used in
> proofs - for example, I know that an arbitrary float can be written exactly
> in decimal using no more than 150 digits. That matters, because I can rely
> on picking off that many digits and winding up with 0. But if I get secret
> extra precision, my result might in fact not be 0, and my code could wind
> up being drastically incorrect.
>
>
First floating-points numbers aren't even numbers in mathematical sense.
What is zero element in it? It could be 0.001 or 10 depending what big
number you try add to. Only when you calculate errors you can use for
numerical calculations.
Second, what is exactly mass of electron? Or mass of some object? Or
position of something (quantum physics anyone?)? You can't know exactly.
And if you have errors in input then you will have error in output. I don't
know why you want compare to have any meaning if some bits are effective
random? Science can work easy with that because they calculate errors and
know how good result is.
> But there is catch, they do not use bit equal. Even funnier FMA is used to
>> recreate calculation in in greater accuracy that is equal if compiler is
>> allowed to use greater accuracy than storage type have.
>> This mean you get result of this paper in C++ for free.
>>
>
> They analyze results based on knowing exactly what the arithmetic does.
> You can't get the result for free in C++ if your language definition can't
> tell you exactly what the arithmetic does.
>
Did you even read this paper? In multiple places they explicitly estimate
error of used arithmetic. This mean if you give them something with less
error then all logic still holds.
Even pure mathematic use same approach, because you can't know value of
e^pi or pi^e (this are EXTREME trivial examples), many times this is simply
avoided by using bigger number like e^pi < 3^4 and then I only use this
bigger number to prove something.
--
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/d4a5da92-9a03-41e2-8cae-f9a91e329c3d%40isocpp.org.
------=_Part_4232_2139893991.1468873749558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, July 18, 2016 at 5:17:40 PM UTC+2, Hyma=
n Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 8:31 PM, <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"1Zt5ctSFDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">inkwizyt...@gmail.com</a>></span> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>I need 1 / 3, can you provide me one if it ca=
n't exists?</div></div></blockquote><div><br></div><div>Sure.=C2=A0 Use=
std::ratio<1,3> if you need exactly 1/3.=C2=A0 If your needs allow y=
ou to use a number close to 1/3 but not equal to it, you can use <font face=
=3D"monospace, monospace">1/3.</font> or <font face=3D"monospace, monospace=
">1/3.f</font>.</div><div>=C2=A0<br></div></div></div></div></blockquote><d=
iv><br>Isn't this contradicting to that you say before? My whole point =
is that float numbers are "close" to real number values and all r=
esult are "close" to real result.<br>And now if I want compare th=
is 1/3 to result of some float point operations (this why I need it), then =
I should use "close" equal not bit equal that you think is right =
thing.<br>=C2=A0</div><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 class=3D"gmail_quote"><div></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div> I need choose one that always will have roun=
ding error.<br>And now I would like to have 1 / 9. I can choose again but w=
hat happens with equality 1 / 9 * 3 =3D=3D 1 / 3? It can't be true for =
bit pattern equality.<br>EVERY floating point operation have build in round=
ing errors. Even=20
add can give "correct" results only when you add numbers of equal=
=20
exponent.<br></div></div></blockquote><div><br></div><div>The arithmetic of=
floating-point always yields the nearest representable result to the corre=
ct value.=C2=A0 The rounding error is the difference between those two.=C2=
=A0 Sometimes the rounding error is 0, and often it is not.</div><div><br><=
/div></div></div></div></blockquote><div><br>No. If some floating point ope=
ration generate some difference between correct value and representable val=
ue then final result can be wrong on any scale you want.<br>Simply image ad=
ding million times value that should be zero but because of limiting accura=
cy of floating points became greater than zero.<br>Example: http://melpon.o=
rg/wandbox/permlink/UDPx1nx78rgqZQAb<br><br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800=
;" class=3D"styled-by-prettify">#include</span><span style=3D"color: #080;"=
class=3D"styled-by-prettify"><iostream></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">float</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">0.00323f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">15011.0f</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> y </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">x </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">/</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> d</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">hexfloat </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><<</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">"\n"</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> d =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">"\n"</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> y </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">"\n"</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cl=
ass=3D"styled-by-prettify">"\n"</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span></div></code></div>For gcc on wandb=
ox this return 0 and diff equal "0x1p-10". Now multiply by 1024 a=
nd you have `1.f`.<br><br><br><br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>But whole point of this=
is to have better accuracy than otherwise possible. Your "error"=
is value that is closer to real number value that you suppose to get. You =
can't store it but you can continue calculating based on it.<br></div><=
/div></blockquote><div><br></div><div>That's half the point.=C2=A0 The =
other half of the point is to have deterministic arithmetic.=C2=A0 When the=
very same calculation (in both cases, I am dividing 1 by 3) produces diffe=
rent results, it is difficult to reason about what code does.=C2=A0 It is e=
xactly as if 2 + 2 sometimes produced 5.=C2=A0 When doing things like conve=
rting numbers between bases, or doing range reduction for mathematical func=
tions, knowing exactly what the arithmetic will do is important.=C2=A0 We w=
ind up with code sprinkled with 'volatile float' and 'volatile =
double' to force proper rounding.<br><br>I suppose that's OK - it m=
akes the people who need the exactness pay for it and lets everyone else ge=
t expression results maybe a little closer to the exact answer than they ot=
herwise would be, but it's messy and awkward.</div><div><br></div></div=
></div></div></blockquote><div><br>You only show that you use it incorrectl=
y.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>Sometimes people <a href=3D"h=
ttp://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.123.9012&rep=
=3Drep1&type=3Dpdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fciteseerx.ist.p=
su.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.123.9012%26rep%3Drep1%26type%3Dp=
df\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJUdF15GsBIuAe3oxiNbWceQFmCg'=
;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3d=
http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.123.=
9012%26rep%3Drep1%26type%3Dpdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJUd=
F15GsBIuAe3oxiNbWceQFmCg';return true;">need to know</a>=C2=A0exactly w=
hat their arithmetic is doing.=C2=A0</div></div></div></div></blockquote></=
span><div>=C2=A0<br>No, they only need to know amplitude of error.</div></d=
iv></blockquote><div><br></div><div>Why do you think you can tell people wh=
at they need?</div><div><br></div></div></div></div></blockquote><div><br>B=
ecause they define that in they paper? Didn't they?<br>=C2=A0</div><blo=
ckquote 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 class=
=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>And if someone give them tool with greater accuracy ("secret&quo=
t; extended type) they will be more than pleased. All equalities that they =
use still holds for for it.<br></div></div></blockquote><div><br></div><div=
>That is simply false.=C2=A0 Floating-point arithmetic involves performing =
exactly defined operations on rational numbers, and that can be used in pro=
ofs - for example, I know that an arbitrary float can be written exactly in=
decimal using no more than 150 digits.=C2=A0 That matters, because I can r=
ely on picking off that many digits and winding up with 0.=C2=A0 But if I g=
et secret extra precision, my result might in fact not be 0, and my code co=
uld wind up being drastically incorrect.</div><div><br></div></div></div></=
div></blockquote><div><br>First floating-points numbers aren't even num=
bers in mathematical sense. What is zero element in it? It could be 0.001 o=
r 10 depending what big number you try add to. Only when you calculate erro=
rs you can use for numerical calculations.<br>Second, what is exactly mass =
of electron? Or mass of some object? Or position of something (quantum phys=
ics anyone?)? You can't know exactly. And if you have errors in input t=
hen you will have error in output. I don't know why you want compare to=
have any meaning if some bits are effective random? Science can work easy =
with that because they calculate errors and know how good result is.<br><br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>But there is catch, they do not use bit equal. Even fu=
nnier FMA is used to recreate calculation in in greater accuracy that is eq=
ual if compiler is allowed to use greater accuracy than storage type have.<=
br>This mean you get result of this paper in C++ for free.</div></div></blo=
ckquote><div><br></div><div>They analyze results based on knowing exactly w=
hat the arithmetic does.=C2=A0 You can't get the result for free in C++=
if your language definition can't tell you exactly what the arithmetic=
does.=C2=A0</div></div></div></div></blockquote><div><br>Did you even read=
this paper? In multiple places they explicitly estimate error of used arit=
hmetic. This mean if you give them something with less error then all logic=
still holds.<br>Even pure mathematic use same approach, because you can=
9;t know value of e^pi or pi^e (this are EXTREME trivial examples), many ti=
mes this is simply avoided by using bigger number like e^pi < 3^4 and th=
en I only use this bigger number to prove something.<br></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/d4a5da92-9a03-41e2-8cae-f9a91e329c3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d4a5da92-9a03-41e2-8cae-f9a91e329c3d=
%40isocpp.org</a>.<br />
------=_Part_4232_2139893991.1468873749558--
------=_Part_4231_171108744.1468873749551--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 19 Jul 2016 01:24:07 +0100
Raw View
--001a114109b85c706d0537f21a94
Content-Type: text/plain; charset=UTF-8
On 18 Jul 2016 4:29 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
>
> On Sun, Jul 17, 2016 at 9:23 PM, FrankHB1989 <frankhb1989@gmail.com>
wrote:
>>
>> How can one trust the order is right (read: intended) without even
knowing it?
>
>
> Because the code works.
Programming by permutation does not yield working code. It yields fragile,
broken code that appears to work initially, but that may not work on all
inputs and certainly that cannot be modified for fear that it will stop
working.
>> Who can guarantee the behavior can be observed immediately? And who can
guarantee at once the behavior is expected, the program will behave
expected at any cases?
>
>
> That is a meaningless question. It can be asked of any program at all.
Not at all; programs can be proved correct.
> Left-to-right evaluation order is less affected by all of this, because
it would be strictly backwards-compatible. Programmers conscious of the
issue can continue to avoid order dependency if they need to use old
systems. New programmers writing for old systems can learn the hard way as
they do now. And all programmers will benefit when writing for new systems
by not having latent order-dependent errors.
That's not true at all. Code that accidentally targets anything other than
LTR would stop working in an LTR world. It would make it impossible to
combine old and new code for fear of order incompatibility, meaning total
forward and backward incompatibility.
--
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/CAJnLdObEv617LYc2xCFxXcsyqFEug4jeQ-S_uTGZLPXc_TBwAA%40mail.gmail.com.
--001a114109b85c706d0537f21a94
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 18 Jul 2016 4:29 p.m., "Hyman Rosen" <<a hre=
f=3D"mailto:hyman.rosen@gmail.com">hyman.rosen@gmail.com</a>> wrote:<br>
><br>
> On Sun, Jul 17, 2016 at 9:23 PM, FrankHB1989 <<a href=3D"mailto:fra=
nkhb1989@gmail.com">frankhb1989@gmail.com</a>> wrote:<br>
>><br>
>> How can one trust the order is right (read: intended) without even=
knowing it?<br>
><br>
><br>
> Because the code works.</p>
<p dir=3D"ltr">Programming by permutation does not yield working code. It y=
ields fragile, broken code that appears to work initially, but that may not=
work on all inputs and certainly that cannot be modified for fear that it =
will stop working. </p>
<p dir=3D"ltr">>> Who can guarantee the behavior can be observed imme=
diately? And who can guarantee at once the behavior is expected, the progra=
m will behave expected at any cases?<br>
><br>
><br>
> That is a meaningless question.=C2=A0 It can be asked of any program a=
t all.</p>
<p dir=3D"ltr">Not at all; programs can be proved correct. </p>
<p dir=3D"ltr">> Left-to-right evaluation order is less affected by all =
of this, because it would be strictly backwards-compatible.=C2=A0 Programme=
rs conscious of the issue can continue to avoid order dependency if they ne=
ed to use old systems.=C2=A0 New programmers writing for old systems can le=
arn the hard way as they do now.=C2=A0 And all programmers will benefit whe=
n writing for new systems by not having latent order-dependent errors.</p>
<p dir=3D"ltr">That's not true at all. Code that accidentally targets a=
nything other than LTR would stop working in an LTR world. It would make it=
impossible to combine old and new code for fear of order incompatibility, =
meaning total forward and backward incompatibility. </p>
<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/CAJnLdObEv617LYc2xCFxXcsyqFEug4jeQ-S_=
uTGZLPXc_TBwAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObEv617LYc2=
xCFxXcsyqFEug4jeQ-S_uTGZLPXc_TBwAA%40mail.gmail.com</a>.<br />
--001a114109b85c706d0537f21a94--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 18 Jul 2016 22:02:02 -0700 (PDT)
Raw View
------=_Part_1546_185173530.1468904522834
Content-Type: multipart/alternative;
boundary="----=_Part_1547_2108965483.1468904522834"
------=_Part_1547_2108965483.1468904522834
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=8810:36:38=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Fri, Jul 15, 2016 at 6:55 PM, 'Edward Catmur' via ISO C++ Standard -=
=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> On 15 Jul 2016 9:38 p.m., "Hyman Rosen" <hyman...@gmail.com <javascript:=
>>=20
>> wrote:
>> > Programming languages are designed to control computers. =20
>>
>> How could that be possible, when a computer program can be run on a=20
>> computer that did not exist and had not been designed at the time the=20
>> program was written or compiled?
>>
> Because the computers are essentially the same. When they're not=20
> (segmented architectures, no stacks, lisp machines) it is difficult to=20
> translate the program to model the abstract machine. Often the=20
> architecture leaks back into the language - near/far/huge pointers,=20
> extended-precision intermediate floating point, and undefined behavior fo=
r=20
> reading a variable containing an invalid pointer are just a few examples.
>
That's not true. Interface of language may have nothing to do with any=20
concrete "computer". The abstraction leaks because it is designed badly. At=
=20
least specifiers like near/far/huge can be hidden totally when you do not=
=20
care. However, when you care, you will have less portability. Undefined=20
behavior is like so.
Provided these features may be useful in specific cases, simply remove them=
=20
away totally from every dialects is not acceptable by users. So it is the=
=20
users' responsibility to keep things not portable away. Any ("standard")=20
language without undefined behavior or similar "extension" mechanism is=20
practically flawed in this aspect.
--=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/b5b3c563-4cee-414d-931f-9e15a7668930%40isocpp.or=
g.
------=_Part_1547_2108965483.1468904522834
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8818=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8810:36:38=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 6:55 =
PM, 'Edward Catmur' via ISO C++ Standard - Future Proposals <span d=
ir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"WPxOPZeDDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">std-pr...@isocpp.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span><p dir=3D"ltr"></p>
<p dir=3D"ltr">On 15 Jul 2016 9:38 p.m., "Hyman Rosen" <<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WPxOPZeDDAAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">hyman...@gm=
ail.com</a>> wrote:<br>
> Programming languages are designed to control computers.=C2=A0 </p>
</span><p dir=3D"ltr">How could that be possible, when a computer program c=
an be run on a computer that did not exist and had not been designed at the=
time the program was written or compiled?</p></blockquote><div>Because the=
computers are essentially the same.=C2=A0 When they're not (segmented =
architectures, no stacks, lisp machines) it is difficult to translate the p=
rogram to model the abstract machine.=C2=A0 Often the architecture leaks ba=
ck into the language - near/far/huge pointers, extended-precision intermedi=
ate floating point, and undefined behavior for reading a variable containin=
g an invalid pointer are just a few examples.</div></div></div></div></bloc=
kquote><div><br>That's not true. Interface of language may have nothing=
to do with any concrete "computer". The abstraction leaks becaus=
e it is designed badly. At least specifiers like near/far/huge can be hidde=
n totally when you do not care. However, when you care, you will have less =
portability. Undefined behavior is like so.<br>Provided these features may =
be useful in specific cases, simply remove them away totally from every dia=
lects is not acceptable by users. So it is the users' responsibility to=
keep things not portable away. Any ("standard") language without=
undefined behavior or similar "extension" mechanism is practical=
ly flawed in this aspect.<br><br><br></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/b5b3c563-4cee-414d-931f-9e15a7668930%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5b3c563-4cee-414d-931f-9e15a7668930=
%40isocpp.org</a>.<br />
------=_Part_1547_2108965483.1468904522834--
------=_Part_1546_185173530.1468904522834--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 18 Jul 2016 22:33:05 -0700 (PDT)
Raw View
------=_Part_872_1834734489.1468906386026
Content-Type: multipart/alternative;
boundary="----=_Part_873_300317248.1468906386026"
------=_Part_873_300317248.1468906386026
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=8811:29:28=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sun, Jul 17, 2016 at 9:23 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> How can one trust the order is right (read: intended) without even=20
>> knowing it?
>>
>
> Because the code works.
>
How can you know the code just "works", by testing? Or something else to=20
ensure the code is bug free?
I don't think you can even make the coverage itself trustworthy without=20
some extraordinary means.
=20
>
> Who can guarantee the *behavior *can be observed immediately? And who can=
=20
>> guarantee at once the behavior is expected, the program will behave=20
>> expected at any cases?
>>
>
> That is a meaningless question. It can be asked of any program at all.
>
So do you admit no one can guarantee?
=20
> =20
>
>> I don't see it in the standard or documentation of any implementation.=
=20
>> Why "then it will work forever"?
>>
>
> You don't see what?
>
> Something to guarantee your assumption is true.
=20
> It is actually harder to learn when not all C and C++ dialects does not=
=20
>> synchronized yet. It's even more trivially easy (and more universal) to=
=20
>> learn that you should not touch what you does not depend on and keep awa=
y=20
>> bad styles.
>>
>
> This is again a meaningless observation. Any time a language standard is=
=20
> updated, programmers need to learn what the new things are, and they may=
=20
> not be able to use the new things when dealing with old dialects. So thi=
s=20
> is merely an argument for never changing the languages at all (which is=
=20
> perhaps not a bad idea).
>
That's simply not true. Programmers do not need to learn new things just=20
because the language standard is updated. They learn new things because new=
=20
things are necessary or at least helpful to their work. Before confirming=
=20
of that, they should stick on specific set of things they used. Even=20
learned some new things, they do need to use them because they learned=20
them. They should determine whether the new things is worthy being applied=
=20
in their work. In this process they can know what is generally bad.=20
>
> Certain things are called "bad style" only because they interact with=20
> flaws in the language definition. When the language is fixed, they shoul=
d=20
> no longer be "bad style" but many people will have internalized the notio=
n=20
> to such an extent that they will not be able to get over it.
>
This is a chicken and egg problem if you still reason it from the language=
=20
itself. Assertion the language is flawed is not more obvious than assertion=
=20
the style is bad in your way. I conclude bad styles from the need behind=20
the use cases, and if the design of the language does not catch up the=20
need, it should be changed. But this is not the case here. There is no need=
=20
to talk about the language yet, because the style to "chaining something"=
=20
to make *anything *work, is technically unsound *in general*. It is one of=
=20
the method that may or may not work. (Note it "works" not only to produce=
=20
expected observable behavior in limited testable cases, but also to provide=
=20
something more.) On the contrary, most cases have better solution.
There is another notable (in)famous example: OOP.
I can imagine people are reluctant to find the solution most fit to their=
=20
problems when they already have a "universal" one, but that's essentially=
=20
wrong. One of the duty of a programmer is to make choice to keep=20
over-universal things (which cannot serve the need well enough) away from=
=20
the products used by others. There is no excuse to defend the largely=20
half-baked results unless there is external force majeure; the work just=20
has not been rightly completed.
> Left-to-right evaluation order is less affected by all of this, because i=
t=20
> would be strictly backwards-compatible. Programmers conscious of the iss=
ue=20
> can continue to avoid order dependency if they need to use old systems. =
=20
> New programmers writing for old systems can learn the hard way as they do=
=20
> now. And all programmers will benefit when writing for new systems by no=
t=20
> having latent order-dependent errors.
>
> =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/18de17e8-f4e7-41c9-8d6b-1e17a79b7b48%40isocpp.or=
g.
------=_Part_873_300317248.1468906386026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8818=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8811:29:28=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Sun, Jul 17, 2016 at 9:23 =
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"ANWQX3mGDAAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>How can one trust the or=
der is right (read: intended) without even knowing it?<br></div></div></blo=
ckquote><div><br></div><div>Because the code works.</div></div></div></div>=
</blockquote><div>How can you know the code just "works", by test=
ing? Or something else to ensure the code is bug free?<br>I don't think=
you can even make the coverage itself <span class=3D"op_dict3_font24 op_di=
ct3_marginRight">trustworthy</span> without some extraordinary means.<br>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Who can guarantee the <i>behavior </i>can be ob=
served immediately? And who can guarantee at once the behavior is expected,=
the program will behave expected at any cases?</div></div></blockquote><di=
v><br></div><div>That is a meaningless question.=C2=A0 It can be asked of a=
ny program at all.</div></div></div></div></blockquote><div>So do you admit=
no one can guarantee?<br>=C2=A0<br></div><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 class=3D"gmail_quote"><div>=C2=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> I don't se=
e it in the standard or documentation of any implementation. Why "then=
it will work forever"?<br></div></div></blockquote><div><br></div><di=
v>You don't see what?</div><div><br></div></div></div></div></blockquot=
e><div>Something to guarantee your assumption is true.<br>=C2=A0<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>It is actually harder to learn when not all C and C++ dialects does =
not synchronized yet. It's even more trivially easy (and more universal=
) to learn that you should not touch what you does not depend on and keep a=
way bad styles.</div></div></blockquote><div><br></div><div>This is again a=
meaningless observation.=C2=A0 Any time a language standard is updated, pr=
ogrammers need to learn what the new things are, and they may not be able t=
o use the new things when dealing with old dialects.=C2=A0 So this is merel=
y an argument for never changing the languages at all (which is perhaps not=
a bad idea).</div></div></div></div></blockquote><div>That's simply no=
t true. Programmers do not need to learn new things just because the langua=
ge standard is updated. They learn new things because new things are necess=
ary or at least helpful to their work. Before confirming of that, they shou=
ld stick on specific set of things they used. Even learned some new things,=
they do need to use them because they learned them. They should determine =
whether the new things is worthy being applied in their work. In this proce=
ss they can know what is generally bad. <br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><=
br>Certain things are called "bad style" only because they intera=
ct with flaws in the language definition.=C2=A0 When the language is fixed,=
they should no longer be "bad style" but many people will have i=
nternalized the notion to such an extent that they will not be able to get =
over it.</div></div></div></div></blockquote><div>This is a chicken and egg=
problem if you still reason it from the language itself. Assertion the lan=
guage is flawed is not more obvious than assertion the style is bad in your=
way. I conclude bad styles from the need behind the use cases, and if the =
design of the language does not catch up the need, it should be changed. Bu=
t this is not the case here. There is no need to talk about the language ye=
t, because the style to "chaining something" to make <i>anything =
</i>work, is technically unsound <i>in general</i>. It is one of the method=
that may or may not work. (Note it "works" not only to produce e=
xpected observable behavior in limited testable cases, but also to provide =
something more.) On the contrary, most cases have better solution.<br>There=
is another notable (in)famous example: OOP.<br>I can imagine people are re=
luctant to find the solution most fit to their problems when they already h=
ave a "universal" one, but that's essentially wrong. One of t=
he duty of a programmer is to make choice to keep over-universal things (wh=
ich cannot serve the need well enough) away from the products used by other=
s. There is no excuse to defend the largely half-baked results unless there=
is external force majeure; the work just has not been rightly completed.<b=
r><br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div><br>Left-to-right evaluation order =
is less affected by all of this, because it would be strictly backwards-com=
patible.=C2=A0 Programmers conscious of the issue can continue to avoid ord=
er dependency if they need to use old systems.=C2=A0 New programmers writin=
g for old systems can learn the hard way as they do now.=C2=A0 And all prog=
rammers will benefit when writing for new systems by not having latent orde=
r-dependent errors.</div><div><br></div><div>=C2=A0</div></div></div></div>
</blockquote></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/18de17e8-f4e7-41c9-8d6b-1e17a79b7b48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18de17e8-f4e7-41c9-8d6b-1e17a79b7b48=
%40isocpp.org</a>.<br />
------=_Part_873_300317248.1468906386026--
------=_Part_872_1834734489.1468906386026--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 18 Jul 2016 22:43:21 -0700 (PDT)
Raw View
------=_Part_639_1943482292.1468907001184
Content-Type: multipart/alternative;
boundary="----=_Part_640_458749464.1468907001185"
------=_Part_640_458749464.1468907001185
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=8811:36:37=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sun, Jul 17, 2016 at 9:34 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> In this case, one piece of language design has sent thousands of=20
>>> programmers down the garden path. That is bad design.=20
>>>
>> Those programmers are not expected to be users. You show no evidence on=
=20
>> "bad" again.
>>
>
> Programmers are users of the language design. If there is evidence that=
=20
> programmers make the same errors over and over again because they=20
> misunderstand some aspect of the language then blaming the language is=20
> reasonable.
>
This is logically problematic.
First, there is no language can be designed to fit everyone's need. It's=20
not doable. So there users will not be arbitrary set of persons, or even=20
"programmers".
Second, even if the target audience are mostly confused, the language is=20
not necessarily ill-designed. There should exist many things to attribute=
=20
before it, e.g. the education.
=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/323d7f22-00f4-4f9e-bb69-0a4937beb6cc%40isocpp.or=
g.
------=_Part_640_458749464.1468907001185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8818=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=8811:36:37=EF=BC=8CHyman Rosen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote">On Sun, Jul 17, 2016 at 9:34 =
PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"s4m7D92GDAAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">frank...@gmail.com</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=
=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=889:40:56=
=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>In this c=
ase, one piece of language design has sent thousands of programmers down th=
e garden path.=C2=A0 That is bad design.=C2=A0</div></div></div></div></blo=
ckquote><div>Those programmers are not expected to be users. You show no ev=
idence on "bad" again.</div></div></blockquote><div><br></div><di=
v>Programmers are users of the language design.=C2=A0 If there is evidence =
that programmers make the same errors over and over again because they misu=
nderstand some aspect of the language then blaming the language is reasonab=
le.</div></div></div></div></blockquote><div>This is logically problematic.=
<br>First, there is no language can be designed to fit everyone's need.=
It's not doable. So there users will not be arbitrary set of persons, =
or even "programmers".<br>Second, even if the target audience are=
mostly confused, the language is not necessarily ill-designed. There shoul=
d exist many things to attribute before it, e.g. the education.<br><br>=C2=
=A0<br></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/323d7f22-00f4-4f9e-bb69-0a4937beb6cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/323d7f22-00f4-4f9e-bb69-0a4937beb6cc=
%40isocpp.org</a>.<br />
------=_Part_640_458749464.1468907001185--
------=_Part_639_1943482292.1468907001184--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 19 Jul 2016 11:32:34 -0400
Raw View
--001a1144db3e6cb0040537feccf5
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 18, 2016 at 4:29 PM, <inkwizytoryankes@gmail.com> wrote:
>
> My whole point is that float numbers are "close" to real number values and
> all result are "close" to real result.
> And now if I want compare this 1/3 to result of some float point
> operations (this why I need it), then I should use "close" equal not bit
> equal that you think is right thing.
>
You may need to know that one number is close to three times another and
someone else may need to know that one number is exactly three times
another. If they do, it doesn't matter to them that you don't, and they're
going to need to know what floating-point arithmetic does in order to be
able to use it.
The arithmetic of floating-point always yields the nearest representable
>> result to the correct value. The rounding error is the difference between
>> those two. Sometimes the rounding error is 0, and often it is not.
>>
>
> No. If some floating point operation generate some difference between
> correct value and representable value then final result can be wrong on any
> scale you want.
> Simply image adding million times value that should be zero but because of
> limiting accuracy of floating points became greater than zero.
>
If you repeat an operation many times such that the rounded result is
always biased away from the actual result in the same direction, then you
will accumulate the repeated differences. If you want to analyze results
of such calculations, it helps to know what the calculations are supposed
to do.
> Example: http://melpon.org/wandbox/permlink/UDPx1nx78rgqZQAb
>
> #include<iostream>
> float d = 0.00323f;
> float x = 15011.0f;
> float y = (x * d / d);
> int main()
> {
> std::cout << std::hexfloat << x << "\n";
> std::cout << d << "\n";
> std::cout << y << "\n";
> std::cout << (x - y) << "\n";
> return (x) == y;
> }
> For gcc on wandbox this return 0 and diff equal "0x1p-10". Now multiply by
> 1024 and you have `1.f`.
>
In the following code, I need equality checks. Not approximate checks,
actual equality checks.
#include <stdio.h>
void shortest_decimal(float f, char *buf)
{
float r;
sprintf(buf, "%.6g", f); sscanf(buf, "%f", &r); if (r != f) {
sprintf(buf, "%.7g", f); sscanf(buf, "%f", &r); if (r != f) {
sprintf(buf, "%.8g", f); sscanf(buf, "%f", &r); if (r != f) {
sprintf(buf, "%.9g", f); }}}
}
You only show that you use it incorrectly.
>
Perhaps you would like to explain how my code above is using equality
incorrectly?
First floating-points numbers aren't even numbers in mathematical sense.
>
Floating-point numbers are a finite set of rational numbers plus a handful
of singular values. Of course they are numbers.
> What is zero element in it? It could be 0.001 or 10 depending what big
> number you try add to.
>
The arithmetic operations don't obey the usual algebraic structures of
group theory, but that doesn't make the values "not numbers" nor does it
mean that the results of operations are not exactly specified.
> Only when you calculate errors you can use for numerical calculations.
>
That depends on what you're doing. As you see from my code above, there
are things that can be done with floating-point without "calculating
errors".
Second, what is exactly mass of electron? Or mass of some object? Or
> position of something (quantum physics anyone?)? You can't know exactly.
> And if you have errors in input then you will have error in output. I don't
> know why you want compare to have any meaning if some bits are effective
> random? Science can work easy with that because they calculate errors and
> know how good result is.
>
Because not all calculation involves imprecisely known physical values.
Your bank account and credit card balances are exact, for example.
--
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/CAHSYqdapr1WMTCkrCAPSPHgzE7H0eE4XOeTgWL5j7KhzB%2BtUMA%40mail.gmail.com.
--001a1144db3e6cb0040537feccf5
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 M=
on, Jul 18, 2016 at 4:29 PM, <span dir=3D"ltr"><<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>>=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>My whole point is that=
float numbers are "close" to real number values and all result a=
re "close" to real result.<br>And now if I want compare this 1/3 =
to result of some float point operations (this why I need it), then I shoul=
d use "close" equal not bit equal that you think is right thing.<=
br></div></div></blockquote><div><br></div><div>You may need to know that o=
ne number is close to three times another and someone else may need to know=
that one number is exactly three times another.=C2=A0 If they do, it doesn=
't matter to them that you don't, and they're going to need to =
know what floating-point arithmetic does in order to be able to use it.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The arithme=
tic of floating-point always yields the nearest representable result to the=
correct value.=C2=A0 The rounding error is the difference between those tw=
o.=C2=A0 Sometimes the rounding error is 0, and often it is not.</div></div=
></div></div></blockquote></span><div><br>No. If some floating point operat=
ion generate some difference between correct value and representable value =
then final result can be wrong on any scale you want.<br>Simply image addin=
g million times value that should be zero but because of limiting accuracy =
of floating points became greater than zero.<br></div></div></blockquote><d=
iv><br></div><div>If you repeat an operation many times such that the round=
ed result is always biased away from the actual result in the same directio=
n, then you will accumulate the repeated differences.=C2=A0 If you want to =
analyze results of such calculations, it helps to know what the calculation=
s are supposed to do.</div><div><br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div>Example: <a href=3D"http://melpon.org/wandbox/permli=
nk/UDPx1nx78rgqZQAb" target=3D"_blank">http://melpon.org/wandbox/permlink/U=
DPx1nx78rgqZQAb</a><br><br><div style=3D"border:1px solid rgb(187,187,187);=
word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span st=
yle=3D"color:rgb(136,0,0)">#include</span><span style=3D"color:rgb(0,136,0)=
"><iostream></span><span style=3D"color:rgb(0,0,0)"><br></span><span =
style=3D"color:rgb(0,0,136)">float</span><span style=3D"color:rgb(0,0,0)"> =
d </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"colo=
r:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">0.00323f</span><=
span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)=
"><br></span><span style=3D"color:rgb(0,0,136)">float</span><span style=3D"=
color:rgb(0,0,0)"> x </span><span style=3D"color:rgb(102,102,0)">=3D</span>=
<span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102=
)">15011.0f</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">float</=
span><span style=3D"color:rgb(0,0,0)"> y </span><span style=3D"color:rgb(10=
2,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">x </span><s=
pan style=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"=
> d </span><span style=3D"color:rgb(102,102,0)">/</span><span style=3D"colo=
r:rgb(0,0,0)"> d</span><span style=3D"color:rgb(102,102,0)">);</span><span =
style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">in=
t</span><span style=3D"color:rgb(0,0,0)"> main</span><span style=3D"color:r=
gb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></span><span s=
tyle=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span=
style=3D"color:rgb(0,0,0)">cout </span><span style=3D"color:rgb(102,102,0)=
"><<</span><span style=3D"color:rgb(0,0,0)"> std</span><span style=3D=
"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">hexfloat <=
/span><span style=3D"color:rgb(102,102,0)"><<</span><span style=3D"co=
lor:rgb(0,0,0)"> x </span><span style=3D"color:rgb(102,102,0)"><<</sp=
an><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,136,=
0)">"\n"</span><span style=3D"color:rgb(102,102,0)">;</span><span=
style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><span style=3D"colo=
r:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">cout </span><sp=
an style=3D"color:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0=
,0,0)"> d </span><span style=3D"color:rgb(102,102,0)"><<</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,136,0)">"=
;\n"</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D=
"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:rgb(102=
,102,0)">::</span><span style=3D"color:rgb(0,0,0)">cout </span><span style=
=3D"color:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"> =
y </span><span style=3D"color:rgb(102,102,0)"><<</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,136,0)">"\n"=
;</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:r=
gb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:rgb(102,102,0)"=
>::</span><span style=3D"color:rgb(0,0,0)">cout </span><span style=3D"color=
:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)"=
>x </span><span style=3D"color:rgb(102,102,0)">-</span><span style=3D"color=
:rgb(0,0,0)"> y</span><span style=3D"color:rgb(102,102,0)">)</span><span st=
yle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"><&=
lt;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(0,136,0)">"\n"</span><span style=3D"color:rgb(102,102,0)">;</spa=
n><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> </span><=
span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)=
">x</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">=3D=3D</span><spa=
n style=3D"color:rgb(0,0,0)"> y</span><span style=3D"color:rgb(102,102,0)">=
;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rg=
b(102,102,0)">}</span></div></code></div>For gcc on wandbox this return 0 a=
nd diff equal "0x1p-10". Now multiply by 1024 and you have `1.f`.=
</div></div></blockquote><div><br></div><div>In the following code, I need =
equality checks.=C2=A0 Not approximate checks, actual equality checks.</div=
><div><br><div><font face=3D"monospace, monospace">#include <stdio.h>=
</font></div><div><span style=3D"font-family:monospace,monospace">void shor=
test_decimal(float f, char *buf)</span><br></div><div><font face=3D"monospa=
ce, monospace">{</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 float r;</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 sprintf(buf, "%.6g", f); sscanf(buf, "%f"=
, &r); if (r !=3D f) {</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 sprintf(buf, "%.7g", f); sscanf(buf, "%f&=
quot;, &r); if (r !=3D f) {</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 sprintf(buf, "%.8g", f); sscanf(buf, &quo=
t;%f", &r); if (r !=3D f) {</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.9g", f); }}}</font><=
/div><div><font face=3D"monospace, monospace">}</font></div></div><div><fon=
t face=3D"monospace, monospace"><br></font></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>You only show that you use it incorrectly.<br></div></div></b=
lockquote><div><br></div><div>Perhaps you would like to explain how my code=
above is using equality incorrectly?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>First floating-points numbers aren't even numbers=
in mathematical sense.</div></div></blockquote><div><br></div><div>Floatin=
g-point numbers are a finite set of rational numbers plus a handful of sing=
ular values.=C2=A0 Of course they are numbers.</div><div>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div> What is zero element in it? It could =
be 0.001 or 10 depending what big number you try add to.</div></div></block=
quote><div><br></div><div>The arithmetic operations don't obey the usua=
l algebraic structures of group theory, but that doesn't make the value=
s "not numbers" nor does it mean that the results of operations a=
re not exactly specified.</div><div>=C2=A0<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div> Only when you calculate errors you can use for numerical c=
alculations.<br></div></div></blockquote><div><br></div><div>That depends o=
n what you're doing.=C2=A0 As you see from my code above, there are thi=
ngs that can be done with floating-point without "calculating errors&q=
uot;.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Second, wh=
at is exactly mass of electron? Or mass of some object? Or position of some=
thing (quantum physics anyone?)? You can't know exactly. And if you hav=
e errors in input then you will have error in output. I don't know why =
you want compare to have any meaning if some bits are effective random? Sci=
ence can work easy with that because they calculate errors and know how goo=
d result is.<br></div></div></blockquote><div><br></div><div>Because not al=
l calculation involves imprecisely known physical values.=C2=A0 Your bank a=
ccount and credit card balances are exact, for example.</div></div></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/CAHSYqdapr1WMTCkrCAPSPHgzE7H0eE4XOeTg=
WL5j7KhzB%2BtUMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdapr1WMTC=
krCAPSPHgzE7H0eE4XOeTgWL5j7KhzB%2BtUMA%40mail.gmail.com</a>.<br />
--001a1144db3e6cb0040537feccf5--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 19 Jul 2016 13:04:37 -0700 (PDT)
Raw View
------=_Part_5757_635347440.1468958677206
Content-Type: multipart/alternative;
boundary="----=_Part_5758_1337255243.1468958677207"
------=_Part_5758_1337255243.1468958677207
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 19, 2016 at 5:32:56 PM UTC+2, Hyman Rosen wrote:
>
> On Mon, Jul 18, 2016 at 4:29 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>>
>> My whole point is that float numbers are "close" to real number values
>> and all result are "close" to real result.
>> And now if I want compare this 1/3 to result of some float point
>> operations (this why I need it), then I should use "close" equal not bit
>> equal that you think is right thing.
>>
>
> You may need to know that one number is close to three times another and
> someone else may need to know that one number is exactly three times
> another. If they do, it doesn't matter to them that you don't, and they're
> going to need to know what floating-point arithmetic does in order to be
> able to use it.
>
>
How many times I need repeat it? You want use floating points for things
that they was not designed for. That mean 3 times another? 3 times add same
number, multiple by 3 or divide other number by 3? Each can give different
answer.
Only thing that people need know then using floating-point is not use equal
because results are meaningless for any serious computation. Another
example presenting this:
#include<iostream>
float d = 0x1.000002p1f;
int main()
{
std::cout << std::hexfloat << d << "\n";
std::cout << d + d + d + d + d + d + d + d + d + d + d + d << "\n";
//0x1.800002p+4
std::cout << d + d + d + d + (d + d + d + d + d + d + d + d) << "\n";
//0x1.800004p+4
return 0;
}
http://melpon.org/wandbox/permlink/3JYcAeOyKbywy9o8
> The arithmetic of floating-point always yields the nearest representable
>>> result to the correct value. The rounding error is the difference between
>>> those two. Sometimes the rounding error is 0, and often it is not.
>>>
>>
>> No. If some floating point operation generate some difference between
>> correct value and representable value then final result can be wrong on any
>> scale you want.
>> Simply image adding million times value that should be zero but because
>> of limiting accuracy of floating points became greater than zero.
>>
>
> If you repeat an operation many times such that the rounded result is
> always biased away from the actual result in the same direction, then you
> will accumulate the repeated differences. If you want to analyze results
> of such calculations, it helps to know what the calculations are supposed
> to do.
>
>
In my previous example only some number combinations generated difference
for `x == x * d / d`. How I could know what this calculation supposed to
do? Only right way to handle it is `abs(x - (x * d / d)) < epsilon`, and
this is only thing I need to know is this `epsilon` about available
floating-point operations.
>
>
>> Example: http://melpon.org/wandbox/permlink/UDPx1nx78rgqZQAb
>>
>> #include<iostream>
>> float d = 0.00323f;
>> float x = 15011.0f;
>> float y = (x * d / d);
>> int main()
>> {
>> std::cout << std::hexfloat << x << "\n";
>> std::cout << d << "\n";
>> std::cout << y << "\n";
>> std::cout << (x - y) << "\n";
>> return (x) == y;
>> }
>> For gcc on wandbox this return 0 and diff equal "0x1p-10". Now multiply
>> by 1024 and you have `1.f`.
>>
>
> In the following code, I need equality checks. Not approximate checks,
> actual equality checks.
>
> #include <stdio.h>
> void shortest_decimal(float f, char *buf)
> {
> float r;
> sprintf(buf, "%.6g", f); sscanf(buf, "%f", &r); if (r != f) {
> sprintf(buf, "%.7g", f); sscanf(buf, "%f", &r); if (r != f) {
> sprintf(buf, "%.8g", f); sscanf(buf, "%f", &r); if (r != f) {
> sprintf(buf, "%.9g", f); }}}
> }
>
> You only show that you use it incorrectly.
>>
>
> Perhaps you would like to explain how my code above is using equality
> incorrectly?
>
>
For any float, from not trivial operation, last line will be used. Simply
because you can't storing it in decimal text without losing some bits.
And if you want create custom format then you probably manually using
`modf` and multiplying by 10, and doing this until fractional part is small
enough or you reach limit of symbols to print.
Another is use "%.9g" and remove tailing zeros from fractional part. Both
solution do not need use equal.
> First floating-points numbers aren't even numbers in mathematical sense.
>>
>
> Floating-point numbers are a finite set of rational numbers plus a handful
> of singular values. Of course they are numbers.
>
>
>> What is zero element in it? It could be 0.001 or 10 depending what big
>> number you try add to.
>>
>
> The arithmetic operations don't obey the usual algebraic structures of
> group theory, but that doesn't make the values "not numbers" nor does it
> mean that the results of operations are not exactly specified.
>
>
They are exactly specified as "value + error" where "abs(error) <
epsilon*value". With that definition I can apply algebraic structures and
use if it was normal numbers. But if like you, pretending that "error" do
not exists because "value1 + error1 == value1 + error2" need to holds then
floating-points aren't numbers. Using greater precision (like in your first
example in this offtop) only helps because error in result of some
operation could be less or equal amplitude as its arguments not greater.
> Only when you calculate errors you can use for numerical calculations.
>>
>
> That depends on what you're doing. As you see from my code above, there
> are things that can be done with floating-point without "calculating
> errors".
>
> Second, what is exactly mass of electron? Or mass of some object? Or
>> position of something (quantum physics anyone?)? You can't know exactly.
>> And if you have errors in input then you will have error in output. I don't
>> know why you want compare to have any meaning if some bits are effective
>> random? Science can work easy with that because they calculate errors and
>> know how good result is.
>>
>
> Because not all calculation involves imprecisely known physical values.
> Your bank account and credit card balances are exact, for example.
>
Then you should use decimal like in C# not float or double. At least you
will not have lost precision when converting between text and numbers. But
they still floating points and without care, equal can work in unexpected
ways.
Anyway this offtopic probably go to far, for me this is EOT.
--
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/9964588d-7cf5-4241-9396-9c7ed026f66c%40isocpp.org.
------=_Part_5758_1337255243.1468958677207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, July 19, 2016 at 5:32:56 PM UTC+2, Hym=
an Rosen 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 class=3D"gmail_quote">On Mon, Jul 18, 2016 at 4:29 PM, <span d=
ir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"7G5JSj7VDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">inkwizyt...@gmail.com</a>></span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>My whole point is that float numbers are "close"=
to real number values and all result are "close" to real result.=
<br>And now if I want compare this 1/3 to result of some float point operat=
ions (this why I need it), then I should use "close" equal not bi=
t equal that you think is right thing.<br></div></div></blockquote><div><br=
></div><div>You may need to know that one number is close to three times an=
other and someone else may need to know that one number is exactly three ti=
mes another.=C2=A0 If they do, it doesn't matter to them that you don&#=
39;t, and they're going to need to know what floating-point arithmetic =
does in order to be able to use it.</div><div><br></div></div></div></div><=
/blockquote><div><br>How many times I need repeat it? You want use floating=
points for things that they was not designed for. That mean 3 times anothe=
r? 3 times add same number, multiple by 3 or divide other number by 3? Each=
can give different answer.<br>Only thing that people need know then using =
floating-point is not use equal because results are meaningless for any ser=
ious computation. Another example presenting this:<br><div class=3D"prettyp=
rint" 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"c=
olor: #800;" class=3D"styled-by-prettify">#include</span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify"><iostream></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0x1</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0=
00002p1f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">hexfloat </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> d </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"\n&qu=
ot;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> d </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0=
d </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> d </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> d </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">"\n"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//0x1.800002p+4</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> d </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> d </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">d </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> d </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> d </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
d </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> d </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> d</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><<</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">"\n"</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//0x1.80=
0004p+4</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}</span></div></code></div>http:=
//melpon.org/wandbox/permlink/3JYcAeOyKbywy9o8<br><br>=C2=A0</div><blockquo=
te 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 class=3D"gma=
il_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The arithmetic of =
floating-point always yields the nearest representable result to the correc=
t value.=C2=A0 The rounding error is the difference between those two.=C2=
=A0 Sometimes the rounding error is 0, and often it is not.</div></div></di=
v></div></blockquote></span><div><br>No. If some floating point operation g=
enerate some difference between correct value and representable value then =
final result can be wrong on any scale you want.<br>Simply image adding mil=
lion times value that should be zero but because of limiting accuracy of fl=
oating points became greater than zero.<br></div></div></blockquote><div><b=
r></div><div>If you repeat an operation many times such that the rounded re=
sult is always biased away from the actual result in the same direction, th=
en you will accumulate the repeated differences.=C2=A0 If you want to analy=
ze results of such calculations, it helps to know what the calculations are=
supposed to do.</div><div><br></div></div></div></div></blockquote><div><b=
r>In my previous example only some number combinations generated difference=
for `x =3D=3D x * d / d`. How I could know what this calculation supposed =
to do? Only right way to handle it is `abs(x - (x * d / d)) < epsilon`, =
and this is only thing I need to know is this `epsilon` about available flo=
ating-point operations.<br>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Example: <a href=3D"http=
://melpon.org/wandbox/permlink/UDPx1nx78rgqZQAb" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2FUDPx1nx78rgqZQAb\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHca6sk3CYEC67ouEPPaImtk7dvjQ';return true;" o=
nclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmelp=
on.org%2Fwandbox%2Fpermlink%2FUDPx1nx78rgqZQAb\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHca6sk3CYEC67ouEPPaImtk7dvjQ';return true;">http://melpon.o=
rg/wandbox/<wbr>permlink/UDPx1nx78rgqZQAb</a><br><br><div style=3D"border:1=
px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250=
,250)"><code><div><span style=3D"color:rgb(136,0,0)">#include</span><span s=
tyle=3D"color:rgb(0,136,0)"><iostream></span><span style=3D"color:rgb=
(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">float</span><span st=
yle=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0)">=3D=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,=
102,102)">0.00323f</span><span style=3D"color:rgb(102,102,0)">;</span><span=
style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">f=
loat</span><span style=3D"color:rgb(0,0,0)"> x </span><span style=3D"color:=
rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span st=
yle=3D"color:rgb(0,102,102)">15011.0f</span><span style=3D"color:rgb(102,10=
2,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"co=
lor:rgb(0,0,136)">float</span><span style=3D"color:rgb(0,0,0)"> y </span><s=
pan style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0=
)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"colo=
r:rgb(0,0,0)">x </span><span style=3D"color:rgb(102,102,0)">*</span><span s=
tyle=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0)">/<=
/span><span style=3D"color:rgb(0,0,0)"> d</span><span style=3D"color:rgb(10=
2,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=
=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> main</s=
pan><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(=
0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:rgb(=
102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">cout </span><span sty=
le=3D"color:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"=
> std</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"co=
lor:rgb(0,0,0)">hexfloat </span><span style=3D"color:rgb(102,102,0)"><&l=
t;</span><span style=3D"color:rgb(0,0,0)"> x </span><span style=3D"color:rg=
b(102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(0,136,0)">"\n"</span><span style=3D"color:rgb=
(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std=
</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:r=
gb(0,0,0)">cout </span><span style=3D"color:rgb(102,102,0)"><<</span>=
<span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102=
,0)"><<</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(0,136,0)">"\n"</span><span style=3D"color:rgb(102,102,=
0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><s=
pan style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)=
">cout </span><span style=3D"color:rgb(102,102,0)"><<</span><span sty=
le=3D"color:rgb(0,0,0)"> y </span><span style=3D"color:rgb(102,102,0)"><=
<</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(0,136,0)">"\n"</span><span style=3D"color:rgb(102,102,0)">;</sp=
an><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">cout </=
span><span style=3D"color:rgb(102,102,0)"><<</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span s=
tyle=3D"color:rgb(0,0,0)">x </span><span style=3D"color:rgb(102,102,0)">-</=
span><span style=3D"color:rgb(0,0,0)"> y</span><span style=3D"color:rgb(102=
,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"co=
lor:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(0,136,0)">"\n"</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span=
style=3D"color:rgb(0,0,0)">x</span><span style=3D"color:rgb(102,102,0)">)<=
/span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102=
,102,0)">=3D=3D</span><span style=3D"color:rgb(0,0,0)"> y</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></sp=
an><span style=3D"color:rgb(102,102,0)">}</span></div></code></div>For gcc =
on wandbox this return 0 and diff equal "0x1p-10". Now multiply b=
y 1024 and you have `1.f`.</div></div></blockquote><div><br></div><div>In t=
he following code, I need equality checks.=C2=A0 Not approximate checks, ac=
tual equality checks.</div><div><br><div><font face=3D"monospace, monospace=
">#include <stdio.h></font></div><div><span style=3D"font-family:mono=
space,monospace">void shortest_decimal(float f, char *buf)</span><br></div>=
<div><font face=3D"monospace, monospace">{</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 float r;</font></div><div><font face=3D"=
monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.6g", f); ssca=
nf(buf, "%f", &r); if (r !=3D f) {</font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.7g", f);=
sscanf(buf, "%f", &r); if (r !=3D f) {</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.8g"=
, f); sscanf(buf, "%f", &r); if (r !=3D f) {</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.9g&=
quot;, f); }}}</font></div><div><font face=3D"monospace, monospace">}</font=
></div></div><div><font face=3D"monospace, monospace"><br></font></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>You only show that you use it incorrectl=
y.<br></div></div></blockquote><div><br></div><div>Perhaps you would like t=
o explain how my code above is using equality incorrectly?</div><div><br></=
div></div></div></div></blockquote><div><br>For any float, from not trivial=
operation, last line will be used. Simply because you can't storing it=
in decimal text without losing some bits.<br>And if you want create custom=
format then you probably manually using `modf` and multiplying by 10, and =
doing this until fractional part is small enough or you reach limit of symb=
ols to print.<br>Another is use "%.9g" and remove tailing zeros f=
rom fractional part. Both solution do not need use equal.<br><br>=C2=A0<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
First floating-points numbers aren't even numbers in mathematical sense=
..</div></div></blockquote><div><br></div><div>Floating-point numbers are a =
finite set of rational numbers plus a handful of singular values.=C2=A0 Of =
course they are numbers.</div><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div> What is zero element in it? It could be 0.001 or 10 dependi=
ng what big number you try add to.</div></div></blockquote><div><br></div><=
div>The arithmetic operations don't obey the usual algebraic structures=
of group theory, but that doesn't make the values "not numbers&qu=
ot; nor does it mean that the results of operations are not exactly specifi=
ed.</div><div>=C2=A0<br></div></div></div></div></blockquote><div><br>They =
are exactly specified as "value + error" where "abs(error) &=
lt; epsilon*value". With that definition I can apply algebraic structu=
res and use if it was normal numbers. But if like you, pretending that &quo=
t;error" do not exists because "value1 + error1 =3D=3D value1 + e=
rror2" need to holds then floating-points aren't numbers. Using gr=
eater precision (like in your first example in this offtop) only helps beca=
use error in result of some operation could be less or equal amplitude as i=
ts arguments not greater.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div> Only when you calculate errors you can =
use for numerical calculations.<br></div></div></blockquote><div><br></div>=
<div>That depends on what you're doing.=C2=A0 As you see from my code a=
bove, there are things that can be done with floating-point without "c=
alculating errors".</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>Second, what is exactly mass of electron? Or mass of some object? =
Or position of something (quantum physics anyone?)? You can't know exac=
tly. And if you have errors in input then you will have error in output. I =
don't know why you want compare to have any meaning if some bits are ef=
fective random? Science can work easy with that because they calculate erro=
rs and know how good result is.<br></div></div></blockquote><div><br></div>=
<div>Because not all calculation involves imprecisely known physical values=
..=C2=A0 Your bank account and credit card balances are exact, for example.<=
/div></div></div></div></blockquote><div><br>Then you should use decimal li=
ke in C# not float or double. At least you will not have lost precision whe=
n converting between text and numbers. But they still floating points and w=
ithout care, equal can work in unexpected ways.<br><br>Anyway this offtopic=
probably go to far, for me this is EOT.<br></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/9964588d-7cf5-4241-9396-9c7ed026f66c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9964588d-7cf5-4241-9396-9c7ed026f66c=
%40isocpp.org</a>.<br />
------=_Part_5758_1337255243.1468958677207--
------=_Part_5757_635347440.1468958677206--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 19 Jul 2016 17:30:09 -0400
Raw View
--94eb2c06fb2e40a7ce053803cb8b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 19, 2016 at 4:04 PM, <inkwizytoryankes@gmail.com> wrote:
>
> How many times I need repeat it? You want use floating points for things
> that they was not designed for.
>
Repeating this will not make it true. Floating-point arithmetic,
especially in its modern IEEE 754 form, produces exact and well-defined
results from its basic arithmetic operations. Those operations can be used
for anything the programmer wants.
> That mean 3 times another? 3 times add same number, multiple by 3 or
> divide other number by 3? Each can give different answer.
>
Recovering original operands after performing arbitrary arithmetic is
indeed unlikely.
> Only thing that people need know then using floating-point is not use
> equal because results are meaningless for any serious computation. Anothe=
r
> example presenting this:
> #include<iostream>
> float d =3D 0x1.000002p1f;
> int main()
> {
> std::cout << std::hexfloat << d << "\n";
> std::cout << d + d + d + d + d + d + d + d + d + d + d + d << "\n";
> //0x1.800002p+4
> std::cout << d + d + d + d + (d + d + d + d + d + d + d + d) << "\n";
> //0x1.800004p+4
> return 0;
> }
> http://melpon.org/wandbox/permlink/3JYcAeOyKbywy9o8
>
Serious computations are not limited to those that accumulate round-off
errors.
In my previous example only some number combinations generated difference
> for `x =3D=3D x * d / d`. How I could know what this calculation supposed=
to do?
>
By understanding the properties of floating-point arithmetic.
Only right way to handle it is `abs(x - (x * d / d)) < epsilon`, and this
> is only thing I need to know is this `epsilon` about available
> floating-point operations.
>
Handle what? Are you trying to write an equality test? If you do it this
way, you will break transitivity; you will have numbers such that a =E2=89=
=88 b and b
=E2=89=88 c but not a =E2=89=88 c. My wife once had an error like this in =
her code that
took days to track down.
#include <stdio.h>
>> void shortest_decimal(float f, char *buf)
>> {
>> float r;
>> sprintf(buf, "%.6g", f); sscanf(buf, "%f", &r); if (r !=3D f) {
>> sprintf(buf, "%.7g", f); sscanf(buf, "%f", &r); if (r !=3D f) {
>> sprintf(buf, "%.8g", f); sscanf(buf, "%f", &r); if (r !=3D f) {
>> sprintf(buf, "%.9g", f); }}}
>> }
>>
>> You only show that you use it incorrectly.
>>>
>>
>> Perhaps you would like to explain how my code above is using equality
>> incorrectly?
>>
>>
> For any float, from not trivial operation, last line will be used. Simply
> because you can't storing it in decimal text without losing some bits.
>
Those "non-trivial" operations happen to include numbers converted from
decimal values on data feeds; numbers that come in with six significant
digits (like currency exchange rates) convert back to six digits.
> And if you want create custom format then you probably manually using
> `modf` and multiplying by 10, and doing this until fractional part is sma=
ll
> enough or you reach limit of symbols to print.
>
No, that's wrong. Multiplying by 10 loses bits (because 10*x =3D 8*x + 2*x=
).
> Another is use "%.9g" and remove tailing zeros from fractional part. Both
> solution do not need use equal.
>
No, that's wrong. If you print 0.1f using %.9g, you get 0.100000001, so
removing trailing 0s doesn't help.
Anyway this offtopic probably go to far, for me this is EOT.
>
It demonstrates that misconceptions lead to poor conclusions and poor
designs.
--=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/CAHSYqda564JO9kVb9Hx%2BKske0OQ4tDfSPf-tmLv9dZU-F=
oDp4A%40mail.gmail.com.
--94eb2c06fb2e40a7ce053803cb8b
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=
ue, Jul 19, 2016 at 4:04 PM, <span dir=3D"ltr"><<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>>=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>How many times I need =
repeat it? You want use floating points for things that they was not design=
ed for.</div></div></blockquote><div><br></div><div>Repeating this will not=
make it true.=C2=A0 Floating-point arithmetic, especially in its modern IE=
EE 754 form, produces exact and well-defined results from its basic arithme=
tic operations.=C2=A0 Those operations can be used for anything the program=
mer wants.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
> That mean 3 times another? 3 times add same number, multiple by 3 or divi=
de other number by 3? Each can give different answer.<br></div></div></bloc=
kquote><div><br></div><div>Recovering original operands after performing ar=
bitrary arithmetic is indeed unlikely.</div><div><br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>Only thing that people need know th=
en using floating-point is not use equal because results are meaningless fo=
r any serious computation. Another example presenting this:<br><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:rgb(136,0,0)">#include</=
span><span style=3D"color:rgb(0,136,0)"><iostream></span><span style=
=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">float</=
span><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(10=
2,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(0,102,102)">0x1</span><span style=3D"color:rgb(102,102,0)">.</sp=
an><span style=3D"color:rgb(0,102,102)">000002p1f</span><span style=3D"colo=
r:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span=
style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> m=
ain</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"colo=
r:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span=
style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 std</span><span style=3D"colo=
r:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">cout </span><sp=
an style=3D"color:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0=
,0,0)"> std</span><span style=3D"color:rgb(102,102,0)">::</span><span style=
=3D"color:rgb(0,0,0)">hexfloat </span><span style=3D"color:rgb(102,102,0)">=
<<</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"co=
lor:rgb(102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(0,136,0)">"\n"</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"=
color:rgb(0,0,0)">cout </span><span style=3D"color:rgb(102,102,0)"><<=
</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(=
102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=
=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </spa=
n><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0=
,0)"> d </span><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"=
color:rgb(0,0,0)"> =C2=A0d </span><span style=3D"color:rgb(102,102,0)">+</s=
pan><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102=
,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"=
color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </span><s=
pan style=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"=
> d </span><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"colo=
r:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0)">+</span><span =
style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0)">+=
</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(=
102,102,0)"><<</span><span style=3D"color:rgb(0,0,0)"> </span><span s=
tyle=3D"color:rgb(0,136,0)">"\n"</span><span style=3D"color:rgb(1=
02,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"=
color:rgb(136,0,0)">//0x1.800002p+4</span><span style=3D"color:rgb(0,0,0)">=
<br>=C2=A0 =C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><=
span style=3D"color:rgb(0,0,0)">cout </span><span style=3D"color:rgb(102,10=
2,0)"><<</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=
=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </spa=
n><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0=
,0)"> d </span><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"=
color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0)">+</span><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"=
>(</span><span style=3D"color:rgb(0,0,0)">d </span><span style=3D"color:rgb=
(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=
=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d </spa=
n><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0=
,0)"> d </span><span style=3D"color:rgb(102,102,0)">+</span><span style=3D"=
color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0)">+</span><s=
pan style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:rgb(102,102,0=
)">+</span><span style=3D"color:rgb(0,0,0)"> d </span><span style=3D"color:=
rgb(102,102,0)">+</span><span style=3D"color:rgb(0,0,0)"> d</span><span sty=
le=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,102,0)"><<</span><span style=3D"color:=
rgb(0,0,0)"> </span><span style=3D"color:rgb(0,136,0)">"\n"</span=
><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(136,0,0)">//0x1.800004p+4</span><span =
style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rg=
b(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> </span><span sty=
le=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(=
102,102,0)">}</span></div></code></div><a href=3D"http://melpon.org/wandbox=
/permlink/3JYcAeOyKbywy9o8" target=3D"_blank">http://melpon.org/wandbox/per=
mlink/3JYcAeOyKbywy9o8</a></div></div></blockquote><div><br></div><div>Seri=
ous computations are not limited to those that accumulate round-off errors.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>In my previous =
example only some number combinations generated difference for `x =3D=3D x =
* d / d`. How I could know what this calculation supposed to do?</div></div=
></blockquote><div><br></div><div>By understanding the properties of floati=
ng-point arithmetic.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div>Only right way to handle it is `abs(x - (x * d / d)) < epsilon`, an=
d this is only thing I need to know is this `epsilon` about available float=
ing-point operations.<br></div></div></blockquote><div><br></div><div>Handl=
e what?=C2=A0 Are you trying to write an equality test?=C2=A0 If you do it =
this way, you will break transitivity; you will have numbers such that <fon=
t face=3D"monospace, monospace">a=C2=A0=E2=89=88 b</font> and <font face=3D=
"monospace, monospace">b =E2=89=88 c</font> but not <font face=3D"monospace=
, monospace">a=C2=A0=E2=89=88 c</font>.=C2=A0 My wife once had an error lik=
e this in her code that took days to track down.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div><div><font face=3D"monospace, mono=
space">#include <stdio.h></font></div><div><span style=3D"font-family=
:monospace,monospace">void shortest_decimal(float f, char *buf)</span><br><=
/div><div><font face=3D"monospace, monospace">{</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 float r;</font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.6g", f);=
sscanf(buf, "%f", &r); if (r !=3D f) {</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.7g"=
, f); sscanf(buf, "%f", &r); if (r !=3D f) {</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "%.8g&=
quot;, f); sscanf(buf, "%f", &r); if (r !=3D f) {</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 sprintf(buf, "=
%.9g", f); }}}</font></div><div><font face=3D"monospace, monospace">}<=
/font></div></div><div><font face=3D"monospace, monospace"><br></font></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>You only show that you use it incor=
rectly.<br></div></div></blockquote><div><br></div><div>Perhaps you would l=
ike to explain how my code above is using equality incorrectly?</div><div><=
br></div></div></div></div></blockquote></span><div><br>For any float, from=
not trivial operation, last line will be used. Simply because you can'=
t storing it in decimal text without losing some bits.<br></div></div></blo=
ckquote><div><br></div><div>Those "non-trivial" operations happen=
to include numbers converted from decimal values on data feeds; numbers th=
at come in with six significant digits (like currency exchange rates) conve=
rt back to six digits.</div><div>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>And if you want create custom format then you probably manual=
ly using `modf` and multiplying by 10, and doing this until fractional part=
is small enough or you reach limit of symbols to print.<br></div></div></b=
lockquote><div><br></div><div>No, that's wrong.=C2=A0 Multiplying by 10=
loses bits (because 10*x =3D 8*x + 2*x).</div><div>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div>Another is use "%.9g" and remove =
tailing zeros from fractional part. Both solution do not need use equal.<br=
></div></div></blockquote><div><br></div><div>No, that's wrong.=C2=A0 I=
f you print 0.1f using %.9g, you get=C2=A00.100000001, so removing trailing=
0s doesn't help.</div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>Anyway this offtopic probably go to far, for me this is EOT.</div></d=
iv></blockquote><div><br></div><div>It demonstrates that misconceptions lea=
d to poor conclusions and poor designs.</div></div></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/CAHSYqda564JO9kVb9Hx%2BKske0OQ4tDfSPf=
-tmLv9dZU-FoDp4A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda564JO9k=
Vb9Hx%2BKske0OQ4tDfSPf-tmLv9dZU-FoDp4A%40mail.gmail.com</a>.<br />
--94eb2c06fb2e40a7ce053803cb8b--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 20 Jul 2016 10:00:30 -0400
Raw View
On 2016-07-19 17:30, Hyman Rosen wrote:
> On Tue, Jul 19, 2016 at 4:04 PM, <inkwizytoryankes@gmail.com> wrote:
>> How many times I need repeat it? You want use floating points for things
>> that they was not designed for.
>
> Repeating this will not make it true. Floating-point arithmetic,
> especially in its modern IEEE 754 form, produces exact and well-defined
> results from its basic arithmetic operations. Those operations can be used
> for anything the programmer wants.
So the expression 1e50 + 1e-50 gives an exact result?
>>> #include <stdio.h>
>>> void shortest_decimal(float f, char *buf)
>>> {
>>> float r;
>>> sprintf(buf, "%.6g", f); sscanf(buf, "%f", &r); if (r != f) {
>>> sprintf(buf, "%.7g", f); sscanf(buf, "%f", &r); if (r != f) {
>>> sprintf(buf, "%.8g", f); sscanf(buf, "%f", &r); if (r != f) {
>>> sprintf(buf, "%.9g", f); }}}
>>> }
>>>
>>> Perhaps you would like to explain how my code above is using equality
>>> incorrectly?
>>
>> For any float, from not trivial operation, last line will be used. Simply
>> because you can't storing it in decimal text without losing some bits.
>
> Those "non-trivial" operations happen to include numbers converted from
> decimal values on data feeds; numbers that come in with six significant
> digits (like currency exchange rates) convert back to six digits.
Near as I can tell, the above gives the decimal representation that is
"within one epsilon" of the input value, where an epsilon is defined
here as the largest value that can be added or subtracted from the
number without changing its representation in `float`.
It also seems to me to be a rather inefficient mechanism for achieving
that result.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nmo05u%24l5n%241%40ger.gmane.org.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 20 Jul 2016 13:03:34 -0400
Raw View
--94eb2c048e44b6a2840538142f3e
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 20, 2016 at 10:00 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> So the expression 1e50 + 1e-50 gives an exact result?
>
Yes, or course. The exact result of this operation is the double value
closest to 1e50 + 1e-50 (which is also the double value closest to 1e50).
Perhaps I should have said an "exactly defined" or "deterministic" result,
since you misunderstood me.
Near as I can tell, the above gives the decimal representation that is
> "within one epsilon" of the input value, where an epsilon is defined
> here as the largest value that can be added or subtracted from the
> number without changing its representation in `float`.
>
It gives the decimal value with the fewest significant digits that converts
back to the original value. That's an extremely desirable property - we
can recover the exact binary value, and users don't get cranky from seeing
"extraneous" decimal places, so it's particularly good in interchange
formats where it will be seen by people. (The equivalent for double is to
try 15, 16, and 17 digits.)
> It also seems to me to be a rather inefficient mechanism for achieving
> that result.
It is the best, or at least shortest, implementation I know of using the
standard library, without coding up a very complex algorithm that does it
in one go. Perhaps you have something better to show me?
--
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/CAHSYqdaiYBJUiZ2nrA%3Dqz2wYPOAOL0637BoBSJzKVVq2VfmLww%40mail.gmail.com.
--94eb2c048e44b6a2840538142f3e
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 W=
ed, Jul 20, 2016 at 10:00 AM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So the expression =
1e50 + 1e-50 gives an exact result?<br></blockquote><div><br></div><div>Yes=
, or course.=C2=A0 The exact result of this operation is the double value c=
losest to 1e50 + 1e-50 (which is also the double value closest to 1e50).=C2=
=A0 Perhaps I should have said an "exactly defined" or "dete=
rministic" result, since you misunderstood me.</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">Near as I can tell, the above gives the decimal=
representation that is<br>
"within one epsilon" of the input value, where an epsilon is defi=
ned<br>
here as the largest value that can be added or subtracted from the<br>
number without changing its representation in `float`.<br></blockquote><div=
><br></div><div>It gives the decimal value with the fewest significant digi=
ts that converts back to the original value.=C2=A0 That's an extremely =
desirable property - we can recover the exact binary value, and users don&#=
39;t get cranky from seeing "extraneous" decimal places, so it=
9;s particularly good in interchange formats where it will be seen by peopl=
e. =C2=A0(The equivalent for double is to try 15, 16, and 17 digits.)=C2=A0=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also seems to me to be a rather inefficient mechanism for achieving<br>
that result.</blockquote><div><br></div><div>It is the best, or at least sh=
ortest, implementation I know of using the standard library, without coding=
up a very complex algorithm that does it in one go.=C2=A0 Perhaps you have=
something better to show me?</div></div></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/CAHSYqdaiYBJUiZ2nrA%3Dqz2wYPOAOL0637B=
oBSJzKVVq2VfmLww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaiYBJUiZ=
2nrA%3Dqz2wYPOAOL0637BoBSJzKVVq2VfmLww%40mail.gmail.com</a>.<br />
--94eb2c048e44b6a2840538142f3e--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 20 Jul 2016 12:11:18 -0700 (PDT)
Raw View
------=_Part_774_388569787.1469041878919
Content-Type: multipart/alternative;
boundary="----=_Part_775_1931217089.1469041878919"
------=_Part_775_1931217089.1469041878919
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, July 18, 2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:
>
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>
>>
>>
>> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>>
>>>
>>> In C and C++98/03, for some initialized and distinct scalar objects x=
=20
>>> and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11 =
assignment=20
>>> allows it for non-volatile scalars, because the C++11 rules makes it=20
>>> effectively ordered (in such cases), with *right-to-left* order.
>>>
>>>
>> Nope, that's still undefined. It's essentially the same as i +=3D ++i + =
1;=20
>> discussed in=20
>> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-un=
defined-behavior
>>
>> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=20
>>
> Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
>
You have a x ^=3D something-modifying-x. There is no sequencing between the=
=20
read of x for the ^ and the modification in something-modifying-x - exactly=
=20
the same problem as i +=3D ++i + 1.
--=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/1569823d-9a4f-4221-82cc-eeacf6077cf4%40isocpp.or=
g.
------=_Part_775_1931217089.1469041878919
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, July 18, 2016 at 2:39:02 AM UTC-4, Fran=
kHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=85=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=
=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thur=
sday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div><br>In C and C++98/03, for s=
ome initialized and distinct scalar objects x and y, x ^=3D y ^=3D x ^=3D y=
will cause undefined behavior, but C++11 assignment allows it for non-vola=
tile scalars, because the C++11 rules makes it effectively ordered (in such=
cases), with <i>right-to-left</i> order.<br><br></div></div></blockquote><=
div><br></div><div>Nope, that's still undefined. It's essentially t=
he same as i +=3D ++i + 1; discussed in=C2=A0<a href=3D"http://stackoverflo=
w.com/questions/24194076/in-c11-does-i-i-1-exhibit-undefined-behavior" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fquestions%2F24194076%2=
Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2=
Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return =
true;">http://stackoverflow.com/<wbr>questions/24194076/in-c11-<wbr>does-i-=
i-1-exhibit-undefined-<wbr>behavior</a></div><div><br></div><div>i =3D ++i =
+ 1 is fine in C++11. i +=3D ++i + 1 is not.=C2=A0</div></div></blockquote>=
<div>Really? Please i +=3D ++i + 1 is <i>not </i>j +=3D ++i + 1.<br></div><=
/div></blockquote><div><br></div><div>You have a x ^=3D something-modifying=
-x. There is no sequencing between the read of x for the ^ and the modifica=
tion in something-modifying-x - exactly the same problem as i +=3D ++i + 1.=
</div><div><br></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/1569823d-9a4f-4221-82cc-eeacf6077cf4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1569823d-9a4f-4221-82cc-eeacf6077cf4=
%40isocpp.org</a>.<br />
------=_Part_775_1931217089.1469041878919--
------=_Part_774_388569787.1469041878919--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 20 Jul 2016 20:25:23 +0100
Raw View
--94eb2c124a32b500d905381629df
Content-Type: text/plain; charset=UTF-8
On 20 Jul 2016 6:03 p.m., "Hyman Rosen" <hyman.rosen@gmail.com> wrote:
> It gives the decimal value with the fewest significant digits that
converts back to the original value. That's an extremely desirable
property - we can recover the exact binary value, and users don't get
cranky from seeing "extraneous" decimal places, so it's particularly good
in interchange formats where it will be seen by people. (The equivalent
for double is to try 15, 16, and 17 digits.)
>
>>
>> It also seems to me to be a rather inefficient mechanism for achieving
>> that result.
>
>
> It is the best, or at least shortest, implementation I know of using the
standard library, without coding up a very complex algorithm that does it
in one go. Perhaps you have something better to show me?
It's a solved problem. Florian Loitsch's Grisu2 is easy to understand and
implement, and there's enough implementations out there to find one
compatible in licensing with your in-house library. We use Milo Yip's
implementation, with some tweaks.
The right way to solve this problem - and I agree it is a worthwhile goal -
is to add to the standard a floating point to string function with the
shortest representation requirement. There was some noise on that recently.
--
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/CAJnLdObTmhtjvekT23e1Mh%3DKU55a%3D8ub3cMnikwTK9jChHQ1VA%40mail.gmail.com.
--94eb2c124a32b500d905381629df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 20 Jul 2016 6:03 p.m., "Hyman Rosen" <<a hre=
f=3D"mailto:hyman.rosen@gmail.com">hyman.rosen@gmail.com</a>> wrote:<br>
> It gives the decimal value with the fewest significant digits that con=
verts back to the original value.=C2=A0 That's an extremely desirable p=
roperty - we can recover the exact binary value, and users don't get cr=
anky from seeing "extraneous" decimal places, so it's particu=
larly good in interchange formats where it will be seen by people. =C2=A0(T=
he equivalent for double is to try 15, 16, and 17 digits.)=C2=A0<br>
> =C2=A0<br>
>><br>
>> It also seems to me to be a rather inefficient mechanism for achie=
ving<br>
>> that result.<br>
><br>
><br>
> It is the best, or at least shortest, implementation I know of using t=
he standard library, without coding up a very complex algorithm that does i=
t in one go.=C2=A0 Perhaps you have something better to show me?</p>
<p dir=3D"ltr">It's a solved problem. Florian Loitsch's Grisu2 is e=
asy to understand and implement, and there's enough implementations out=
there to find one compatible in licensing with your in-house library. We u=
se Milo Yip's implementation, with some tweaks. </p>
<p dir=3D"ltr">The right way to solve this problem - and I agree it is a wo=
rthwhile goal - is to add to the standard a floating point to string functi=
on with the shortest representation requirement. There was some noise on th=
at recently.</p>
<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/CAJnLdObTmhtjvekT23e1Mh%3DKU55a%3D8ub=
3cMnikwTK9jChHQ1VA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObTmhtj=
vekT23e1Mh%3DKU55a%3D8ub3cMnikwTK9jChHQ1VA%40mail.gmail.com</a>.<br />
--94eb2c124a32b500d905381629df--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 20 Jul 2016 17:42:07 -0400
Raw View
--001a1135729ee55515053818130d
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 20, 2016 at 3:25 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> It's a solved problem.
>
Yes.
> Florian Loitsch's Grisu2 is easy to understand and implement,
>
This is just one file
<https://github.com/google/double-conversion/blob/master/double-conversion/double-conversion.cc>
of
FL's implementation. By length alone I would dispute your claim.
> and there's enough implementations out there to find one compatible in
> licensing with your in-house library. We use Milo Yip's implementation,
> with some tweaks.
>
No doubt. Nevertheless, my way of doing it is in fact easy to understand
and implement, and uses only the standard library. It is also a good
illustration for a use of exact floating-point equality. It's even
educational - someone unfamiliar with the vagaries of floating-point is
going to look at it and wonder why it tries 6 through 9 digits, and be
inspired to learn.
> The right way to solve this problem - and I agree it is a worthwhile goal
> - is to add to the standard a floating point to string function with the
> shortest representation requirement. There was some noise on that recently.
>
It would be good if the right way to solve the problem were added to the
standard.
--
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/CAHSYqdZ2FBoHxaVLsD0AC4Fb48hLgWhQhVHj1RBFxH9UmkRNhg%40mail.gmail.com.
--001a1135729ee55515053818130d
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 W=
ed, Jul 20, 2016 at 3:25 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">
</span><p dir=3D"ltr">It's a solved problem.</p></blockquote><div>Yes.<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"> Florian Loitsch's G=
risu2 is easy to understand and implement,</p></blockquote><div>This is jus=
t=C2=A0<a href=3D"https://github.com/google/double-conversion/blob/master/d=
ouble-conversion/double-conversion.cc">one file</a>=C2=A0of FL's implem=
entation.=C2=A0 By length alone I would dispute your claim.</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><p dir=3D"ltr"> and there's enough implementations=
out there to find one compatible in licensing with your in-house library. =
We use Milo Yip's implementation, with some tweaks.</p></blockquote><di=
v>No doubt.=C2=A0 Nevertheless, my way of doing it is in fact easy to under=
stand and implement, and uses only the standard library.=C2=A0 It is also a=
good illustration for a use of exact floating-point equality.=C2=A0 It'=
;s even educational - someone unfamiliar with the vagaries of floating-poin=
t is going to look at it and wonder why it tries 6 through 9 digits, and be=
inspired to learn.</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"> </p=
>
<p dir=3D"ltr">The right way to solve this problem - and I agree it is a wo=
rthwhile goal - is to add to the standard a floating point to string functi=
on with the shortest representation requirement. There was some noise on th=
at recently.</p></blockquote><div>It would be good if the right way to solv=
e the problem were added to the standard.</div></div></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/CAHSYqdZ2FBoHxaVLsD0AC4Fb48hLgWhQhVHj=
1RBFxH9UmkRNhg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ2FBoHxaVL=
sD0AC4Fb48hLgWhQhVHj1RBFxH9UmkRNhg%40mail.gmail.com</a>.<br />
--001a1135729ee55515053818130d--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 20 Jul 2016 23:35:19 -0700 (PDT)
Raw View
------=_Part_2833_1721422797.1469082919759
Content-Type: multipart/alternative;
boundary="----=_Part_2834_467347087.1469082919760"
------=_Part_2834_467347087.1469082919760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
No, it is not the case of "x ^=3D something-modifying-x", it is "y ^=3D=20
something-modifying-x". There is no side effect beside assignments, and=20
multiple side effects the assignments in this full expression are sequenced=
=20
in a chain by the rule of assignment since each right operand is also an=20
assignment expression, see [expr.ass]/1.
And even if the left operand is denoting same scalar object, it is still=20
not UB, because compound assignment is a single evaluation and the=20
assigned-to operand is evaluated only once (see [expr.ass]/7), whose value=
=20
computation is restricted by the rule above. Only when you have a=20
volatile-qualified scalar, there will be unsequenced side effects (between=
=20
the left operand and right operand).
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Monday, July 18, 2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:
>>
>>
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>
>>>
>>>
>>> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>>>
>>>>
>>>> In C and C++98/03, for some initialized and distinct scalar objects x=
=20
>>>> and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11=
assignment=20
>>>> allows it for non-volatile scalars, because the C++11 rules makes it=
=20
>>>> effectively ordered (in such cases), with *right-to-left* order.
>>>>
>>>>
>>> Nope, that's still undefined. It's essentially the same as i +=3D ++i +=
1;=20
>>> discussed in=20
>>> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-u=
ndefined-behavior
>>>
>>> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=20
>>>
>> Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
>>
>
> You have a x ^=3D something-modifying-x. There is no sequencing between t=
he=20
> read of x for the ^ and the modification in something-modifying-x - exact=
ly=20
> the same problem as i +=3D ++i + 1.
>
>
--=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/194407f5-c086-4f0e-98a9-86b20a8cd38b%40isocpp.or=
g.
------=_Part_2834_467347087.1469082919760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, it is not the case of "x ^=3D something-modifying=
-x", it is "y ^=3D something-modifying-x".=C2=A0 There is no=
side effect beside assignments, and multiple side effects the assignments =
in this full expression are sequenced in a chain by the rule of assignment =
since each right operand is also an assignment expression, see [expr.ass]/1=
..<br><br>And even if the left operand is denoting same scalar object, it is=
still not UB, because compound assignment is a single evaluation and the a=
ssigned-to operand is evaluated only once (see [expr.ass]/7), whose value c=
omputation is restricted by the rule above. Only when you have a volatile-q=
ualified scalar, there will be unsequenced side effects (between the left o=
perand and right operand).<br><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=
=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=
=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><br><br>On Monday, July 18, 2016 at 2:39:02 AM UTC-4=
, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=85=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=
=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thur=
sday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div><br>In C and C++98/03, for s=
ome initialized and distinct scalar objects x and y, x ^=3D y ^=3D x ^=3D y=
will cause undefined behavior, but C++11 assignment allows it for non-vola=
tile scalars, because the C++11 rules makes it effectively ordered (in such=
cases), with <i>right-to-left</i> order.<br><br></div></div></blockquote><=
div><br></div><div>Nope, that's still undefined. It's essentially t=
he same as i +=3D ++i + 1; discussed in=C2=A0<a href=3D"http://stackoverflo=
w.com/questions/24194076/in-c11-does-i-i-1-exhibit-undefined-behavior" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fquestions%2F24194076%2=
Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2=
Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return =
true;">http://stackoverflow.com/<wbr>questions/24194076/in-c11-<wbr>does-i-=
i-1-exhibit-undefined-<wbr>behavior</a></div><div><br></div><div>i =3D ++i =
+ 1 is fine in C++11. i +=3D ++i + 1 is not.=C2=A0</div></div></blockquote>=
<div>Really? Please i +=3D ++i + 1 is <i>not </i>j +=3D ++i + 1.<br></div><=
/div></blockquote><div><br></div><div>You have a x ^=3D something-modifying=
-x. There is no sequencing between the read of x for the ^ and the modifica=
tion in something-modifying-x - exactly the same problem as i +=3D ++i + 1.=
</div><div><br></div></div></blockquote></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/194407f5-c086-4f0e-98a9-86b20a8cd38b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/194407f5-c086-4f0e-98a9-86b20a8cd38b=
%40isocpp.org</a>.<br />
------=_Part_2834_467347087.1469082919760--
------=_Part_2833_1721422797.1469082919759--
.
Author: "T. C." <rs2740@gmail.com>
Date: Thu, 21 Jul 2016 08:48:46 -0700 (PDT)
Raw View
------=_Part_526_1677273279.1469116127046
Content-Type: multipart/alternative;
boundary="----=_Part_527_1888418350.1469116127047"
------=_Part_527_1888418350.1469116127047
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What, in your view, sequences the evaluation of
x ^=3D y ^=3D x ^=3D y
|
|
this x and that of the rhs (y ^=3D x ^=3D y)?
On Thursday, July 21, 2016 at 2:35:20 AM UTC-4, FrankHB1989 wrote:
>
> No, it is not the case of "x ^=3D something-modifying-x", it is "y ^=3D=
=20
> something-modifying-x". There is no side effect beside assignments, and=
=20
> multiple side effects the assignments in this full expression are sequenc=
ed=20
> in a chain by the rule of assignment since each right operand is also an=
=20
> assignment expression, see [expr.ass]/1.
>
> And even if the left operand is denoting same scalar object, it is still=
=20
> not UB, because compound assignment is a single evaluation and the=20
> assigned-to operand is evaluated only once (see [expr.ass]/7), whose valu=
e=20
> computation is restricted by the rule above. Only when you have a=20
> volatile-qualified scalar, there will be unsequenced side effects (betwee=
n=20
> the left operand and right operand).
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B U=
TC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>
>>
>>
>> On Monday, July 18, 2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:
>>>
>>>
>>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD=
UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>>
>>>>
>>>>
>>>> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>>>>
>>>>>
>>>>> In C and C++98/03, for some initialized and distinct scalar objects x=
=20
>>>>> and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++1=
1 assignment=20
>>>>> allows it for non-volatile scalars, because the C++11 rules makes it=
=20
>>>>> effectively ordered (in such cases), with *right-to-left* order.
>>>>>
>>>>>
>>>> Nope, that's still undefined. It's essentially the same as i +=3D ++i =
+=20
>>>> 1; discussed in=20
>>>> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-=
undefined-behavior
>>>>
>>>> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=20
>>>>
>>> Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
>>>
>>
>> You have a x ^=3D something-modifying-x. There is no sequencing between =
the=20
>> read of x for the ^ and the modification in something-modifying-x - exac=
tly=20
>> the same problem as i +=3D ++i + 1.
>>
>>
--=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/b5a95799-bea4-4d12-b9bd-2624c8c73b47%40isocpp.or=
g.
------=_Part_527_1888418350.1469116127047
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What, in your view, sequences the evaluation of<div><br></=
div><div>x ^=3D y ^=3D x ^=3D y</div><div>|</div><div>|</div><div>this x an=
d that of the rhs (y ^=3D x ^=3D y)?</div><div><br>On Thursday, July 21, 20=
16 at 2:35:20 AM UTC-4, FrankHB1989 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">No, it is not the case of "x ^=3D somethi=
ng-modifying-x", it is "y ^=3D something-modifying-x".=C2=A0=
There is no side effect beside assignments, and multiple side effects the =
assignments in this full expression are sequenced in a chain by the rule of=
assignment since each right operand is also an assignment expression, see =
[expr.ass]/1.<br><br>And even if the left operand is denoting same scalar o=
bject, it is still not UB, because compound assignment is a single evaluati=
on and the assigned-to operand is evaluated only once (see [expr.ass]/7), w=
hose value computation is restricted by the rule above. Only when you have =
a volatile-qualified scalar, there will be unsequenced side effects (betwee=
n the left operand and right operand).<br><br><br>=E5=9C=A8 2016=E5=B9=B47=
=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=883:11=
:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><br><br>On Monday, July 18, 2016 at 2:39:02 AM UT=
C-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=
=E5=85=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=
=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On T=
hursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 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><br>In C and C++98/03, fo=
r some initialized and distinct scalar objects x and y, x ^=3D y ^=3D x ^=
=3D y will cause undefined behavior, but C++11 assignment allows it for non=
-volatile scalars, because the C++11 rules makes it effectively ordered (in=
such cases), with <i>right-to-left</i> order.<br><br></div></div></blockqu=
ote><div><br></div><div>Nope, that's still undefined. It's essentia=
lly the same as i +=3D ++i + 1; discussed in=C2=A0<a href=3D"http://stackov=
erflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-undefined-behavior"=
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fquestions%2F241940=
76%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return true;" onclick=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.c=
om%2Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';ret=
urn true;">http://stackoverflow.com/<wbr>questions/24194076/in-c11-<wbr>doe=
s-i-i-1-exhibit-undefined-<wbr>behavior</a></div><div><br></div><div>i =3D =
++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=C2=A0</div></div></blockqu=
ote><div>Really? Please i +=3D ++i + 1 is <i>not </i>j +=3D ++i + 1.<br></d=
iv></div></blockquote><div><br></div><div>You have a x ^=3D something-modif=
ying-x. There is no sequencing between the read of x for the ^ and the modi=
fication in something-modifying-x - exactly the same problem as i +=3D ++i =
+ 1.</div><div><br></div></div></blockquote></div></blockquote></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/b5a95799-bea4-4d12-b9bd-2624c8c73b47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5a95799-bea4-4d12-b9bd-2624c8c73b47=
%40isocpp.org</a>.<br />
------=_Part_527_1888418350.1469116127047--
------=_Part_526_1677273279.1469116127046--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 21 Jul 2016 12:59:26 -0400
Raw View
On 2016-07-17 21:34, FrankHB1989 wrote:
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 U=
TC+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A
>> "A user interface is like a joke. If you have to explain it, it's not=
=20
>> very good."
>
> Do you mean every command line shell should not be explained or no shells=
=20
> can be a good UI? That's totally nonsense.
> Even GUI may need professional training to use. Are CAD or Photoshop joke=
s?
Totally off topic, but I *have* used powerful CAD software without
needing a manual, at least for basic things. So, yeah, most CAD software
*does* have a horrible UI, as demonstrated by the existence of UI's that
*aren't* execrable.
As applied to C++, I consider myself an experienced C and C++
programmer... and in fact I *do* have almost zero formal training (at
least on C/C++ specifically). So, it *is* possible to learn C++ without
professional training.
I'm still going to argue that this *isn't* necessarily an argument in
favor of defined order. Specifically, because it encourages writing code
that *seems* correct (brittle) rather than code that *is* correct (robust).
In fact, I'll turn Hyman Rosen's quote on its head... if I have to
explain why a confusing expression is correct because <arcane rules of
evaluation order>...
--=20
Matthew
--=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/nmqv1f%244qc%241%40ger.gmane.org.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 21 Jul 2016 11:02:43 -0700
Raw View
--001a11377158f56ed50538291f90
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 20, 2016 at 11:35 PM, FrankHB1989 <frankhb1989@gmail.com> wrote=
:
> No, it is not the case of "x ^=3D something-modifying-x", it is "y ^=3D
> something-modifying-x". There is no side effect beside assignments, and
> multiple side effects the assignments in this full expression are sequenc=
ed
> in a chain by the rule of assignment since each right operand is also an
> assignment expression, see [expr.ass]/1.
>
> And even if the left operand is denoting same scalar object, it is still
> not UB, because compound assignment is a single evaluation
>
The rule in question is more subtle than that. See [expr.ass]/1:
"With respect to an indeterminately-sequenced function call, the operation
of a compound assignment is a single evaluation. [ Note: Therefore, a
function call shall not intervene between the lvalue-to-rvalue conversion
and the side effect associated with any single compound assignment
operator. =E2=80=94 end note ]"
Function calls do not occur between the load and store of a
compound-assignment, but that does not cause the implied load to be
sequenced after the value computation of the right-hand side. (Under the
C++17 rules, the RHS is sequenced before the LHS, and -- presumably -- the
value computation of the LHS should be assumed to be sequenced before the
implied load in a compound assignment, so the required sequencing can be
inferred.)
> and the assigned-to operand is evaluated only once (see [expr.ass]/7),
> whose value computation is restricted by the rule above. Only when you ha=
ve
> a volatile-qualified scalar, there will be unsequenced side effects
> (between the left operand and right operand).
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B U=
TC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>
>>
>>
>> On Monday, July 18, 2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:
>>>
>>>
>>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD=
UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>>
>>>>
>>>>
>>>> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>>>>
>>>>>
>>>>> In C and C++98/03, for some initialized and distinct scalar objects x
>>>>> and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++1=
1 assignment
>>>>> allows it for non-volatile scalars, because the C++11 rules makes it
>>>>> effectively ordered (in such cases), with *right-to-left* order.
>>>>>
>>>>>
>>>> Nope, that's still undefined. It's essentially the same as i +=3D ++i =
+
>>>> 1; discussed in
>>>> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-=
undefined-behavior
>>>>
>>>> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.
>>>>
>>> Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
>>>
>>
>> You have a x ^=3D something-modifying-x. There is no sequencing between =
the
>> read of x for the ^ and the modification in something-modifying-x - exac=
tly
>> the same problem as i +=3D ++i + 1.
>>
>> --
> 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/194407f5-c08=
6-4f0e-98a9-86b20a8cd38b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/194407f5-c0=
86-4f0e-98a9-86b20a8cd38b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAOfiQqnZotdztyfbHrKnmz_OUS%2Bpabxzzjf3kCP%3D%3D=
enCZOYK-g%40mail.gmail.com.
--001a11377158f56ed50538291f90
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 W=
ed, Jul 20, 2016 at 11:35 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">No, it is not the cas=
e of "x ^=3D something-modifying-x", it is "y ^=3D something=
-modifying-x".=C2=A0 There is no side effect beside assignments, and m=
ultiple side effects the assignments in this full expression are sequenced =
in a chain by the rule of assignment since each right operand is also an as=
signment expression, see [expr.ass]/1.<br><br>And even if the left operand =
is denoting same scalar object, it is still not UB, because compound assign=
ment is a single evaluation</div></blockquote><div><br></div><div>The rule =
in question is more subtle than that. See [expr.ass]/1:</div><div><br></div=
><div>"With respect to an indeterminately-sequenced function call, the=
operation of a compound assignment is a single evaluation. [ Note: Therefo=
re, a function call shall not intervene between the lvalue-to-rvalue conver=
sion and the side effect associated with any single compound assignment ope=
rator. =E2=80=94 end note ]"</div><div><br></div><div>Function calls d=
o not occur between the load and store of a compound-assignment, but that d=
oes not cause the implied load to be sequenced after the value computation =
of the right-hand side. (Under the C++17 rules, the RHS is sequenced before=
the LHS, and -- presumably -- the value computation of the LHS should be a=
ssumed to be sequenced before the implied load in a compound assignment, so=
the required sequencing can be inferred.)</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div dir=3D"ltr">and the assigned-to operand is evaluated only once =
(see [expr.ass]/7), whose value computation is restricted by the rule above=
.. Only when you have a volatile-qualified scalar, there will be unsequenced=
side effects (between the left operand and right operand).<span class=3D""=
><br><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=
=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=
=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, July 18, 2016 at=
2:39:02 AM UTC-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD=
UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, July 14, 2016 at 10:00:=
10 PM UTC-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br>I=
n C and C++98/03, for some initialized and distinct scalar objects x and y,=
x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11 assignment=
allows it for non-volatile scalars, because the C++11 rules makes it effec=
tively ordered (in such cases), with <i>right-to-left</i> order.<br><br></d=
iv></div></blockquote><div><br></div><div>Nope, that's still undefined.=
It's essentially the same as i +=3D ++i + 1; discussed in=C2=A0<a href=
=3D"http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-u=
ndefined-behavior" rel=3D"nofollow" target=3D"_blank">http://stackoverflow.=
com/questions/24194076/in-c11-does-i-i-1-exhibit-undefined-behavior</a></di=
v><div><br></div><div>i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not=
..=C2=A0</div></div></blockquote><div>Really? Please i +=3D ++i + 1 is <i>no=
t </i>j +=3D ++i + 1.<br></div></div></blockquote><div><br></div><div>You h=
ave a x ^=3D something-modifying-x. There is no sequencing between the read=
of x for the ^ and the modification in something-modifying-x - exactly the=
same problem as i +=3D ++i + 1.</div><div><br></div></div></blockquote></s=
pan></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" 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@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/194407f5-c086-4f0e-98a9-86b20a8cd38b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/194407f5-c086-=
4f0e-98a9-86b20a8cd38b%40isocpp.org</a>.<br>
</blockquote></div><br></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/CAOfiQqnZotdztyfbHrKnmz_OUS%2Bpabxzzj=
f3kCP%3D%3DenCZOYK-g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnZot=
dztyfbHrKnmz_OUS%2Bpabxzzjf3kCP%3D%3DenCZOYK-g%40mail.gmail.com</a>.<br />
--001a11377158f56ed50538291f90--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 21 Jul 2016 18:26:08 -0400
Raw View
--94eb2c0566ce2724e205382ccf94
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 21, 2016 at 12:59 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> In fact, I'll turn Hyman Rosen's quote on its head... if I have to
> explain why a confusing expression is correct because <arcane rules of
> evaluation order>...
Therefore it is a language design error for the rules of evaluation order
to be arcane. Therefore the rule should be strict left-to-right.
It is strictly better for a confusing expression to have a single meaning
than to have a set of possible meanings of which an arbitrary one is chosen
by the language environment without comment, because when the arbitrary
choice matches the programmer's expectation, the programmer will
incorrectly believe that the expression is absolutely correct rather than
accidentally correct.
--
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/CAHSYqdZToKJaCNurB-siv3t6EgnNseV8BEEi9d4mE5DJSkhneA%40mail.gmail.com.
--94eb2c0566ce2724e205382ccf94
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, Jul 21, 2016 at 12:59 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex">
In fact, I'll turn Hyman Rosen's quote on its head... if I have to<=
br>
explain why a confusing expression is correct because <arcane rules of<b=
r>
evaluation order>...</blockquote><div><br></div><div>Therefore it is a l=
anguage design error for the rules of evaluation order to be arcane.=C2=A0 =
Therefore the rule should be strict left-to-right.</div><div><br></div><div=
>It is strictly better for a confusing expression to have a single meaning =
than to have a set of possible meanings of which an arbitrary one is chosen=
by the language environment without comment, because when the arbitrary ch=
oice matches the programmer's expectation, the programmer will incorrec=
tly believe that the expression is absolutely correct rather than accidenta=
lly correct.</div></div></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/CAHSYqdZToKJaCNurB-siv3t6EgnNseV8BEEi=
9d4mE5DJSkhneA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZToKJaCNur=
B-siv3t6EgnNseV8BEEi9d4mE5DJSkhneA%40mail.gmail.com</a>.<br />
--94eb2c0566ce2724e205382ccf94--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 21 Jul 2016 23:02:34 -0700 (PDT)
Raw View
------=_Part_92_1101559184.1469167355028
Content-Type: multipart/alternative;
boundary="----=_Part_93_1452813896.1469167355028"
------=_Part_93_1452813896.1469167355028
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
From right to left.
More specifically, in abstract machine semantics, for some non=20
volatile-qualified scalar lvalue variables x and y, evaluation of this full=
=20
expression will be equivalent to evaluation of expressions in the following=
=20
statements:
x ^=3D y;
y ^=3D x; // The right operand is the result of the rightmost x ^=3D y.
x ^=3D y; // The right operand is the result of y ^=3D x ^=3D y.
As if there are more than one ';' provided by the rule of assignment=20
(though "as-if" rules are actually not needed).
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=8811:48:47=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>
> What, in your view, sequences the evaluation of
>
> x ^=3D y ^=3D x ^=3D y
> |
> |
> this x and that of the rhs (y ^=3D x ^=3D y)?
>
> On Thursday, July 21, 2016 at 2:35:20 AM UTC-4, FrankHB1989 wrote:
>>
>> No, it is not the case of "x ^=3D something-modifying-x", it is "y ^=3D=
=20
>> something-modifying-x". There is no side effect beside assignments, and=
=20
>> multiple side effects the assignments in this full expression are sequen=
ced=20
>> in a chain by the rule of assignment since each right operand is also an=
=20
>> assignment expression, see [expr.ass]/1.
>>
>> And even if the left operand is denoting same scalar object, it is still=
=20
>> not UB, because compound assignment is a single evaluation and the=20
>> assigned-to operand is evaluated only once (see [expr.ass]/7), whose val=
ue=20
>> computation is restricted by the rule above. Only when you have a=20
>> volatile-qualified scalar, there will be unsequenced side effects (betwe=
en=20
>> the left operand and right operand).
>>
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>
>>>
>>>
>>> On Monday, July 18, 2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:
>>>>
>>>>
>>>>
>>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>>>>>
>>>>>>
>>>>>> In C and C++98/03, for some initialized and distinct scalar objects =
x=20
>>>>>> and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++=
11 assignment=20
>>>>>> allows it for non-volatile scalars, because the C++11 rules makes it=
=20
>>>>>> effectively ordered (in such cases), with *right-to-left* order.
>>>>>>
>>>>>>
>>>>> Nope, that's still undefined. It's essentially the same as i +=3D ++i=
+=20
>>>>> 1; discussed in=20
>>>>> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit=
-undefined-behavior
>>>>>
>>>>> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=20
>>>>>
>>>> Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
>>>>
>>>
>>> You have a x ^=3D something-modifying-x. There is no sequencing between=
=20
>>> the read of x for the ^ and the modification in something-modifying-x -=
=20
>>> exactly the same problem as i +=3D ++i + 1.
>>>
>>>
--=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/854aa32a-d7c8-46b9-9b99-00b3f45793b8%40isocpp.or=
g.
------=_Part_93_1452813896.1469167355028
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">From right to left.<br><br>More specifically, in abstract =
machine semantics, for some non volatile-qualified scalar lvalue variables =
x and y, evaluation of this full expression will be equivalent to evaluatio=
n of expressions in the following statements:<br><br>x ^=3D y;<br>y ^=3D x;=
// The right operand is the result of the rightmost x ^=3D y.<br>x ^=3D y;=
// The right operand is the result of y ^=3D x ^=3D y.<br><br>As if there =
are more than one=C2=A0 ';' provided by the rule of assignment (tho=
ugh "as-if" rules are actually not needed).<br><br>=E5=9C=A8 2016=
=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=
=8D=8811:48:47=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">What, in your view, sequences the=
evaluation of<div><br></div><div>x ^=3D y ^=3D x ^=3D y</div><div>|</div><=
div>|</div><div>this x and that of the rhs (y ^=3D x ^=3D y)?</div><div><br=
>On Thursday, July 21, 2016 at 2:35:20 AM UTC-4, FrankHB1989 wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">No, it is not the case of =
"x ^=3D something-modifying-x", it is "y ^=3D something-modi=
fying-x".=C2=A0 There is no side effect beside assignments, and multip=
le side effects the assignments in this full expression are sequenced in a =
chain by the rule of assignment since each right operand is also an assignm=
ent expression, see [expr.ass]/1.<br><br>And even if the left operand is de=
noting same scalar object, it is still not UB, because compound assignment =
is a single evaluation and the assigned-to operand is evaluated only once (=
see [expr.ass]/7), whose value computation is restricted by the rule above.=
Only when you have a volatile-qualified scalar, there will be unsequenced =
side effects (between the left operand and right operand).<br><br><br>=E5=
=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+8=
=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, July 18,=
2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=
=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT.=
C.=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><br>On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankH=
B1989 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><=
br>In C and C++98/03, for some initialized and distinct scalar objects x an=
d y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++11 assign=
ment allows it for non-volatile scalars, because the C++11 rules makes it e=
ffectively ordered (in such cases), with <i>right-to-left</i> order.<br><br=
></div></div></blockquote><div><br></div><div>Nope, that's still undefi=
ned. It's essentially the same as i +=3D ++i + 1; discussed in=C2=A0<a =
href=3D"http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhib=
it-undefined-behavior" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"th=
is.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.co=
m%2Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fstackoverflow.com%2Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit=
-undefined-behavior\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_=
g0P2Y70JPyQVQ';return true;">http://stackoverflow.com/<wbr>questions/24=
194076/in-c11-<wbr>does-i-i-1-exhibit-undefined-<wbr>behavior</a></div><div=
><br></div><div>i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=C2=
=A0</div></div></blockquote><div>Really? Please i +=3D ++i + 1 is <i>not </=
i>j +=3D ++i + 1.<br></div></div></blockquote><div><br></div><div>You have =
a x ^=3D something-modifying-x. There is no sequencing between the read of =
x for the ^ and the modification in something-modifying-x - exactly the sam=
e problem as i +=3D ++i + 1.</div><div><br></div></div></blockquote></div><=
/blockquote></div></div></blockquote></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/854aa32a-d7c8-46b9-9b99-00b3f45793b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/854aa32a-d7c8-46b9-9b99-00b3f45793b8=
%40isocpp.org</a>.<br />
------=_Part_93_1452813896.1469167355028--
------=_Part_92_1101559184.1469167355028--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 21 Jul 2016 23:19:21 -0700 (PDT)
Raw View
------=_Part_109_235092110.1469168361704
Content-Type: multipart/alternative;
boundary="----=_Part_110_2050020573.1469168361705"
------=_Part_110_2050020573.1469168361705
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=8812:59:39=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 2016-07-17 21:34, FrankHB1989 wrote:=20
> > =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94=
UTC+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=EF=BC=
=9A=20
> >> "A user interface is like a joke. If you have to explain it, it's not=
=20
> >> very good."=20
> >=20
> > Do you mean every command line shell should not be explained or no=20
> shells=20
> > can be a good UI? That's totally nonsense.=20
> > Even GUI may need professional training to use. Are CAD or Photoshop=20
> jokes?=20
>
> Totally off topic, but I *have* used powerful CAD software without=20
> needing a manual, at least for basic things. So, yeah, most CAD software=
=20
> *does* have a horrible UI, as demonstrated by the existence of UI's that=
=20
> *aren't* execrable.=20
>
Because you have some basic knowledge of the "basic things". You were not=
=20
skilled when born.
I don't know what things are basic enough here for CAD software. I know=20
almost nothing to play with them, even I have implemented some plugins for=
=20
ProE/UG/AutoCAD during working.
As an end-user, I *do* *use *them without manual a bit, just because I know=
=20
the most basic knowledge about it, which is almost totally *shared *with=20
other interface - e.g. how to close a window :)
> As applied to C++, I consider myself an experienced C and C++=20
> programmer... and in fact I *do* have almost zero formal training (at=20
> least on C/C++ specifically). So, it *is* possible to learn C++ without=
=20
> professional training.=20
>
> So possibly as the result, you don't get the idea that some others have=
=20
got... The difference may be caused by the background problems, but anyway,=
=20
experience matters.
=20
> I'm still going to argue that this *isn't* necessarily an argument in=20
> favor of defined order. Specifically, because it encourages writing code=
=20
> that *seems* correct (brittle) rather than code that *is* correct=20
> (robust).=20
>
> Agreed.
=20
> In fact, I'll turn Hyman Rosen's quote on its head... if I have to=20
> explain why a confusing expression is correct because <arcane rules of=20
> evaluation order>...=20
>
> --=20
> Matthew=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/7bc622da-a9b2-4be9-9bcc-f16d2b42697c%40isocpp.or=
g.
------=_Part_110_2050020573.1469168361705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=8812:59:39=EF=BC=8CMatthew Woehl=
ke=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n 2016-07-17 21:34, FrankHB1989 wrote:
<br>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=94 UTC+8=E4=B8=8B=E5=8D=889:40:56=EF=BC=8CHyman Rosen=E5=86=99=E9=81=93=
=EF=BC=9A
<br>>> "A user interface is like a joke. =C2=A0If you have to ex=
plain it, it's not=20
<br>>> very good."
<br>>
<br>> Do you mean every command line shell should not be explained or no=
shells=20
<br>> can be a good UI? That's totally nonsense.
<br>> Even GUI may need professional training to use. Are CAD or Photosh=
op jokes?
<br>
<br>Totally off topic, but I *have* used powerful CAD software without
<br>needing a manual, at least for basic things. So, yeah, most CAD softwar=
e
<br>*does* have a horrible UI, as demonstrated by the existence of UI's=
that
<br>*aren't* execrable.
<br></blockquote><div>Because you have some basic knowledge of the "ba=
sic things". You were not skilled when born.<br>I don't know what =
things are basic enough here for CAD software. I know almost nothing to pla=
y with them, even I have implemented some plugins for ProE/UG/AutoCAD durin=
g working.<br>As an end-user, I <i>do</i> <i>use </i>them without manual a =
bit, just because I know the most basic knowledge about it, which is almost=
totally <i>shared </i>with other interface - e.g. how to close a window :)=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>As applied to C++, I consider myself an experienced C and C++
<br>programmer... and in fact I *do* have almost zero formal training (at
<br>least on C/C++ specifically). So, it *is* possible to learn C++ without
<br>professional training.
<br>
<br></blockquote><div>So possibly as the result, you don't get the idea=
that some others have got... The difference may be caused by the backgroun=
d problems, but anyway, experience matters.<br><br>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">I'm still going to argue that this=
*isn't* necessarily an argument in
<br>favor of defined order. Specifically, because it encourages writing cod=
e
<br>that *seems* correct (brittle) rather than code that *is* correct (robu=
st).
<br>
<br></blockquote><div>Agreed.<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">In fact, I'll turn Hyman Rosen's quote on its he=
ad... if I have to
<br>explain why a confusing expression is correct because <arcane rules =
of
<br>evaluation order>...
<br>
<br>--=20
<br>Matthew
<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" 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/7bc622da-a9b2-4be9-9bcc-f16d2b42697c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7bc622da-a9b2-4be9-9bcc-f16d2b42697c=
%40isocpp.org</a>.<br />
------=_Part_110_2050020573.1469168361705--
------=_Part_109_235092110.1469168361704--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 21 Jul 2016 23:57:50 -0700 (PDT)
Raw View
------=_Part_127_2102400007.1469170670532
Content-Type: multipart/alternative;
boundary="----=_Part_128_156941036.1469170670532"
------=_Part_128_156941036.1469170670532
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The rule of single evaluation is normative text. Even the intent specified=
=20
in the note is merely for preventing interleaving function calls, it can=20
cover other cases.
A more fundamental flaw is the specification on the operation itself. The=
=20
standard does not specify the evaluation must include the effect from a=20
"load" (read: not requires, or *excludes *it from the abstract machine=20
semantics) to get both the identity (for a lvalue) and the stored value=20
(for lvalue used as a prvalue) of the invented operand in the compound=20
assignment. To determinate the value of this operand, a value computation=
=20
is needed. Unless the standard explicitly allows some superfluous effects=
=20
(of lvalue-to-rvalue conversions), that can only be the value computation=
=20
in the evaluation of the left operand, whose order is already restricted.
BTW, though not necessarily, in the aspect of typical implementation, an=20
instruction set architecture may likely not impose the requirement of the=
=20
load operation - the effect may be micro-fused in underlying instruction=20
implementation, e.g. microarchitecture of a processor. This makes the=20
abstract machine closer to ISA.
C++17 rule would be clearer, though.
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=882:02:48=EF=BC=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Wed, Jul 20, 2016 at 11:35 PM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
>> No, it is not the case of "x ^=3D something-modifying-x", it is "y ^=3D=
=20
>> something-modifying-x". There is no side effect beside assignments, and=
=20
>> multiple side effects the assignments in this full expression are sequen=
ced=20
>> in a chain by the rule of assignment since each right operand is also an=
=20
>> assignment expression, see [expr.ass]/1.
>>
>> And even if the left operand is denoting same scalar object, it is still=
=20
>> not UB, because compound assignment is a single evaluation
>>
>
> The rule in question is more subtle than that. See [expr.ass]/1:
>
> "With respect to an indeterminately-sequenced function call, the operatio=
n=20
> of a compound assignment is a single evaluation. [ Note: Therefore, a=20
> function call shall not intervene between the lvalue-to-rvalue conversion=
=20
> and the side effect associated with any single compound assignment=20
> operator. =E2=80=94 end note ]"
>
> Function calls do not occur between the load and store of a=20
> compound-assignment, but that does not cause the implied load to be=20
> sequenced after the value computation of the right-hand side. (Under the=
=20
> C++17 rules, the RHS is sequenced before the LHS, and -- presumably -- th=
e=20
> value computation of the LHS should be assumed to be sequenced before the=
=20
> implied load in a compound assignment, so the required sequencing can be=
=20
> inferred.)
> =20
>
>> and the assigned-to operand is evaluated only once (see [expr.ass]/7),=
=20
>> whose value computation is restricted by the rule above. Only when you h=
ave=20
>> a volatile-qualified scalar, there will be unsequenced side effects=20
>> (between the left operand and right operand).
>>
>>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>
>>>
>>>
>>> On Monday, July 18, 2016 at 2:39:02 AM UTC-4, FrankHB1989 wrote:
>>>>
>>>>
>>>>
>>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=
=AD UTC+8=E4=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, July 14, 2016 at 10:00:10 PM UTC-4, FrankHB1989 wrote:
>>>>>>
>>>>>>
>>>>>> In C and C++98/03, for some initialized and distinct scalar objects =
x=20
>>>>>> and y, x ^=3D y ^=3D x ^=3D y will cause undefined behavior, but C++=
11 assignment=20
>>>>>> allows it for non-volatile scalars, because the C++11 rules makes it=
=20
>>>>>> effectively ordered (in such cases), with *right-to-left* order.
>>>>>>
>>>>>>
>>>>> Nope, that's still undefined. It's essentially the same as i +=3D ++i=
+=20
>>>>> 1; discussed in=20
>>>>> http://stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit=
-undefined-behavior
>>>>>
>>>>> i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=20
>>>>>
>>>> Really? Please i +=3D ++i + 1 is *not *j +=3D ++i + 1.
>>>>
>>>
>>> You have a x ^=3D something-modifying-x. There is no sequencing between=
=20
>>> the read of x for the ^ and the modification in something-modifying-x -=
=20
>>> exactly the same problem as i +=3D ++i + 1.
>>>
>>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/194407f5-c0=
86-4f0e-98a9-86b20a8cd38b%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/194407f5-c=
086-4f0e-98a9-86b20a8cd38b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/3198345a-7912-4908-a249-a09a940471e8%40isocpp.or=
g.
------=_Part_128_156941036.1469170670532
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The rule of single evaluation is normative text. Even the =
intent specified in the note is merely for preventing interleaving function=
calls, it can cover other cases.<br><br>A more fundamental flaw is the spe=
cification on the operation itself. The standard does not specify the evalu=
ation must include the effect from a "load" (read: not requires, =
or <i>excludes </i>it from the abstract machine semantics) to get both the =
identity (for a lvalue) and the stored value (for lvalue used as a prvalue)=
of the invented operand in the compound assignment. To determinate the val=
ue of this operand, a value computation is needed. Unless the standard expl=
icitly allows some superfluous effects (of lvalue-to-rvalue conversions), t=
hat can only be the value computation in the evaluation of the left operand=
, whose order is already restricted.<br><br>BTW, though not necessarily, in=
the aspect of typical implementation, an instruction set architecture may =
likely not impose the requirement of the load operation - the effect may be=
micro-fused in underlying instruction implementation, e.g. microarchitectu=
re of a processor. This makes the abstract machine closer to ISA.<br><br>C+=
+17 rule would be clearer, though.<br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=88=
22=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=882:02:48=EF=BC=
=8CRichard Smith=E5=86=99=E9=81=93=EF=BC=9A<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 class=3D"gmail_quote">On Wed, Jul 2=
0, 2016 at 11:35 PM, FrankHB1989 <span dir=3D"ltr"><<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"IrKOcgtYAwAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">frank...@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr">No, it is not the ca=
se of "x ^=3D something-modifying-x", it is "y ^=3D somethin=
g-modifying-x".=C2=A0 There is no side effect beside assignments, and =
multiple side effects the assignments in this full expression are sequenced=
in a chain by the rule of assignment since each right operand is also an a=
ssignment expression, see [expr.ass]/1.<br><br>And even if the left operand=
is denoting same scalar object, it is still not UB, because compound assig=
nment is a single evaluation</div></blockquote><div><br></div><div>The rule=
in question is more subtle than that. See [expr.ass]/1:</div><div><br></di=
v><div>"With respect to an indeterminately-sequenced function call, th=
e operation of a compound assignment is a single evaluation. [ Note: Theref=
ore, a function call shall not intervene between the lvalue-to-rvalue conve=
rsion and the side effect associated with any single compound assignment op=
erator. =E2=80=94 end note ]"</div><div><br></div><div>Function calls =
do not occur between the load and store of a compound-assignment, but that =
does not cause the implied load to be sequenced after the value computation=
of the right-hand side. (Under the C++17 rules, the RHS is sequenced befor=
e the LHS, and -- presumably -- the value computation of the LHS should be =
assumed to be sequenced before the implied load in a compound assignment, s=
o the required sequencing can be inferred.)</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr">and the assigned-to operand is evaluated only once=
(see [expr.ass]/7), whose value computation is restricted by the rule abov=
e. Only when you have a volatile-qualified scalar, there will be unsequence=
d side effects (between the left operand and right operand).<span><br><br><=
br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8A=E5=8D=883:11:19=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><br><br>On Monday, July 18, 2016 at 2:39:02 A=
M UTC-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=E5=9C=
=A8 2016=E5=B9=B47=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=
=B8=8A=E5=8D=886:07:54=EF=BC=8CT. C.=E5=86=99=E9=81=93=EF=BC=9A<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><br><br>On Thursday, July 14, 2016 at 10:00:10 PM UTC=
-4, FrankHB1989 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br>In C and C=
++98/03, for some initialized and distinct scalar objects x and y, x ^=3D y=
^=3D x ^=3D y will cause undefined behavior, but C++11 assignment allows i=
t for non-volatile scalars, because the C++11 rules makes it effectively or=
dered (in such cases), with <i>right-to-left</i> order.<br><br></div></div>=
</blockquote><div><br></div><div>Nope, that's still undefined. It's=
essentially the same as i +=3D ++i + 1; discussed in=C2=A0<a href=3D"http:=
//stackoverflow.com/questions/24194076/in-c11-does-i-i-1-exhibit-undefined-=
behavior" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fquestions=
%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-behavior\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fstacko=
verflow.com%2Fquestions%2F24194076%2Fin-c11-does-i-i-1-exhibit-undefined-be=
havior\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQzjLkKrYcQB5l_g0P2Y70JPyQVQ=
';return true;">http://stackoverflow.com/<wbr>questions/24194076/in-c11=
-<wbr>does-i-i-1-exhibit-undefined-<wbr>behavior</a></div><div><br></div><d=
iv>i =3D ++i + 1 is fine in C++11. i +=3D ++i + 1 is not.=C2=A0</div></div>=
</blockquote><div>Really? Please i +=3D ++i + 1 is <i>not </i>j +=3D ++i + =
1.<br></div></div></blockquote><div><br></div><div>You have a x ^=3D someth=
ing-modifying-x. There is no sequencing between the read of x for the ^ and=
the modification in something-modifying-x - exactly the same problem as i =
+=3D ++i + 1.</div><div><br></div></div></blockquote></span></div><span>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
IrKOcgtYAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"IrKOcgtYAwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/194407f5-c086-4f0e-98a9-86b20a8cd38b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/194407f5-c086-4f0e-98a9-86b20a8cd38b%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/194407f5-c086-4f0e-98a9-86b20a8cd38b%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/194407f5-c086-4f0e-<wbr>98a9-=
86b20a8cd38b%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
</blockquote></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/3198345a-7912-4908-a249-a09a940471e8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3198345a-7912-4908-a249-a09a940471e8=
%40isocpp.org</a>.<br />
------=_Part_128_156941036.1469170670532--
------=_Part_127_2102400007.1469170670532--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sat, 23 Jul 2016 04:10:23 -0700 (PDT)
Raw View
------=_Part_583_2103429913.1469272223385
Content-Type: multipart/alternative;
boundary="----=_Part_584_940328164.1469272223386"
------=_Part_584_940328164.1469272223386
Content-Type: text/plain; charset=UTF-8
BTW, besides C++, there can be some (un)interesting thing if people relies
on left-to-right evaluation too much:
https://cygwin.com/ml/cygwin/2013-05/msg00222.html
--
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/4a34c38a-54e1-472b-b4ab-705485b40eda%40isocpp.org.
------=_Part_584_940328164.1469272223386
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">BTW, besides C++, there can be some (un)interesting thing =
if people relies on left-to-right evaluation too much:<br><br>https://cygwi=
n.com/ml/cygwin/2013-05/msg00222.html<br><br></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/4a34c38a-54e1-472b-b4ab-705485b40eda%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a34c38a-54e1-472b-b4ab-705485b40eda=
%40isocpp.org</a>.<br />
------=_Part_584_940328164.1469272223386--
------=_Part_583_2103429913.1469272223385--
.